So, I just finished reading draft-marjou-dispatch-rtcweb-sip-rtp-interwk-reqs-00.txt, draft-rosenberg-rtcweb-framework-00.txt, and the thread to date. Both drafts have some nice ascii art showing where they expect specific pieces of functionality to sit. The Marjou et al draft has this: ----------------- ----------------- | RTC-Web | | SIP-RTP | | application | | application | |-----------------| | | |rtcweb rtcweb | | | | sig media | | | | APIs APIs | | | |-----------------| | | | | | | | ----- | | ----- | || SIP | |<-----------SIP----------->|| SIP | | ||stack| | ||stack| | | ----- | | ----- | | ----- | | ----- | | | RTP ||<-----------RTP----------->| | RTP || | |stack|| | |stack|| | ----- | | ----- | ----------------- ----------------- and the Rosenberg et al draft has this: +------------------------+ On-the-wire | | Protocols | Servers |---------> | | | | +------------------------+ ^ | | | HTTP/ | Websockets | | | | +----------------------------+ | Javascript/HTML/CSS | +----------------------------+ Other ^ ^RTC APIs | |APIs +---|-----------------|------+ | | | | | +---------+| | | Browser || On-the-wire | Browser | RTC || Protocols | | Function|-----------> | | || | | || | +---------+| +---------------------|------+ | V Native OS Services I have to say that I like the term "RTC-Web application" better. The working group appears to me to be taking on specifying how to use a set of web technologies to talk to a web-based rendezvous server (and potential intermediary) for real-time communications. That may be because they want to have live video of their poker partners on a gaming site, because they want their shared desktop/conferencing software to be able to call out to participants, or for any one of a number of other scenarios. But the fact that it is a *browser* who acts as a client should not be our focus. If an app on a mobile platform wants to use the same technologies, for example, that should be fine with us even if it is not a "browser". I think that means we don't need to be quite so wrapped around the axle as to which hunk of code holds which functionality. We need to be clear which pieces of functionality we'll provide, but we should assume that continuing evolution may mean that some bit will move from app/browser to OS just as they are now moving from plugin to core application capability. Just two cents with no hats on, Ted