[RTW] WG charter, take 4

[Harald Alvestrand]

On 02/25/11 09:01, Elwell, John wrote:
> "These events and state
> need to include information such as: receiving DTMF in the RTP, RTP and
> RTCP statistics, and the state of DTLS/SRTP handshakes."
>
> I would be inclined to say instead:
> "These events and state
> need to include information such as: receiving DTMF in the RTP, RTP and
> RTCP statistics, and the security status of RTP sessions."
>
> This would bring it more into line with item 9 earlier, which refrains from mentioning a specific key management protocol.
>
> Also a nit: "NSIS" appears twice in the same list.
thanks - I'll just adopt this, it seems sensible and uncontroversial.

> John
>
>> -----Original Message-----
>> From: rtc-web-bounces at alvestrand.no
>> [mailto:rtc-web-bounces at alvestrand.no] On Behalf Of Harald Alvestrand
>> Sent: 24 February 2011 13:45
>> To: RTC-Web at alvestrand.no
>> Subject: [RTW] WG charter, take 4
>>
>> This is the current charter text - it's updated somewhat based on
>> discussions on the list.
>>
>> In particular, there's now suggested language about the
>> relationship to
>> session management protocols.
>> We'll make this an explicit discussion at the BOF, with the aim of
>> getting one of three conclusions in the charter:
>>
>> - The WG will not address session management protocols
>> - The WG will choose one or more session management protocols
>> - The WG will discuss session management protocols, and do
>> what makes sense.
>>
>> The last one is the one suggested by the current charter
>> text; the other
>> possible outcomes should be easier to write text for.
>>
>> Comments welcome!
>>
>> Harald
>>
>> (Note: The below is not going out in<  80 columns, I think. Please
>> forgive the formatting issue.)
>>
>> ------------------------------------------------
>>
>> Version: 4
>>
>> Name: RTCWEB
>> WG Chair(s): Cullen Jennings<fluffy at cisco.com>
>>
>> Body:
>>
>> Many implementations have been made that use a Web browser to support
>> direct, interactive communications, including voice, video,
>> collaboration, and gaming. In these implementations, the web
>> server acts
>> as the signaling path between these applications, using locally
>> significant identifiers to set up the association. Up till now, such
>> applications have typically required the installation of plugins or
>> non-standard browser extensions. There is a desire to standardize this
>> functionality, so that this type of application can be run in any
>> compatible browser and allow for high-quality real-time
>> communications
>> experiences within the browser.
>>
>> Traditionally, the W3C has defined API and markup languages
>> such as HTML
>> that work in conjunction with with the IETF over the wire
>> protocols such
>> as HTTP to allow web browsers to display media that does not
>> have real
>> time interactive constraints with another human.
>>
>> The W3C and IETF plan to collaborate together in their
>> traditional way
>> to meet the evolving needs of browsers. Specifically the IETF will
>> provide a set of on the wire protocols, including RTP, to
>> meet the needs
>> on interactive communications, and the W3C will define the API and
>> markup to allow web application developers to control the on the wire
>> protocols. This will allow application developers to write
>> applications
>> that run in a browser and facilitate interactive
>> communications between
>> users for voice and video communications, collaboration, and gaming.
>>
>> This working group will select and define a minimal set of protocols
>> that will enable browsers to:
>> have interactive real time voice and video pairwise between
>> browsers or
>> other devices using RTP
>> have interactive real time application data for collaboration
>> and gaming
>> pairwise between browsers
>>
>>
>> Fortunately very little development of new protocol at IETF
>> is required
>> for this, only selection of existing protocols and selection
>> of minimum
>> capabilities to ensure interoperability. The following protocols are
>> candidates for including in the profile set:
>>
>> 1) RTP/ RTCP
>>
>> 2) a baseline audio codec for high quality interactive audio.
>> Opus will
>> be one of the codecs considered
>>
>> 3) a baseline audio codec for PSTN interoperability. G.711
>> and iLBC will
>> be some of the codecs considered
>>
>> 4) a baseline video codec. H.264 and VP8 will be some of the codecs
>> considered
>>
>> 5) Diffserv based QoS
>>
>> 6) NAT traversal using ICE
>>
>> 7) media based DTMF
>>
>> 8) support for identifying streams' purpose using semantics labels
>> mappable to the labels described in RFC 4574
>>
>> 9) Secure RTP and keying
>>
>> 10) support for IPv4, IPv6 and dual stack browsers
>>
>> Please note the above list is only a set of candidates that
>> the WG may
>> consider and is not list of things that will be in the
>> profile the set.
>>
>> This group's primary aim is to enable web applications to manage
>> real-time communication sessions with other web-context applications
>> that implement this specification. When making choices, the working
>> group will also consider the impact of those choices on
>> interoperability
>> with other devices that create or manage multimedia sessions,
>> including
>> the complexity imposed
>> on any gateways which may be required.
>>
>> The Working group will identify information needed for session
>> negotiation and management in web contexts, and its output documents
>> will describe the relationship of this to information carried
>> in session
>> protocols used in other standardized contexts.
>>
>> 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 cooperate closely with the W3C activity that
>> specifies a semantic level API that allows the control and
>> manipulation
>> of all the functionality above. In addition, the API needs to
>> communicate state information and events about what is
>> happening in the
>> browser to applications running in the browser. These events
>> and state
>> need to include information such as: receiving DTMF in the
>> RTP, RTP and
>> RTCP statistics, and the state of DTLS/SRTP handshakes. The output of
>> this WG will form input to the W3C group that specifies the
>> API, and if
>> there are parts of the mapping between the API and the protocols that
>> need to be done outside of the W3C, this group will do it.
>>
>> 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.
>>
>> The following topics will be out of scope for the initial
>> phase of the
>> WG but could be added after a recharter: RTSP, RSVP, NSIS, LOST,
>> Geolocation, IM&  Presence, NSIS, Resource Priority. RTP
>> Payload formats
>> will not be done in this WG.
>>
>> Deliverables:
>> An overview document describing the architecture
>> A scenarios document describing scenarios that are expected
>> to be supported
>> A profile document specifying the protocols and options that must be
>> supported by a conforming implementation
>> (If needed) A mapping document describing the relationship
>> between the
>> protocols and the W3C-defined API.
>>
>>
>> Milestones:
>>
>> May 2011 Main alternatives identified in drafts
>>
>> Aug 2011 WG draft with text reflecting agreement of what the
>> profile set
>> should be
>>
>> Sept 2011 Scenarios specification to IESG as Informational
>>
>> Nov 2011 Draft available of documentation specifying mapping
>> of protocol
>> functionality to W3C-specified API produced. This is an input
>> to W3C API
>> work.
>>
>> Dec 2011 Profile specification to IESG as PS
>>
>> Apr 2012 Mapping document submitted to the IESG as
>> Informational (if needed)
>>
>>
>> _______________________________________________
>> RTC-Web mailing list
>> RTC-Web at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>>