Hi, Another couple of 2 cents, :-). Browser are in my mind most definately a particular focus area here, and the prime one. This does not exclude the results to be applicable to also other client environments, but this IETF activity has a strong kinship with the efforts in enhancing the browser platform, as U indicate. This leads to the challenge of working closely with the browser manufacturers to make sure that the protocols evolve in par with the core elements and API's. I would hate having IETF do some nice work on protocols which are not implemented in browser core, :-). There are some other fancy stds organisations out there like JIL, BONDI, WAC and indeed some W3C groups that have a hard time getting the browser manufacturers to do their API's, :-). Now, IETF cannot be compared to such fora, but close synch with relevant 'authorities' is essential in this work in my opinion. And I expect pretty full feature browsers on mid and high end mobiles/smartphones pretty soon, :-). Best Regards Göran -----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Ted Hardie Sent: den 9 februari 2011 22:47 To: rtc-web@alvestrand.no Subject: [RTW] Axles we don't have to wrap ourselves around 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 _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web