From wwwrun@ietfa.amsl.com Tue May 3 09:37:41 2011 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 4AE9AE086B; Tue, 3 May 2011 09:37:41 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110503163741.4AE9AE086B@ietfa.amsl.com> Date: Tue, 3 May 2011 09:37:41 -0700 (PDT) Cc: ted.ietf@gmail.com, rtcweb@ietf.org Subject: [rtcweb] WG Action: Real-Time Communication in WEB-browsers (rtcweb) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 16:37:41 -0000 A new IETF working group has been formed in the Real-Time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. Real-Time Communication in WEB-browsers (rtcweb) --------------------------------------------------- Current Status: Active Working Group Chairs: Magnus Westerlund Cullen Jennings Ted Hardie Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: Address: rtcweb@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rtcweb Archive: http://www.ietf.org/mail-archive/web/rtcweb/ Description of Working Group: 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 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 identify 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. We will reach out to the developer community for consultation and early feedback on implementation. The security and privacy 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 need 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 and privacy goals and specifies the security protocol mechanisms necessary to achieve those goals. 3. Define the solution - protocols and API requirements - for firewall and NAT traversal. 4. Define which media 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. 7. Define how non media data is transported between clients in a secure and 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. 9. The group will consider options for interworking with legacy VoIP equipment. 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: RTSP, RSVP, NSIS, Location services, Resource Priority, and IM & Presence specific features. 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. Goals and Milestones: Aug 2011 Architecture, Security, Privacy and Threat Model sent to W3C Aug 2011 Use cases, Scenarios, and Requirements document (I-D) sent to W3C Sep 2011 Architecture and Security, Privacy, and Threat Model document(s) to IESG as Informational Sep 2011 Use cases, Scenarios, and Requirements for RTCWeb document sent to IESG as Informational Dec 2011 RTCWeb protocol profiles 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) From fluffy@cisco.com Tue May 3 10:33:11 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95D1E07E0 for ; Tue, 3 May 2011 10:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.603 X-Spam-Level: X-Spam-Status: No, score=-110.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUDyA2T1tGyT for ; Tue, 3 May 2011 10:33:11 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 26C29E0756 for ; Tue, 3 May 2011 10:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=722; q=dns/txt; s=iport; t=1304443991; x=1305653591; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=gkZTkv0SqV2j6Z2EdHD3DRignsIckLCGON8P0KeZAcY=; b=B79diXdCjKCv/WhMtjfZwrTaVTLaIQKBoQnawZpK8ux6BGD8BaKj7WF7 tronb0lNX7eGN9CLl4PW9Sv2ijZKBde02e6qGQh47lqj6l8ZzpLpFVIDq 7mo5D2ofKj+Luw+1lDeZIuYhdJOAo7gcoznD9gMt/QPsrDCX+31RVpOWN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMHACQ8wE2rRDoG/2dsb2JhbACYRo1Vd6gKnH+GAgSGJYhzhBqKNw X-IronPort-AV: E=Sophos;i="4.64,310,1301875200"; d="scan'208";a="349546233" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 03 May 2011 17:33:03 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p43HX1b7031503; Tue, 3 May 2011 17:33:02 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 3 May 2011 11:33:01 -0600 Message-Id: <21B5AA97-549A-4782-8E34-E04EF431D591@cisco.com> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Poll about an RTCWeb Interim Meeting - Due May 12th X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 17:33:12 -0000 I'm thrilled to see that the RTCWeb working group has been approved.=20 At the last IETF meeting, many people felt we should considering having = a virtual interim meeting for the IETF RTCWeb WG. Let us know which = dates could work for you. I have proposed four dates at the following = doodle pool. http://doodle.com/zf8wq624py96rkxx The meeting would likely be 3 or 4 hours long so it starts really early = if you live in Silicon valley and goes really late it you live in = Europe. Sorry. Please choose the dates that you would be able to attend = a virtual interim meeting. On May 12, we will look at the data from the = poll and try to pick an appropriate date.=20 Thanks, Cullen, Magnus & Ted From igor.faynberg@alcatel-lucent.com Tue May 3 10:57:38 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F70E0837 for ; Tue, 3 May 2011 10:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmoWtz5f7tLr for ; Tue, 3 May 2011 10:57:37 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id E61A1E0756 for ; Tue, 3 May 2011 10:57:36 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p43HvUVR012156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 May 2011 12:57:30 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p43HvUqM014030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 May 2011 12:57:30 -0500 Received: from [135.244.1.209] (faynberg.lra.lucent.com [135.244.1.209]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p43HvT6Z018454; Tue, 3 May 2011 12:57:29 -0500 (CDT) Message-ID: <4DC04203.9040907@alcatel-lucent.com> Date: Tue, 03 May 2011 13:57:23 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Cullen Jennings References: <21B5AA97-549A-4782-8E34-E04EF431D591@cisco.com> In-Reply-To: <21B5AA97-549A-4782-8E34-E04EF431D591@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Poll about an RTCWeb Interim Meeting - Due May 12th X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 17:57:38 -0000 Thanks for a thoughtful, multi-choice proposal! Igor Cullen Jennings wrote: > I'm thrilled to see that the RTCWeb working group has been approved. > > At the last IETF meeting, many people felt we should considering having a virtual interim meeting for the IETF RTCWeb WG. Let us know which dates could work for you. I have proposed four dates at the following doodle pool. > > http://doodle.com/zf8wq624py96rkxx > > The meeting would likely be 3 or 4 hours long so it starts really early if you live in Silicon valley and goes really late it you live in Europe. Sorry. Please choose the dates that you would be able to attend a virtual interim meeting. On May 12, we will look at the data from the poll and try to pick an appropriate date. > > Thanks, Cullen, Magnus & Ted > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From hardie@ipinfusion.com Tue May 3 17:04:43 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90861E06C2 for ; Tue, 3 May 2011 17:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1ykOutzIErq for ; Tue, 3 May 2011 17:04:43 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27644E0674 for ; Tue, 3 May 2011 17:04:43 -0700 (PDT) Received: by pzk5 with SMTP id 5so329053pzk.31 for ; Tue, 03 May 2011 17:04:42 -0700 (PDT) Received: by 10.68.7.41 with SMTP id g9mr672647pba.148.1304467482772; Tue, 03 May 2011 17:04:42 -0700 (PDT) Received: from [10.10.0.100] ([65.223.109.250]) by mx.google.com with ESMTPS id b4sm344894pbo.80.2011.05.03.17.04.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2011 17:04:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Ted Hardie Date: Tue, 3 May 2011 17:07:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: hardie@ipinfusion.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 00:04:43 -0000 As you will have seen from Cullen's announcement, we are now officially = a working group and starting to collect data on the possible timing of = an interim meeting.=20 For the interim meeting, we want to start work on the chartered = deliverables. If you are interested in being an editor for one of the = working group docs, the chairs would like you to prepare something for = the Interim as a draft-00 of your take. If you can, raise your hand on = the list to say you're doing so, so as to let others know to talk to you = about collaborating. If you are not able to attend any of the times put = forward for the interim, you can still volunteer to edit a document--it = just means you'll have to have the -00 done early enough for the chairs = to find a stuckee for feedback coming in at the interim. regards, Ted, Cullen, and Magnus= From matthew.kaufman@skype.net Tue May 3 17:09:24 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79FAE06D3 for ; Tue, 3 May 2011 17:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sv4zc+LkGDKE for ; Tue, 3 May 2011 17:09:20 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1A6E06C2 for ; Tue, 3 May 2011 17:09:20 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 1D55D1717; Wed, 4 May 2011 02:09:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=FAuIGAIfmp4jTf /ujgsbjaSy+8E=; b=S89d5yCrB7YWrRfNX+McNdBgWpBF25SR7gMFdyvB9nPRCx LTV77gfy8VV4kij+FGzHD0lpUiECnRKg1Sbqk0fNaJdWYzLxwQiJNHrZK4Ompv+v eC2ZiQQm3mDTo7VpuVa69nIr+LZm64o/vMUOnBETAr2foab6IO5Lt6Q7NLS/c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=lglSAvL1eJ2rWiYZxpRno8 1SHEbQe45mQODDrZ1T97gR/OWy7DcrPtrepn7eA+0eE3GKFLdtq9JFillKMR76wh smrkH3TYvMS/nL1js2n4G1p1BczocrD1QHjiPb1F45luw0J1YvuG4s8CHb7aWtI2 PFHkjYh/IENk1bUxeMrBk= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 1BE637F6; Wed, 4 May 2011 02:09:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 0002A3506F84; Wed, 4 May 2011 02:09:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYYD8Z8+tDa1; Wed, 4 May 2011 02:09:18 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id D67D83506F37; Wed, 4 May 2011 02:09:17 +0200 (CEST) Message-ID: <4DC09923.4070702@skype.net> Date: Tue, 03 May 2011 17:09:07 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: hardie@ipinfusion.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 00:09:24 -0000 On 5/3/2011 5:07 PM, Ted Hardie wrote: > As you will have seen from Cullen's announcement, we are now officially a working group and starting to collect data on the possible timing of an interim meeting. > > For the interim meeting, we want to start work on the chartered deliverables. If you are interested in being an editor for one of the working group docs, the chairs would like you to prepare something for the Interim as a draft-00 of your take. If you can, raise your hand on the list to say you're doing so, so as to let others know to talk to you about collaborating. I have started poking at charter item #3 "Define the solution - protocols and API requirements - for firewall and NAT traversal" to the point of starting a draft of my thoughts towards creating the browser-side requirements to support this. Whether or not I have enough cycles to prepare a complete draft for the interim meeting is another story... if anyone else has put thought into this item lets get in touch. Matthew Kaufman From harald@alvestrand.no Wed May 4 05:29:51 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB23E073D for ; Wed, 4 May 2011 05:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-Sa80+azatm for ; Wed, 4 May 2011 05:29:45 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 59E20E0682 for ; Wed, 4 May 2011 05:29:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9DBBE39E202; Wed, 4 May 2011 14:28:56 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZWibDcUqkaT; Wed, 4 May 2011 14:28:55 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 5F5FF39E1D1; Wed, 4 May 2011 14:28:55 +0200 (CEST) Message-ID: <4DC146B5.6080407@alvestrand.no> Date: Wed, 04 May 2011 14:29:41 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: hardie@ipinfusion.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 12:29:51 -0000 I will offer an update to draft-alvestrand-dispatch-rtcweb-protocols as a candidate for the group's "overview/architecture" document. I'm not sure it makes sense to continue with draft-alvestrand-dispatch-rtcweb-datagram at this time. Harald On 05/04/11 02:07, Ted Hardie wrote: > As you will have seen from Cullen's announcement, we are now officially a working group and starting to collect data on the possible timing of an interim meeting. > > For the interim meeting, we want to start work on the chartered deliverables. If you are interested in being an editor for one of the working group docs, the chairs would like you to prepare something for the Interim as a draft-00 of your take. If you can, raise your hand on the list to say you're doing so, so as to let others know to talk to you about collaborating. If you are not able to attend any of the times put forward for the interim, you can still volunteer to edit a document--it just means you'll have to have the -00 done early enough for the chairs to find a stuckee for feedback coming in at the interim. > > regards, > > Ted, Cullen, and Magnus > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From dzonatas@gmail.com Wed May 4 18:23:29 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CAAE067E for ; Wed, 4 May 2011 18:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.78 X-Spam-Level: X-Spam-Status: No, score=-3.78 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac+u6Zw56QZc for ; Wed, 4 May 2011 18:23:28 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id AA327E0669 for ; Wed, 4 May 2011 18:23:28 -0700 (PDT) Received: by pxi2 with SMTP id 2so1071087pxi.38 for ; Wed, 04 May 2011 18:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=SuBlaB0ZbTnbtiUpnZKJyo+zWYxKZk8hiAGRkeQuBGw=; b=Tgil852vkKpKpWNCeQpKRCZQnsOwrJI4m49TPq9ZNGoQ9v/zLW34/R5aQ07mwRD0Yd eqz4kkhaXtQd/FXGXkkgBg4mbxnX31Z+b8hqf4uTW5wVC/GEXNo8rcDEqnPUb1dy+cYd OW9UD9NGPmRkP6jh7sf8bt2MC6paVJPRLk1pc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=m6Riu33Sde9QzM4mL6Xnm3RSDmrX/Qy9tIN1b1d798wvE+GYvlHm9SwzzJwUPfdDma AolCTXCswc7yCv7zx5gnj3Lvqw5vWc/6viTxGuex5WpFSnO8F+px8vBXLBNQ/RzLOdqc 9FG7I5rsOG0sIQk0EMG1xvjqYL7Ir7QzcSBa4= Received: by 10.68.44.227 with SMTP id h3mr2463586pbm.245.1304558608067; Wed, 04 May 2011 18:23:28 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id o3sm1080380pbt.61.2011.05.04.18.23.26 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2011 18:23:27 -0700 (PDT) Message-ID: <4DC1FBCF.1090903@gmail.com> Date: Wed, 04 May 2011 18:22:23 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 01:23:30 -0000 Hi, I've read the acceptance e-mail: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg08829.html "RTP functionalities, media formats, security algorithms are example of things that commonly need extensions, additions or replacement, and thus some support for negotiation between clients is required." At a glance, I thought this sounded like "Real-Time Compositing" from the frame and media complexes of IETF VWRAP WG. I'm not immediately aware of any web-browser that features hardware-compositors, which would help avoid some endless transistions. Hypervisors did come to mind, however. I'm the scientist, so I can help the doctors on this WG. Also, this was hinted to me: http://100yearstarshipstudy.com/ .NET version of original UNIX under Hypervisor mode with X Windows seems like the bootstrap station for this WG. YMMV... -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From magnus.westerlund@ericsson.com Thu May 5 02:22:20 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03462E0693 for ; Thu, 5 May 2011 02:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKhfjp6Z-OpD for ; Thu, 5 May 2011 02:22:19 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id E7EB8E067B for ; Thu, 5 May 2011 02:22:18 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-61-4dc26c49cd69 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 97.17.11171.94C62CD4; Thu, 5 May 2011 11:22:17 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 5 May 2011 11:22:16 +0200 Message-ID: <4DC26C48.7040604@ericsson.com> Date: Thu, 5 May 2011 11:22:16 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dzonatas Sol References: <4DC1FBCF.1090903@gmail.com> In-Reply-To: <4DC1FBCF.1090903@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 09:22:20 -0000 On 2011-05-05 03:22, Dzonatas Sol wrote: > Hi, > > I've read the acceptance e-mail: > http://www.ietf.org/mail-archive/web/ietf-announce/current/msg08829.html > > "RTP functionalities, media formats, security algorithms are example of > things that commonly need extensions, additions or replacement, and > thus some support for negotiation between clients is required." > > At a glance, I thought this sounded like "Real-Time Compositing" from > the frame and media complexes of IETF VWRAP WG. I'm not immediately > aware of any web-browser that features hardware-compositors, which would > help avoid some endless transistions. Hypervisors did come to mind, however. To my understanding and I would say intention as I was part of writing that text line is that it concerns the need for having signalling, capability and negotiation mechanism for having the peers to agree on what is to be used. For example a peer may implement multiple video codecs. They need to negotiation at least to which is the common set between the peers. In security one may have several encryption algorithms and key lengths in a protocol. Even if one selects only one today this is a case where we know that tomorrow some vulnerability may be discovered and thus requiring everyone to promptly deploy a new one. When it comes to VWRAP I think there are some potential overlapp in underlying technology. Not following VWRAP I don't know if they are creating something new or are considering RTP for position information in a virtual world which definitely is a real-time media. If you believe there is overlap with VWRAP can you please be a bit more verbose on what that overlap consists of. I do fail to understand the meaning of the rest of your comments. Best Regards Magnus Westerlund > > I'm the scientist, so I can help the doctors on this WG. > > Also, this was hinted to me: http://100yearstarshipstudy.com/ > > .NET version of original UNIX under Hypervisor mode with X Windows seems > like the bootstrap station for this WG. YMMV... > -- 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 ---------------------------------------------------------------------- From dzonatas@gmail.com Thu May 5 06:18:25 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C64E0724 for ; Thu, 5 May 2011 06:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.77 X-Spam-Level: X-Spam-Status: No, score=-3.77 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkVW-moZN+RC for ; Thu, 5 May 2011 06:18:24 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 53BC5E06DC for ; Thu, 5 May 2011 06:18:24 -0700 (PDT) Received: by pwi5 with SMTP id 5so1276925pwi.31 for ; Thu, 05 May 2011 06:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AK8W3AuThhvCU4ibfDZTtSXDylOyqoHEV54bFP+3OFY=; b=KVFkP2M88dwf5MQOc0seyRdwt+MTXi6C1dHyPpP/i8XgrKdPu9TO5lTYKAoK+48P6C 698MJKS5bATWztIJIEVyoad9I5eFM6A73NARZtd/HNCjjNk9M0M2ZYMRZiSXD6/LqA0V ywA4DT5SqmzIEOsrEjlF7FQ3iw2mlzM0oBcPg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Q3FyHqiW9WzuUghZpoAvuywdEBdZAYK5HRIzUGxiITHiBi4nqh/Wfv+tFE81P4Qxx0 yZgcqAXMZR4JWrGOa9TH4i6sLeha3KhCn7Is1HIwkTkPsn5MwEbTttQAZPMKQVbJBZ/T VceVjnwniMG/1N7oncDqmtb601vSGrOfviVMA= Received: by 10.68.31.197 with SMTP id c5mr3330063pbi.247.1304601503833; Thu, 05 May 2011 06:18:23 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id h7sm1431722pbg.74.2011.05.05.06.18.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2011 06:18:22 -0700 (PDT) Message-ID: <4DC2A35F.607@gmail.com> Date: Thu, 05 May 2011 06:17:19 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Magnus Westerlund References: <4DC1FBCF.1090903@gmail.com> <4DC26C48.7040604@ericsson.com> In-Reply-To: <4DC26C48.7040604@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 13:18:25 -0000 Thanks for the reply, On 05/05/2011 02:22 AM, Magnus Westerlund wrote: > On 2011-05-05 03:22, Dzonatas Sol wrote: > >> Hi, >> >> I've read the acceptance e-mail: >> http://www.ietf.org/mail-archive/web/ietf-announce/current/msg08829.html >> >> "RTP functionalities, media formats, security algorithms are example of >> things that commonly need extensions, additions or replacement, and >> thus some support for negotiation between clients is required." >> >> At a glance, I thought this sounded like "Real-Time Compositing" from >> the frame and media complexes of IETF VWRAP WG. I'm not immediately >> aware of any web-browser that features hardware-compositors, which would >> help avoid some endless transistions. Hypervisors did come to mind, however. >> > To my understanding and I would say intention as I was part of writing > that text line is that it concerns the need for having signalling, > capability and negotiation mechanism for having the peers to agree on > what is to be used. > Yes, given an example of an multiple applications that each support RESTful queues and HTTP servers on the same home network, there is commercial concern if these too easily breached because the home firewall may not be trusted as the commercial firewall. That is subject to opinion, yet it is an area that we haven't seen such end to negotiation. Thus, more extensions interfere with interoperability, especially if the commercial server will ensure assets in the hands of the home user. > > When it comes to VWRAP I think there are some potential overlapp in > underlying technology. Not following VWRAP I don't know if they are > creating something new or are considering RTP for position information > in a virtual world which definitely is a real-time media. > VWRAP has gone through few make-overs, already, in concerns of architectural WGs. Linden Labs has been key with the VW Second Life, and whose original founder worked previously with Real. The Second Life application is open source and features media plug-ins (for web-media/web-browser on 3D polygons/primitives). The movement away from monolithic designs, of both SL and web-browser, has been slow, yet effort doesn't stop. This involves several layers at various scales. > If you believe there is overlap with VWRAP can you please be a bit more > verbose on what that overlap consists of. > > I do fail to understand the meaning of the rest of your comments. > > Best Regards > > Magnus Westerlund > No problem, as I mainly stated, expectantly, that if we relate to the depth at scale given the language used already. Original UNIX is known for real-time applications do to its time-slice capabilities. Many have emulated UNIX for compatibility, yet they don't guarantee such real-time scale or such quantums. We could relate X Windows as "a 3D browser" and so further web-browsers on the web make this appears as a browser in a browser, and so on. I think the original UNIX had the right idea to help avoid turtle on turtles, yet the hardware-means didn't exist in earlier processors on the market. Now they do, and today people use emulated modes within emulated modes. Not that they are wrong in their direction, yet computation power is of concern with that trend. Power effects timing. > >> I'm the scientist, so I can help the doctors on this WG. >> >> Also, this was hinted to me: http://100yearstarshipstudy.com/ >> >> .NET version of original UNIX under Hypervisor mode with X Windows seems >> like the bootstrap station for this WG. YMMV... >> >> > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From csp@csperkins.org Thu May 5 15:20:00 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E39E07D6 for ; Thu, 5 May 2011 15:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dClCFcupTjRo for ; Thu, 5 May 2011 15:19:59 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id AE0F5E074D for ; Thu, 5 May 2011 15:19:59 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.5]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QI6tq-0002ru-bS; Thu, 05 May 2011 22:19:58 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Thu, 5 May 2011 23:19:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <32372E0F-2F58-4B7B-A9EF-918D3A5BD553@csperkins.org> References: To: hardie@ipinfusion.com X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 22:20:00 -0000 On 4 May 2011, at 01:07, Ted Hardie wrote: > As you will have seen from Cullen's announcement, we are now = officially a working group and starting to collect data on the possible = timing of an interim meeting.=20 >=20 > For the interim meeting, we want to start work on the chartered = deliverables. If you are interested in being an editor for one of the = working group docs, the chairs would like you to prepare something for = the Interim as a draft-00 of your take. If you can, raise your hand on = the list to say you're doing so, so as to let others know to talk to you = about collaborating. If you are not able to attend any of the times put = forward for the interim, you can still volunteer to edit a document--it = just means you'll have to have the -00 done early enough for the chairs = to find a stuckee for feedback coming in at the interim. We're planning an update to draft-perkins-rtcweb-rtp-usage-00 before the = interim. This a candidate document for work item 4 from the charter: Define which media functions and extensions shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. Cheers, Colin --=20 Colin Perkins http://csperkins.org/ From dzonatas@gmail.com Thu May 5 20:38:47 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E120CE0753 for ; Thu, 5 May 2011 20:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MCqRk098edx for ; Thu, 5 May 2011 20:38:47 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B194E0751 for ; Thu, 5 May 2011 20:38:47 -0700 (PDT) Received: by pwi5 with SMTP id 5so1638729pwi.31 for ; Thu, 05 May 2011 20:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=n8X8lTesXLu68SSdCRTiABIbbDkZQ6g9X027x7ou58A=; b=LU84OQrh3Zj2UsVn5HSj7OgeIiwu+vA+7jfahvk3TX7ljlEWOEOlpPA4F7CkWzM2Hp uOo9ao2NoGCaeV+RvR8vtdsbNPTQnBg2pYqRWQQ8/T+m3cFRKPW0RsiZ3kLaqIQDFLuv qEJnTnh4LbSUDbT0mmO5JPq4SNfC8uYRFOqnw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=i/FPJHjjVVaRSki/eWQIs8OMEhpOaxjQdEZHE1DWVka1qtrhmHr9FM8LWdzkxTC4tc pqnQXL4Yg2sUfUFDbojcrnV9BZFO8SQBE718Z1AlWDUM0cr/35W6NpKygeqXxoTsjsjB weBWUsU76EdIqhUYb1Kdpmzpxc2UH+xQ/ltBA= Received: by 10.142.234.18 with SMTP id g18mr1613015wfh.104.1304653126478; Thu, 05 May 2011 20:38:46 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id w14sm3607917wfh.20.2011.05.05.20.38.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2011 20:38:45 -0700 (PDT) Message-ID: <4DC36D06.50605@gmail.com> Date: Thu, 05 May 2011 20:37:42 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <32372E0F-2F58-4B7B-A9EF-918D3A5BD553@csperkins.org> In-Reply-To: <32372E0F-2F58-4B7B-A9EF-918D3A5BD553@csperkins.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 03:38:48 -0000 On 05/05/2011 03:19 PM, Colin Perkins wrote: > > We're planning an update to draft-perkins-rtcweb-rtp-usage-00 before the interim. This a candidate document for work item 4 from the charter: > > Define which media functions and extensions shall be supported in > the client and their usage for real-time media, including media > adaptation to ensure congestion safe usage. > > Cheers, > Colin > > > I noticed within http://tools.ietf.org/id/draft-perkins-rtcweb-rtp-usage-00.txt that section 2 covers multiplexing. One item that may be of interest to bring into scope, from general multicasting (already denoted out of scope), is if the desired multicast-ability is within frame-complexes. I comprehend the concern to leave general multicasting out of discussion, so I have no argument there. My concern is more about shared memory and being able to stage frames across multiple clients (ideally on the same network or computer in the RESTful paradigm). Even the simple review of RTP usage reveal others that desire shared memory across virtualization, which fallbacks to shared memory even if "frames" aren't mentioned in general. This is even more common now with virtualization of media surfaces. Frames then take on the role of to hold multiple regions where each region may be updated separately by multiple clients. In this in-frame scenario is where multicast is automatically back in scope in communication to each client that has some role in the single frame. This is not an argument to bring multicast fully back in scope, yet more for the similarity where shared memory is more obviously needed/requested for RTP Frames. Perhaps, there is another terminology we can refer to this besides multicast since the "client/server" roles can flip/flop and not make much sense (especially to convey in documentation) to use either "client" or "server" when that flip/flop happens often enough. Other WGs have used forward flow and reverse flow after the client establishes initial connection (and both roles becomes moot-to-point), as they are seen as just end-points. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From harald@alvestrand.no Fri May 6 05:19:07 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77895E06C5 for ; Fri, 6 May 2011 05:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaMlc-A37Yxa for ; Fri, 6 May 2011 05:19:06 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id BA73AE064B for ; Fri, 6 May 2011 05:19:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B5D9639E123 for ; Fri, 6 May 2011 14:18:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHM+Nrj-l-4V for ; Fri, 6 May 2011 14:18:17 +0200 (CEST) Received: from [172.16.40.184] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C9CF939E08B for ; Fri, 6 May 2011 14:18:16 +0200 (CEST) Message-ID: <4DC3E731.6040401@alvestrand.no> Date: Fri, 06 May 2011 14:18:57 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: rtcweb@ietf.org References: <32372E0F-2F58-4B7B-A9EF-918D3A5BD553@csperkins.org> <4DC36D06.50605@gmail.com> In-Reply-To: <4DC36D06.50605@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 12:19:07 -0000 On 05/06/11 05:37, Dzonatas Sol wrote: > > I noticed within > http://tools.ietf.org/id/draft-perkins-rtcweb-rtp-usage-00.txt that > section 2 covers multiplexing. One item that may be of interest to > bring into scope, from general multicasting (already denoted out of > scope), is if the desired multicast-ability is within frame-complexes. > I comprehend the concern to leave general multicasting out of > discussion, so I have no argument there. My concern is more about > shared memory and being able to stage frames across multiple clients > (ideally on the same network or computer in the RESTful paradigm). > > Even the simple review of RTP usage reveal others that desire shared > memory across virtualization, which fallbacks to shared memory even if > "frames" aren't mentioned in general. This is even more common now > with virtualization of media surfaces. Frames then take on the role of > to hold multiple regions where each region may be updated separately > by multiple clients. In this in-frame scenario is where multicast is > automatically back in scope in communication to each client that has > some role in the single frame. This is not an argument to bring > multicast fully back in scope, yet more for the similarity where > shared memory is more obviously needed/requested for RTP Frames. If the charter can be read to make shared-memory models (the way the term "shared memory" is commonly used - with hardware accessible on the microsecond timescale) in scope, I think we have not formulated the charter well. Synchronization of state is important for many kinds of applications, and I'm sure we'll get to primitives that are useful for that sooner or later, but I don't want to discuss "shared memory" paradigms. Harald From dzonatas@gmail.com Fri May 6 06:49:48 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F112E072F for ; Fri, 6 May 2011 06:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.675 X-Spam-Level: X-Spam-Status: No, score=-3.675 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW5ThFg8dH76 for ; Fri, 6 May 2011 06:49:47 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB476E067A for ; Fri, 6 May 2011 06:49:46 -0700 (PDT) Received: by pwi5 with SMTP id 5so1878989pwi.31 for ; Fri, 06 May 2011 06:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=L8tZ0n3gmKIW242c8LLNTQEz7wRB7g9X70Tkrlpb4UY=; b=RrtTgrZeVXgCbvQriWah18xHgZEDTDBDYarICUx+iQ0c9b5umdosJRuZxL05SumnSC BIBSWMys4JAQaHE4X6QVVCQqDVnKbB8ywEiT6yPw3cjv13fphmGlLQrtC45pwvC6RvIh zu/7WuFh8ogc2rsBoP/TZHqwWzGMlwpKJWvIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=dFt3dKBEVoiSg3xdrRug3jABwckU087PFAeIvqfRyLkxFAmBFE8tD5LvXmzmvWKFd/ BNY7TEIS7Nf2D5pzvzXgOAR3E0qkjfbynar2YViXxI+2/TMrnNLCI+WR/tKLb1zaCOom dV8+oBo2MVcUAeBA7rEtbBXNRWyFbquMVe+5I= Received: by 10.68.32.231 with SMTP id m7mr4990852pbi.200.1304689786372; Fri, 06 May 2011 06:49:46 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id g3sm1552605pbk.82.2011.05.06.06.49.44 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 May 2011 06:49:45 -0700 (PDT) Message-ID: <4DC3FC3B.2020209@gmail.com> Date: Fri, 06 May 2011 06:48:43 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <32372E0F-2F58-4B7B-A9EF-918D3A5BD553@csperkins.org> <4DC36D06.50605@gmail.com> <4DC3E731.6040401@alvestrand.no> In-Reply-To: <4DC3E731.6040401@alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 13:49:48 -0000 On 05/06/2011 05:18 AM, Harald Alvestrand wrote: > On 05/06/11 05:37, Dzonatas Sol wrote: >> >> I noticed within >> http://tools.ietf.org/id/draft-perkins-rtcweb-rtp-usage-00.txt that >> section 2 covers multiplexing. One item that may be of interest to >> bring into scope, from general multicasting (already denoted out of >> scope), is if the desired multicast-ability is within >> frame-complexes. I comprehend the concern to leave general >> multicasting out of discussion, so I have no argument there. My >> concern is more about shared memory and being able to stage frames >> across multiple clients (ideally on the same network or computer in >> the RESTful paradigm). >> >> Even the simple review of RTP usage reveal others that desire shared >> memory across virtualization, which fallbacks to shared memory even >> if "frames" aren't mentioned in general. This is even more common now >> with virtualization of media surfaces. Frames then take on the role >> of to hold multiple regions where each region may be updated >> separately by multiple clients. In this in-frame scenario is where >> multicast is automatically back in scope in communication to each >> client that has some role in the single frame. This is not an >> argument to bring multicast fully back in scope, yet more for the >> similarity where shared memory is more obviously needed/requested for >> RTP Frames. > If the charter can be read to make shared-memory models (the way the > term "shared memory" is commonly used - with hardware accessible on > the microsecond timescale) in scope, I think we have not formulated > the charter well. > > Synchronization of state is important for many kinds of applications, > and I'm sure we'll get to primitives that are useful for that sooner > or later, but I don't want to discuss "shared memory" paradigms. > Thanks. The word "region" appears more applicable than "shared memory" or "synchronization". Let the word "region" identifies the transition within staged frames. The concept of multiple regions within the RTP frame, and the frame succession of frame by frame over time, will do just enough for now with expectation to only "multicast" the regions within the given frame. The assumption can then be made regions are volatile in variable microseconds, yet default upon the update of the frame. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Fri May 6 07:08:19 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DE1E0737 for ; Fri, 6 May 2011 07:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.671 X-Spam-Level: X-Spam-Status: No, score=-3.671 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtsoMgpHQ1L1 for ; Fri, 6 May 2011 07:08:18 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3432DE0721 for ; Fri, 6 May 2011 07:08:18 -0700 (PDT) Received: by pzk5 with SMTP id 5so1883464pzk.31 for ; Fri, 06 May 2011 07:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/nK7BR+Nv4iZo3ssb9Y2i0D/BfK+7eFvm87FZ9mVvVg=; b=Esm/FBfFmuIfRav0S0XICzquLkWmt6D5U87JGaN8cWP6IiRGu5PYZ37bapYZiHvAR5 Ovzd4+e2pcFy8DYwAWs3s3Wrp5tIWqtMlUp4MU+LfJNfDpGINrFb/CwllN9MiKYCIxHl yNP14ixIMLFAgUFIqNzL3UcN+zBnGWcDpOk7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=jDnLokQDZvQRGYH6H/gOg5ApNvPuQKRscHpQjD147MN5HujIfSwz8C6aArONB4WDPN +S3btjk7gRGMDd+E8AyDafFYxwKGHthbd29BNcl4OnJI1sxS8A9HABQphr78IWs7H6FA MXFkwr9vVkR8t+CUGjPGTtkbyqmzZIQvRi2jY= Received: by 10.68.50.161 with SMTP id d1mr5004561pbo.439.1304690897780; Fri, 06 May 2011 07:08:17 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id t9sm2166778pbq.31.2011.05.06.07.08.16 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 May 2011 07:08:17 -0700 (PDT) Message-ID: <4DC40093.1030603@gmail.com> Date: Fri, 06 May 2011 07:07:15 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Dzonatas Sol References: <32372E0F-2F58-4B7B-A9EF-918D3A5BD553@csperkins.org> <4DC36D06.50605@gmail.com> <4DC3E731.6040401@alvestrand.no> <4DC3FC3B.2020209@gmail.com> In-Reply-To: <4DC3FC3B.2020209@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 14:08:19 -0000 On 05/06/2011 06:48 AM, Dzonatas Sol wrote: > On 05/06/2011 05:18 AM, Harald Alvestrand wrote: >> On 05/06/11 05:37, Dzonatas Sol wrote: >>> >>> I noticed within >>> http://tools.ietf.org/id/draft-perkins-rtcweb-rtp-usage-00.txt that >>> section 2 covers multiplexing. One item that may be of interest to >>> bring into scope, from general multicasting (already denoted out of >>> scope), is if the desired multicast-ability is within >>> frame-complexes. I comprehend the concern to leave general >>> multicasting out of discussion, so I have no argument there. My >>> concern is more about shared memory and being able to stage frames >>> across multiple clients (ideally on the same network or computer in >>> the RESTful paradigm). >>> >>> Even the simple review of RTP usage reveal others that desire shared >>> memory across virtualization, which fallbacks to shared memory even >>> if "frames" aren't mentioned in general. This is even more common >>> now with virtualization of media surfaces. Frames then take on the >>> role of to hold multiple regions where each region may be updated >>> separately by multiple clients. In this in-frame scenario is where >>> multicast is automatically back in scope in communication to each >>> client that has some role in the single frame. This is not an >>> argument to bring multicast fully back in scope, yet more for the >>> similarity where shared memory is more obviously needed/requested >>> for RTP Frames. >> If the charter can be read to make shared-memory models (the way the >> term "shared memory" is commonly used - with hardware accessible on >> the microsecond timescale) in scope, I think we have not formulated >> the charter well. >> >> Synchronization of state is important for many kinds of applications, >> and I'm sure we'll get to primitives that are useful for that sooner >> or later, but I don't want to discuss "shared memory" paradigms. >> > > Thanks. The word "region" appears more applicable than "shared memory" > or "synchronization". Let the word "region" identifies the transition > within staged frames. The concept of multiple regions within the RTP > frame, and the frame succession of frame by frame over time, will do > just enough for now with expectation to only "multicast" the regions > within the given frame. The assumption can then be made regions are > volatile in variable microseconds, yet default upon the update of the > frame. > This use-case may help convey this further: at the edge of the blackbox, assume end-point-A has an asset it doesn't want to share with the other end-points, yet given access to the frame then end-points-A can render to the media its asset while other end-points do the same with their assets they don't want to openly share. The end-points need to identify their region and when each region is volatile. Further multiplexing can either be done by proxy or where one end-points acts like the host to the other end-points as guest. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Fri May 6 07:36:01 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FD2E0747 for ; Fri, 6 May 2011 07:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.668 X-Spam-Level: X-Spam-Status: No, score=-3.668 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWQ4GESqG3Ci for ; Fri, 6 May 2011 07:36:01 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id F2F53E073C for ; Fri, 6 May 2011 07:36:00 -0700 (PDT) Received: by pxi2 with SMTP id 2so2008418pxi.38 for ; Fri, 06 May 2011 07:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cm1rtdOhTSZyK50R2PqtSRRVTZTlkE/ntcL9zs+Lfqo=; b=LLCG999XkvFB6Ir2YwLS3HE8dyhEtV2490987KlWcD2td+WRVLIY3XBbk7qRA0KuQT AOPBUg4FTi20d7wKtat3OpnVMWnNGhXjeyvjdzJiU0p8pzd9jztoxdHF0VFdi/fjCtiN KvpK31EZpmPXdJYqP5dPp8HX688TQOQcu3p1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=hklkuKRwdc+zwB1lrJYqk5HT9ByDYK10ndhSfkQWcnGdxWmjm4fpfi7Ivl4asPY+5C T9W0LaQrDCj++RRGWtkaVTHcmq2UhMPANtdY0HIszXh+aEBQ70J69fNHs9V4byFfGccS EEBnu5ziM/r31JsiMzdXGq/QHgj4gvnXeafDM= Received: by 10.68.55.163 with SMTP id t3mr4870536pbp.281.1304692560629; Fri, 06 May 2011 07:36:00 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id q10sm2178950pbk.39.2011.05.06.07.35.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 May 2011 07:35:59 -0700 (PDT) Message-ID: <4DC40711.8050000@gmail.com> Date: Fri, 06 May 2011 07:34:57 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Magnus Westerlund References: <4DC1FBCF.1090903@gmail.com> <4DC26C48.7040604@ericsson.com> <4DC2A35F.607@gmail.com> <4DC4047F.9060209@ericsson.com> In-Reply-To: <4DC4047F.9060209@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 14:36:02 -0000 Please review the use-case I just posted: http://www.ietf.org/mail-archive/web/rtcweb/current/msg00057.html I'm not sure if you say that as you seen this. If that is not clear enough, I can answer more questions off-list. With that use-case, however, assume there is no specific perspective, like page mode or such, so I want to avoid explanation of that complexity. With the ReSTful paradigm, we can shift matters that fall out of scope into other capabilities. Thanks. On 05/06/2011 07:23 AM, Magnus Westerlund wrote: > Sorry, > > I can't make head and tails of your comments. They contain words that > could be relevant but I can't determine what your actual argument or > position is from it. > > Can you please be more specific and clear on what your point of argument > is. What is the intention of your comments? > > best regards > > Magnus > > > On 2011-05-05 15:17, Dzonatas Sol wrote: > >> Thanks for the reply, >> >> On 05/05/2011 02:22 AM, Magnus Westerlund wrote: >> >>> On 2011-05-05 03:22, Dzonatas Sol wrote: >>> >>> >>>> Hi, >>>> >>>> I've read the acceptance e-mail: >>>> http://www.ietf.org/mail-archive/web/ietf-announce/current/msg08829.html >>>> >>>> "RTP functionalities, media formats, security algorithms are example of >>>> things that commonly need extensions, additions or replacement, and >>>> thus some support for negotiation between clients is required." >>>> >>>> At a glance, I thought this sounded like "Real-Time Compositing" from >>>> the frame and media complexes of IETF VWRAP WG. I'm not immediately >>>> aware of any web-browser that features hardware-compositors, which would >>>> help avoid some endless transistions. Hypervisors did come to mind, however. >>>> >>>> >>> To my understanding and I would say intention as I was part of writing >>> that text line is that it concerns the need for having signalling, >>> capability and negotiation mechanism for having the peers to agree on >>> what is to be used. >>> >>> >> >> Yes, given an example of an multiple applications that each support >> RESTful queues and HTTP servers on the same home network, there is >> commercial concern if these too easily breached because the home >> firewall may not be trusted as the commercial firewall. That is subject >> to opinion, yet it is an area that we haven't seen such end to >> negotiation. Thus, more extensions interfere with interoperability, >> especially if the commercial server will ensure assets in the hands of >> the home user. >> >> >> >> >> >>> When it comes to VWRAP I think there are some potential overlapp in >>> underlying technology. Not following VWRAP I don't know if they are >>> creating something new or are considering RTP for position information >>> in a virtual world which definitely is a real-time media. >>> >>> >> VWRAP has gone through few make-overs, already, in concerns of >> architectural WGs. Linden Labs has been key with the VW Second Life, and >> whose original founder worked previously with Real. The Second Life >> application is open source and features media plug-ins (for >> web-media/web-browser on 3D polygons/primitives). The movement away from >> monolithic designs, of both SL and web-browser, has been slow, yet >> effort doesn't stop. >> >> This involves several layers at various scales. >> >> >> >> >>> If you believe there is overlap with VWRAP can you please be a bit more >>> verbose on what that overlap consists of. >>> >>> I do fail to understand the meaning of the rest of your comments. >>> >>> Best Regards >>> >>> Magnus Westerlund >>> >>> >> No problem, as I mainly stated, expectantly, that if we relate to the >> depth at scale given the language used already. Original UNIX is known >> for real-time applications do to its time-slice capabilities. Many have >> emulated UNIX for compatibility, yet they don't guarantee such real-time >> scale or such quantums. We could relate X Windows as "a 3D browser" and >> so further web-browsers on the web make this appears as a browser in a >> browser, and so on. >> >> I think the original UNIX had the right idea to help avoid turtle on >> turtles, yet the hardware-means didn't exist in earlier processors on >> the market. Now they do, and today people use emulated modes within >> emulated modes. >> >> Not that they are wrong in their direction, yet computation power is of >> concern with that trend. >> >> Power effects timing. >> >> >> >> >>> >>> >>>> I'm the scientist, so I can help the doctors on this WG. >>>> >>>> Also, this was hinted to me: http://100yearstarshipstudy.com/ >>>> >>>> .NET version of original UNIX under Hypervisor mode with X Windows seems >>>> like the bootstrap station for this WG. YMMV... >>>> >>>> >>>> >>> >>> >> >> > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From magnus.westerlund@ericsson.com Fri May 6 07:39:07 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA92E073C for ; Fri, 6 May 2011 07:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z187k0Y3VM1Z for ; Fri, 6 May 2011 07:39:03 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 14F11E06EA for ; Fri, 6 May 2011 07:39:02 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-99-4dc4047f6d47 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D5.14.28525.F7404CD4; Fri, 6 May 2011 16:24:00 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Fri, 6 May 2011 16:23:59 +0200 Message-ID: <4DC4047F.9060209@ericsson.com> Date: Fri, 6 May 2011 16:23:59 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Dzonatas Sol References: <4DC1FBCF.1090903@gmail.com> <4DC26C48.7040604@ericsson.com> <4DC2A35F.607@gmail.com> In-Reply-To: <4DC2A35F.607@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 14:39:07 -0000 Sorry, I can't make head and tails of your comments. They contain words that could be relevant but I can't determine what your actual argument or position is from it. Can you please be more specific and clear on what your point of argument is. What is the intention of your comments? best regards Magnus On 2011-05-05 15:17, Dzonatas Sol wrote: > Thanks for the reply, > > On 05/05/2011 02:22 AM, Magnus Westerlund wrote: >> On 2011-05-05 03:22, Dzonatas Sol wrote: >> >>> Hi, >>> >>> I've read the acceptance e-mail: >>> http://www.ietf.org/mail-archive/web/ietf-announce/current/msg08829.html >>> >>> "RTP functionalities, media formats, security algorithms are example of >>> things that commonly need extensions, additions or replacement, and >>> thus some support for negotiation between clients is required." >>> >>> At a glance, I thought this sounded like "Real-Time Compositing" from >>> the frame and media complexes of IETF VWRAP WG. I'm not immediately >>> aware of any web-browser that features hardware-compositors, which would >>> help avoid some endless transistions. Hypervisors did come to mind, however. >>> >> To my understanding and I would say intention as I was part of writing >> that text line is that it concerns the need for having signalling, >> capability and negotiation mechanism for having the peers to agree on >> what is to be used. >> > > > Yes, given an example of an multiple applications that each support > RESTful queues and HTTP servers on the same home network, there is > commercial concern if these too easily breached because the home > firewall may not be trusted as the commercial firewall. That is subject > to opinion, yet it is an area that we haven't seen such end to > negotiation. Thus, more extensions interfere with interoperability, > especially if the commercial server will ensure assets in the hands of > the home user. > > > > >> >> When it comes to VWRAP I think there are some potential overlapp in >> underlying technology. Not following VWRAP I don't know if they are >> creating something new or are considering RTP for position information >> in a virtual world which definitely is a real-time media. >> > > VWRAP has gone through few make-overs, already, in concerns of > architectural WGs. Linden Labs has been key with the VW Second Life, and > whose original founder worked previously with Real. The Second Life > application is open source and features media plug-ins (for > web-media/web-browser on 3D polygons/primitives). The movement away from > monolithic designs, of both SL and web-browser, has been slow, yet > effort doesn't stop. > > This involves several layers at various scales. > > > >> If you believe there is overlap with VWRAP can you please be a bit more >> verbose on what that overlap consists of. >> >> I do fail to understand the meaning of the rest of your comments. >> >> Best Regards >> >> Magnus Westerlund >> > > No problem, as I mainly stated, expectantly, that if we relate to the > depth at scale given the language used already. Original UNIX is known > for real-time applications do to its time-slice capabilities. Many have > emulated UNIX for compatibility, yet they don't guarantee such real-time > scale or such quantums. We could relate X Windows as "a 3D browser" and > so further web-browsers on the web make this appears as a browser in a > browser, and so on. > > I think the original UNIX had the right idea to help avoid turtle on > turtles, yet the hardware-means didn't exist in earlier processors on > the market. Now they do, and today people use emulated modes within > emulated modes. > > Not that they are wrong in their direction, yet computation power is of > concern with that trend. > > Power effects timing. > > > >> >>> I'm the scientist, so I can help the doctors on this WG. >>> >>> Also, this was hinted to me: http://100yearstarshipstudy.com/ >>> >>> .NET version of original UNIX under Hypervisor mode with X Windows seems >>> like the bootstrap station for this WG. YMMV... >>> >>> >> >> > > -- 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 ---------------------------------------------------------------------- From dzonatas@gmail.com Fri May 6 08:20:30 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD8DE070E for ; Fri, 6 May 2011 08:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.665 X-Spam-Level: X-Spam-Status: No, score=-3.665 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fi+YIhqTXsPq for ; Fri, 6 May 2011 08:20:29 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92E77E0682 for ; Fri, 6 May 2011 08:20:29 -0700 (PDT) Received: by pzk5 with SMTP id 5so1919630pzk.31 for ; Fri, 06 May 2011 08:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PMRXFs/GMxq4xqyXrdvX+bBgPXstuswd+6yyi6mjWas=; b=qyA/TVXGJHAsSdoykC9Qn10ES5WrxP/CHUvoqA4bqN5YaB9bMbrm8EZMYj2PHUSyW1 mpiLgClYQLYI5cwO41xjy4WqZmoXh6Y6R0Ch7N89eIMqPhzDQf0iLBWtdNmBRS7Tdy+Q m2Tp/UlvcZn3thSU3+dcFJgUV2vw3fAXDA+WI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=gBpGShArqRoS6KGvMHBnQah/y5iA9fwnwt4eZFfE0iz2qVYHdMUZ40SyiGFi7ZLHSp Sz2ZYPTgxkbQB5AgqJ74ouLjqUhqD40tKS5O0/0ip2iqxrkn7Tr8MotKQ9G/nefo3zIn qD69oednpKqvhJN3VgXPzpn9ntY99ryopdeis= Received: by 10.68.52.70 with SMTP id r6mr4810696pbo.453.1304695228250; Fri, 06 May 2011 08:20:28 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id c10sm2198200pbd.87.2011.05.06.08.20.26 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 May 2011 08:20:27 -0700 (PDT) Message-ID: <4DC4117C.20003@gmail.com> Date: Fri, 06 May 2011 08:19:24 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Dzonatas Sol References: <4DC1FBCF.1090903@gmail.com> <4DC26C48.7040604@ericsson.com> <4DC2A35F.607@gmail.com> <4DC4047F.9060209@ericsson.com> <4DC40711.8050000@gmail.com> In-Reply-To: <4DC40711.8050000@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 15:20:30 -0000 I smiled at this one: http://tech.slashdot.org/story/11/05/06/122233/A-25-PC-On-a-USB-Stick Consider the HDMI as optional where-if the media uses USB as transport. On 05/06/2011 07:34 AM, Dzonatas Sol wrote: > Please review the use-case I just posted: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg00057.html > > I'm not sure if you say that as you seen this. If that is not clear > enough, I can answer more questions off-list. > > With that use-case, however, assume there is no specific perspective, > like page mode or such, so I want to avoid explanation of that > complexity. With the ReSTful paradigm, we can shift matters that fall > out of scope into other capabilities. > > Thanks. > > On 05/06/2011 07:23 AM, Magnus Westerlund wrote: >> Sorry, >> >> I can't make head and tails of your comments. They contain words that >> could be relevant but I can't determine what your actual argument or >> position is from it. >> >> Can you please be more specific and clear on what your point of argument >> is. What is the intention of your comments? >> >> best regards >> >> Magnus >> >> >> On 2011-05-05 15:17, Dzonatas Sol wrote: >>> Thanks for the reply, >>> >>> On 05/05/2011 02:22 AM, Magnus Westerlund wrote: >>>> On 2011-05-05 03:22, Dzonatas Sol wrote: >>>> >>>>> Hi, >>>>> >>>>> I've read the acceptance e-mail: >>>>> http://www.ietf.org/mail-archive/web/ietf-announce/current/msg08829.html >>>>> >>>>> >>>>> "RTP functionalities, media formats, security algorithms are >>>>> example of >>>>> things that commonly need extensions, additions or replacement, and >>>>> thus some support for negotiation between clients is required." >>>>> >>>>> At a glance, I thought this sounded like "Real-Time Compositing" from >>>>> the frame and media complexes of IETF VWRAP WG. I'm not immediately >>>>> aware of any web-browser that features hardware-compositors, which >>>>> would >>>>> help avoid some endless transistions. Hypervisors did come to >>>>> mind, however. >>>>> >>>> To my understanding and I would say intention as I was part of writing >>>> that text line is that it concerns the need for having signalling, >>>> capability and negotiation mechanism for having the peers to agree on >>>> what is to be used. >>>> >>> >>> Yes, given an example of an multiple applications that each support >>> RESTful queues and HTTP servers on the same home network, there is >>> commercial concern if these too easily breached because the home >>> firewall may not be trusted as the commercial firewall. That is subject >>> to opinion, yet it is an area that we haven't seen such end to >>> negotiation. Thus, more extensions interfere with interoperability, >>> especially if the commercial server will ensure assets in the hands of >>> the home user. >>> >>> >>> >>> >>>> When it comes to VWRAP I think there are some potential overlapp in >>>> underlying technology. Not following VWRAP I don't know if they are >>>> creating something new or are considering RTP for position information >>>> in a virtual world which definitely is a real-time media. >>>> >>> VWRAP has gone through few make-overs, already, in concerns of >>> architectural WGs. Linden Labs has been key with the VW Second Life, >>> and >>> whose original founder worked previously with Real. The Second Life >>> application is open source and features media plug-ins (for >>> web-media/web-browser on 3D polygons/primitives). The movement away >>> from >>> monolithic designs, of both SL and web-browser, has been slow, yet >>> effort doesn't stop. >>> >>> This involves several layers at various scales. >>> >>> >>> >>>> If you believe there is overlap with VWRAP can you please be a bit >>>> more >>>> verbose on what that overlap consists of. >>>> >>>> I do fail to understand the meaning of the rest of your comments. >>>> >>>> Best Regards >>>> >>>> Magnus Westerlund >>>> >>> No problem, as I mainly stated, expectantly, that if we relate to the >>> depth at scale given the language used already. Original UNIX is known >>> for real-time applications do to its time-slice capabilities. Many have >>> emulated UNIX for compatibility, yet they don't guarantee such >>> real-time >>> scale or such quantums. We could relate X Windows as "a 3D browser" and >>> so further web-browsers on the web make this appears as a browser in a >>> browser, and so on. >>> >>> I think the original UNIX had the right idea to help avoid turtle on >>> turtles, yet the hardware-means didn't exist in earlier processors on >>> the market. Now they do, and today people use emulated modes within >>> emulated modes. >>> >>> Not that they are wrong in their direction, yet computation power is of >>> concern with that trend. >>> >>> Power effects timing. >>> >>> >>> >>>> >>>>> I'm the scientist, so I can help the doctors on this WG. >>>>> >>>>> Also, this was hinted to me: http://100yearstarshipstudy.com/ >>>>> >>>>> .NET version of original UNIX under Hypervisor mode with X Windows >>>>> seems >>>>> like the bootstrap station for this WG. YMMV... >>>>> >>>>> >>>> >>> >> > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From magnus.westerlund@ericsson.com Fri May 6 08:29:08 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA12E0691 for ; Fri, 6 May 2011 08:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJ8K4H6Pp0oc for ; Fri, 6 May 2011 08:29:06 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 10351E067A for ; Fri, 6 May 2011 08:29:05 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-d2-4dc413b1f15e Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 75.8B.11171.1B314CD4; Fri, 6 May 2011 17:28:49 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 6 May 2011 17:28:46 +0200 Message-ID: <4DC413AE.1010608@ericsson.com> Date: Fri, 6 May 2011 17:28:46 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Dzonatas Sol References: <4DC1FBCF.1090903@gmail.com> <4DC26C48.7040604@ericsson.com> <4DC2A35F.607@gmail.com> <4DC4047F.9060209@ericsson.com> <4DC40711.8050000@gmail.com> In-Reply-To: <4DC40711.8050000@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 15:29:08 -0000 On 2011-05-06 16:34, Dzonatas Sol wrote: > Please review the use-case I just posted: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg00057.html > Yes I saw it. But I still don't understand what you are after. I can't determine if it is proxying or some write through data manipulation you want to attempt. Can you describe this in separate data objects or data stream, nodes that are involved in communication and existing or desired network protocol that perform the communication. > I'm not sure if you say that as you seen this. If that is not clear > enough, I can answer more questions off-list. > > With that use-case, however, assume there is no specific perspective, > like page mode or such, so I want to avoid explanation of that > complexity. With the ReSTful paradigm, we can shift matters that fall > out of scope into other capabilities. When I brought up perspective, I asked about your motivation and what capabilities that you see a need that still are within the WG's charter. 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 ---------------------------------------------------------------------- From dzonatas@gmail.com Fri May 6 10:10:07 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F4AE07A0 for ; Fri, 6 May 2011 10:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.662 X-Spam-Level: X-Spam-Status: No, score=-3.662 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ss-WxeRVtBE for ; Fri, 6 May 2011 10:10:06 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id EF460E079A for ; Fri, 6 May 2011 10:10:02 -0700 (PDT) Received: by pxi2 with SMTP id 2so2085895pxi.38 for ; Fri, 06 May 2011 10:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=T0PdfgOC1dYPGErQEqOZjpeEsYa/TNubpCJ/hu4vyGI=; b=stjTXeyI0kDgs2ymqYwSdivODLIwd9cO6ZciFMkHCuOFIPxnlgrBN48dd4ol+vG6sJ ePeDRhCtHrwqjM2BWJelY+hGD+wpoiKlq8WFlSDHTvpf6Us8uhZKQcBbCQz2kW7EuBJy wLeuOJ91kFE1YpIC4U2+227igCW1XBeVRTQUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=sFZEgGVmcnyEAcqIZ/bt5R0XjE8M8ZILjlo/QnmO3x7TNOLBNPZj3pWMDJT2zjCdQc 0J95xO2PUHas8sK6pFyM+BHZ1kNJ15p1y6SfBdFTtXZs7l61yZ3PcWI2mYlpLb0pTb3h kBY3K303USGvGPTsrS28BMof2f8n4okul4pYg= Received: by 10.68.60.164 with SMTP id i4mr5388204pbr.0.1304701801271; Fri, 06 May 2011 10:10:01 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id i10sm2254389pbd.28.2011.05.06.10.09.59 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 May 2011 10:10:00 -0700 (PDT) Message-ID: <4DC42B2A.6010107@gmail.com> Date: Fri, 06 May 2011 10:08:58 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Magnus Westerlund , "rtcweb@ietf.org" References: <4DC1FBCF.1090903@gmail.com> <4DC26C48.7040604@ericsson.com> <4DC2A35F.607@gmail.com> <4DC4047F.9060209@ericsson.com> <4DC40711.8050000@gmail.com> <4DC413AE.1010608@ericsson.com> In-Reply-To: <4DC413AE.1010608@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 17:10:07 -0000 On 05/06/2011 08:28 AM, Magnus Westerlund wrote: > On 2011-05-06 16:34, Dzonatas Sol wrote: > >> Please review the use-case I just posted: >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg00057.html >> >> > Yes I saw it. But I still don't understand what you are after. I can't > determine if it is proxying or some write through data manipulation you > want to attempt. > What we, in particular, want to do is avoid the current trend that puts people into more complicated support over what is suppose to be simplified communication through heterogeneous systems. At a glance, this WG sounded like "Real-Time Compositing". > Can you describe this in separate data objects or data stream, nodes > that are involved in communication and existing or desired network > protocol that perform the communication. > Yes. Let's consider that each frame needs composite information for each region over each succession of the frame. An example is the Hypervisor (as host) that gathers region data sent from guests for frame composition. The forward flow is more obvious then the reverse flow, where the host only needs to send essentially the same data to each region. With the Raspberry Pi prototype ( http://www.raspberrypi.org/ ), imagine any unit like that where the host is the one with the HDMI connection and the guests connect to the USB hub. The guest units would not need the HDMI hardware due to virtualization of the host or media thereof on the wire. Any new unit plugged into the hub can filter-in the "essentially same data" already being sent by the host. Even though the "essentially same data" exists, it surely isn't the same outside this scope. We can apply the same concept to shared-memory, multicasting, write-through, etc, at different frame scales, components, hardware/software, yet, as noted, we tried to avoid that implementation detail. We can already imagine those with invested interest in star-topologies would avoid anything like mesh-networks (and multicasting in general). Within the frame (and still technically within scope) and specific to each composition, we still need this much more so people are not left in continual argument how to negotiate their communication (and whatever desire at poly-scale). -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Fri May 6 10:59:00 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3212EE075E for ; Fri, 6 May 2011 10:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.659 X-Spam-Level: X-Spam-Status: No, score=-3.659 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDB-EsuaR5VP for ; Fri, 6 May 2011 10:58:59 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0985FE071E for ; Fri, 6 May 2011 10:58:58 -0700 (PDT) Received: by pwi5 with SMTP id 5so1996745pwi.31 for ; Fri, 06 May 2011 10:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ED5qo2TvQZt+7zozq2WJzTFCLY34hJqticaYnmZqI/A=; b=m8MUfzjaGMkmhAxPfxLi9UnviBnhrUXeVIlmEHg6hH8o8di21BGoymDDRrgXUuYf95 oKZAPxtY/iG57NeOgrSKYP0iK+01mW5pqWo6xoAvSwd1MFZ7elYJ3y+xFCogWSpUoFsJ 1atYUR5R+gNxhcQKFVgShrioVs0x6UHqadX/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=wf17mO4kU0DNbGJVIw243TOoAAn9MF2AIdNReGbzAlus2qCobNY+nLBFVRow5rD6Mt X6t6NTmY3TEnEGcNjStJeimvLemQKxq0Jbkrptm6D+WUP/Nf2A/5uru6OwQg4ZllUoi4 aK4/bIok4j2FL0mGkaorFyFFrU0nHvPGcvUyA= Received: by 10.68.10.135 with SMTP id i7mr5159816pbb.417.1304704738019; Fri, 06 May 2011 10:58:58 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id t10sm2265814pbh.9.2011.05.06.10.58.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 May 2011 10:58:56 -0700 (PDT) Message-ID: <4DC436A3.4080709@gmail.com> Date: Fri, 06 May 2011 10:57:55 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Ted Hardie References: <4DC1FBCF.1090903@gmail.com> <4DC26C48.7040604@ericsson.com> <4DC2A35F.607@gmail.com> <4DC4047F.9060209@ericsson.com> <4DC40711.8050000@gmail.com> <4DC413AE.1010608@ericsson.com> <4DC42B2A.6010107@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 17:59:00 -0000 We try to filter-in mime-types and capabilities, yet we know now to filter-out any leftover flow of RTP in regards to the RTCWEB constraints, yet for support, do nothing. Thanks. On 05/06/2011 10:38 AM, Ted Hardie wrote: > Hi Dzonatas, > > Having read through this thread and visited the prototype site you > mentioned, I conclude that the perceived overlap is because each > community uses similar vocabulary. �That's an important insight for us > as we strive to make our work understood, thanks. �The practical > overlap between the efforts seems to be very small, however, at least > at this time. �Given the tight time constraints on producing the > currently chartered work, we will not be considering expanding the > scope at this point. > > Thanks and regards, > > Ted � > > On Fri, May 6, 2011 at 10:08 AM, Dzonatas Sol > wrote: > > On 05/06/2011 08:28 AM, Magnus Westerlund wrote: > > On 2011-05-06 16:34, Dzonatas Sol wrote: > � > > Please review the use-case I just posted: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg00057.html > > � � > > Yes I saw it. But I still don't understand what you are after. > I can't > determine if it is proxying or some write through data > manipulation you > want to attempt. > � > > > What we, in particular, want to do is avoid the current trend that > puts people into more complicated support over what is suppose to > be simplified communication through heterogeneous systems. At a > glance, this WG sounded like "Real-Time Compositing". > > > > Can you describe this in separate data objects or data stream, > nodes > that are involved in communication and existing or desired network > protocol that perform the communication. > � > > > Yes. Let's consider that each frame needs composite information > for each region over each succession of the frame. An example is > the Hypervisor (as host) that gathers region data sent from guests > for frame composition. The forward flow is more obvious then the > reverse flow, where the host only needs to send essentially the > same data to each region. > > With the Raspberry Pi prototype ( http://www.raspberrypi.org/ ), > imagine any unit like that where the host is the one with the HDMI > connection and the guests connect to the USB hub. The guest units > would not need the HDMI hardware due to virtualization of the host > or media thereof on the wire. Any new unit plugged into the hub > can filter-in the "essentially same data" already being sent by > the host. Even though the "essentially same data" exists, it > surely isn't the same outside this scope. > > We can apply the same concept to shared-memory, multicasting, > write-through, etc, at different frame scales, components, > hardware/software, yet, as noted, we tried to avoid that > implementation detail. > > We can already imagine those with invested interest in > star-topologies would avoid anything like mesh-networks (and > multicasting in general). Within the frame (and still technically > within scope) and specific to each composition, we still need this > much more so people are not left in continual argument how to > negotiate their communication (and whatever desire at poly-scale). > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From harald@alvestrand.no Fri May 6 11:03:04 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C529E07D8 for ; Fri, 6 May 2011 11:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1CbFfpbOIkU for ; Fri, 6 May 2011 11:03:04 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 836B6E07D7 for ; Fri, 6 May 2011 11:03:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 35A7A39E123 for ; Fri, 6 May 2011 20:02:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HBE2Pknd22J for ; Fri, 6 May 2011 20:02:14 +0200 (CEST) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id D956039E08B for ; Fri, 6 May 2011 20:02:13 +0200 (CEST) Message-ID: <4DC437D4.2020004@alvestrand.no> Date: Fri, 06 May 2011 20:03:00 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------030306010106010803020400" Subject: [rtcweb] Fwd: W3C Web Real-Time Communications group officially created X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 18:03:04 -0000 This is a multi-part message in MIME format. --------------030306010106010803020400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit For your info: The W3C counterpart of the IETF effort is now open for business (and not just a mailing list). For those of you who want formal, company-based representation: Make sure to do the processing to be officially registered - this commits your company to the W3C IPR policy, too. Anyone can join the public mailing list; this is not an IPR commitment. Welcome! Harald -------- Original Message -------- Subject: W3C Web Real-Time Communications group officially created Resent-Date: Fri, 06 May 2011 09:41:17 +0000 Resent-From: public-webrtc@w3.org Date: Fri, 06 May 2011 11:38:48 +0200 From: Francois Daoust To: public-webrtc@w3.org Hi all, Great news, the W3C Web Real-Time Communications working group (Web RTC WG) has been officially launched yesterday! Not surprisingly, the group's mission is to define client-side APIs to enable Real-Time Communications in Web browsers. Please have a look at the charter of the group for more details: http://www.w3.org/2011/04/webrtc-charter.html This group will work in close relationship with the recently created IETF RTCWEB group. Harald Alvestrand and Stefan Håkansson will serve as co-chairs for this group. I will be the W3C staff contact. Feel free to get in touch with me, in particular if you have questions on logistics or W3C process. I'd be more than happy to help if I can. Instructions to join the group are available at: http://www.w3.org/2004/01/pp-impl/47318/instructions This mailing-list now becomes the official public mailing-list of the Web RTC WG. Anyone can subscribe to this mailing-list and comment or react on on-going discussions. Official participants take an active role in decision-making and contribute substantive portions of text to the deliverables of the group under the W3C patent policy. Participation to the group is open to W3C Members. Subscribing to the mailing-list does not make you an official participant of the group (no patent commitment to following emails). Thanks, Francois. --------------030306010106010803020400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit For your info: The W3C counterpart of the IETF effort is now open for business (and not just a mailing list).

For those of you who want formal, company-based representation: Make sure to do the processing to be officially registered - this commits your company to the W3C IPR policy, too.

Anyone can join the public mailing list; this is not an IPR commitment.
Welcome!

             Harald

-------- Original Message --------
Subject: W3C Web Real-Time Communications group officially created
Resent-Date: Fri, 06 May 2011 09:41:17 +0000
Resent-From: public-webrtc@w3.org
Date: Fri, 06 May 2011 11:38:48 +0200
From: Francois Daoust <fd@w3.org>
To: public-webrtc@w3.org 


Hi all,

Great news, the W3C Web Real-Time Communications working group (Web RTC WG) has been officially launched yesterday!

Not surprisingly, the group's mission is to define client-side APIs to enable Real-Time Communications in Web browsers. Please have a look at the charter of the group for more details:
 http://www.w3.org/2011/04/webrtc-charter.html

This group will work in close relationship with the recently created IETF RTCWEB group. Harald Alvestrand and Stefan Håkansson will serve as co-chairs for this group. I will be the W3C staff contact. Feel free to get in touch with me, in particular if you have questions on logistics or W3C process. I'd be more than happy to help if I can.

Instructions to join the group are available at:
 http://www.w3.org/2004/01/pp-impl/47318/instructions

This mailing-list now becomes the official public mailing-list of the Web RTC WG. Anyone can subscribe to this mailing-list and comment or react on on-going discussions. Official participants take an active role in decision-making and contribute substantive portions of text to the deliverables of the group under the W3C patent policy. Participation to the group is open to W3C Members. Subscribing to the mailing-list does not make you an official participant of the group (no patent commitment to following emails).

Thanks,
Francois.
--------------030306010106010803020400-- From christer.holmberg@ericsson.com Tue May 10 07:51:13 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E93CE0681 for ; Tue, 10 May 2011 07:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdNMPn+hNYkQ for ; Tue, 10 May 2011 07:51:11 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 71626E075C for ; Tue, 10 May 2011 07:51:10 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-7b-4dc950da9306 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B4.33.11171.AD059CD4; Tue, 10 May 2011 16:51:07 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 10 May 2011 16:51:02 +0200 From: Christer Holmberg To: "hardie@ipinfusion.com" , "rtcweb@ietf.org" Date: Tue, 10 May 2011 16:51:01 +0200 Thread-Topic: [rtcweb] Contributions for the Interim meeting Thread-Index: AcwJ7uFnZuMR1nYOTAmSGUdSJsBizQFMomxg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E0F11D5@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 14:51:13 -0000 Hi, We are willing to continue the work on the use-case & requirements draft (d= raft-holmberg-rtcweb-ucreqs), if the group thinks thinks it's useful. Regards, Christer =20 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie > Sent: 4. toukokuuta 2011 3:08 > To: rtcweb@ietf.org > Subject: [rtcweb] Contributions for the Interim meeting >=20 > As you will have seen from Cullen's announcement, we are now=20 > officially a working group and starting to collect data on=20 > the possible timing of an interim meeting.=20 >=20 > For the interim meeting, we want to start work on the=20 > chartered deliverables. If you are interested in being an=20 > editor for one of the working group docs, the chairs would=20 > like you to prepare something for the Interim as a draft-00=20 > of your take. If you can, raise your hand on the list to say=20 > you're doing so, so as to let others know to talk to you=20 > about collaborating. If you are not able to attend any of=20 > the times put forward for the interim, you can still=20 > volunteer to edit a document--it just means you'll have to=20 > have the -00 done early enough for the chairs to find a=20 > stuckee for feedback coming in at the interim. >=20 > regards, >=20 > Ted, Cullen, and Magnus > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From harald@alvestrand.no Wed May 11 02:05:36 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC86E078A for ; Wed, 11 May 2011 02:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcvdhW4G4VJO for ; Wed, 11 May 2011 02:05:35 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id DD538E064E for ; Wed, 11 May 2011 02:05:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 090F039E13B for ; Wed, 11 May 2011 11:04:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ib6A6AuXADv for ; Wed, 11 May 2011 11:04:44 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 4615D39E16B for ; Wed, 11 May 2011 11:04:44 +0200 (CEST) Message-ID: <4DCA515C.5050207@alvestrand.no> Date: Wed, 11 May 2011 11:05:32 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/mixed; boundary="------------000306000901080008000208" Subject: [rtcweb] Meeting minutes from Prague X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 09:05:36 -0000 This is a multi-part message in MIME format. --------------000306000901080008000208 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Apologies for the excessive lateness of these minutes, which was not due to the minute-takers. Corrections are (still) welcome. Harald --------------000306000901080008000208 Content-Type: text/plain; name="bof-minutes.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bof-minutes.txt" UmVhbCBUaW1lIENvbW11bmljYXRpb24gZm9yIHRoZSBXb3JsZCBXaWRlIFdlYiAoUlRDV0VC KSBCT0YgbWludXRlcwoKQ2hhaXJzOiBUZWQgSGFyZGllIDxoYXJkaWUraWV0ZkBnbWFpbC5j b20+CiAgICAgICAgSGFyYWxkIEFsdmVzdHJhbmQgPGh0YUBnb29nbGUuY29tPiAKCk1lZXRp bmcgMTogSUVURiA4MCwgVHVlc2RheSwgTWFyY2ggMjksIDA5MDAtMTEzMApMb2NhdGlvbjog UHJhZ3VlIEhpbHRvbiwgQ29uZ3Jlc3MgSGFsbCBJSQpNaW51dGVzOiBDaHJpc3RlciBIb2xt YmVyZyA8CgpNZWV0aW5nIDIgKGZvcm1hbGx5IGEgRElTUEFUQ0ggYWQtaG9jIG1lZXRpbmcp OiBGcmlkYXksIEFwcmlsIDEsIDE0MTUtMTUxNQpMb2NhdGlvbjogUHJhZ3VlIEhpbHRvbiwg R3JhbmQgQmFsbHJvb20KTWludXRlczogQ2FyeSBCcmFuIDxjYnJhbkBjaXNjby5jb20+CgpW ZXJzaW9uOiAwLjIKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KVFVFU0RBWQoKaHR0cDovL2lldGY4MHN0cmVh bWluZy5kbnNhbGlhcy5uZXQvaWV0ZjgwL2lldGY4MC1jaDMtdHVlcy1hbS5tcDMKQ29sbGFi b3JhdGlvbiB3aXRoIFczQzoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCi0gSXQgd2Fz IG5vdGVkIHRoYXQgd2hpbGUgSUVURiBoYXMgdGhlIG5ldHdvcmsgZXhwZXJ0aXNlLCBXM0Mg aGFzIHRoZQpBUEkgZXhwZXJ0aXNlLCBhbmQgdGhhdCBjb2xsYWJvcmF0aW9uIGJldHdlZW4g dGhlIGdyb3VwIGlzCmltcG9ydGFudC4KLSBJdCB3YXMgaW5kaWNhdGVkLCBhcyB0aGVyZSBh cmUgcGVvcGxlIGFjdGl2ZSBpbiBib3RoIElFVEYgYW5kIFczQywgaXQKaXMgYmV0dGVyIHRv IHJlbHkgb24gYWN0aXZlIGNvbGxhYm9yYXRpb24gZHJpdmVuIGJ5IGluZGl2aWR1YWxzLApy YXRoZXIgdGhhbiBzZW5kaW5nIGxpYWlzb25zIGJldHdlZW4gdGhlIFNET3MuCi0gSXMgd2Fz IHF1ZXN0aW9uZWQgd2hldGhlciBJRVRGIGFuZCBXM0MgaGF2ZSBkaWZmZXJlbnQgSVBSIHBv bGljaWVzLgotIEl0IHdhcyBpbmRpY2F0ZWQgdGhhdCB0aGUgc2VjdXJpdHkgbW9kZWwgYWxz byBuZWVkcyB0byBiZSBkZWZpbmVkIGluCmNvbGxhYm9yYXRpb24gd2l0aCBXM0MsIGFzIHRo ZXJlIGFyZSB3ZWIgc2VjdXJpdHkgYXNwZWN0cyB0aGF0IElFVEYKbWlnaHQgbm90IGhhdmUg Z29vZCBrbm93bGVkZ2Ugb2YuCi0gVGhlcmUgd2FzIGEgcXVlc3Rpb24gd2hldGhlciBkb2N1 bWVudCBwcm9kdWNlZCBieSBJRVRGIGFuZCBXM0MgbmVlZHMKdG8gYmUgYXBwcm92ZWQgYnkg Ym90aCBTRE9zLiBJdCB3YXMgaW5kaWNhdGVkIHRoYXQgaG9wZWZ1bGx5IHRoZXJlCndpbGwg bm90IGJlIGEgbmVlZCBmb3IgYm90aCBncm91cHMgdG8gZm9ybWFsbHkgYXBwcm92ZSBkb2N1 bWVudHMgb2YKdGhlIG90aGVyIGdyb3VwLCBidXQgZWFjaCBTRE8gc2hvdWxkIGZvbGxvdyBh bmQgcmV2aWV3IHRoZSB3b3JrIG9mIHRoZQpvdGhlciBncm91cC4KLSBJdCB3YXMgY29tbWVu dGVkIHRoYXQgd2UgbWlnaHQgbmVlZCB0byBlc3RhYmxpc2ggYSBjb2xsYWJvcmF0aW9uCmFs c28gd2l0aCB0aGUgV0hBVFdHLCByYXRoZXIgdGhhbiByZWx5aW5nIG9uIFczQyBmb3IgdGhl IFdIQVRXRwpjb2xsYWJvcmF0aW9uLgoKClVzZS1jYXNlcyBhbmQgcmVxdWlyZW1lbnRzOgot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKUHJlc2VudGVyOiBDaHJpc3RlciBIb2xt YmVyZwoKLSBUaGUgcHJlc2VudGVyIGluZGljYXRlZCB0aGF0IHdlIG5lZWQgdG8sIGluIG9y ZGVyIHRvIHByb2R1Y2UgQVBJCnJlcXVpcmVtZW50cywgYWdyZWUgb24gdGhlIGZ1bmN0aW9u YWwgc3BsaXQgYmV0d2VlbiB0aGUgYnJvd3NlciBhbmQKdGhlIHdlYi1hcHAuCi0gVGhlIHBy ZXNlbnRlciBpbmRpY2F0ZWQgdGhhdCBOQVQvRlcgdHJhdmVyc2FsIGFsc28gY29udGFpbnMg YQptZWNoYW5pc20gdG8gcGVyZm9ybSBtZWRpYSBmYWxsYmFjayAoZS5nLiBIVFRQIGZhbGxi YWNrKS4KCgpSVEMtV2ViIEZyYW1ld29yazoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoK UHJlc2VudGVyOiBKb25hdGhhbiBSb3NlbmJlcmcKCi0gVGhlIHByZXNlbnRlciBpbmRpY2F0 ZWQgdGhhdCwgYXMgdGhlIGJyb3dzZXIgYW5kIHdlYi1hcHAgaW4gbW9zdApjYXNlcyBhcmUg cHJvZHVjZWQgYnkgZGlmZmVyZW50IG9yZ2FuaXphdGlvbnMsIHdlIHNob3VsZCBsb29rIGF0 IHRoZQpBUEkgYmV0d2VlbiB0aGUgYnJvd3NlciBhbmQgd2ViLWFwcCBhcyBhIHByb3RvY29s LiAKLSBJdCB3YXMgY29tbWVudGVkIHRoYXQgd2UgbmVlZCB0byBiZSBjYXJlZnVsIHdpdGgg dGVybWlub2xvZ3ksIGFzIGFuCkFQSSBkb2VzIG5vdCBkaWN0YXRlIGEgcHJvdG9jb2wuCi0g SXQgd2FzIGNvbW1lbnRlZCB0aGF0IHRoZSBBUEkgc2hvdWxkIG5vdCBiZSB0b28gY29tcGxl eCBmb3Igd2ViCmFwcGxpY2F0aW9uLiBJdCB3YXMgc3VnZ2VzdGVkIHRoYXQgdGhlIEFQSSBt aWdodCBoYXZlIGRpZmZlcmVudCBsZXZlbHMKb2YgY29tcGxleGl0eS4KLSBJdCB3YXMgaW5k aWNhdGVkIHRoYXQgdGhlIGJyb3dzZXIgYXBwbGljYXRpb24gaXRzZWxmIG1pZ2h0IG5vdApp bXBsZW1lbnQgdGhlIGZlYXR1cmVzIGl0IG9mZmVycyB0byB0aGUgd2ViLWFwcC4gU29tZSBm ZWF0dXJlcyBtaWdodAphbHNvIGJlIG9mZmVyZWQgYnkgdGhlIE9TLCB3aGVyZSB0aGUgYnJv c3dlciBzaW1wbHkgcHJvdmlkZXMgYWNjZXNzIHRvCnRob3NlIGZlYXR1cmVzIHRvIHRoZSB3 ZWItYXBwLgoKCldlYiBTZWN1cml0eToKLS0tLS0tLS0tLS0tLS0tCgpQcmVzZW50ZXI6IEVy aWMgUmVzY29ybGEKCi0gVGhlIGZvbGxvd2luZyBzZWN1cml0eSBhcmVhcywgcmVsYXRlZCB0 byBydGMtd2ViLCB3ZXJlIGlkZW50aWZpZWQ6Ci0tIE1lZGlhIHJlbW90ZSBwZWVyIHZlcmlm aWNhdGlvbi4KLS0gQWNjZXNzIHRvIGxvY2FsIGRldmljZS4KLS0gQ29tbXVuaWNhdGlvbiBz ZWN1cml0eS4KLSBUaGVyZSB3YXMgYSBjb21tZW50IHRoYXQgaWRlbnRpdHkgYWxzbyBuZWVk cyB0byBiZSBjb3ZlcmVkLiBIb3dldmVyLAppbiBzb21lIHVzZS1jYXNlcyBpZGVudGl0eSBt aWdodCBub3QgYmUgbmVlZGVkLCBvciBldmVuIGRlc2lyZWQuIAotIEl0IHdhcyBxdWVzdGlv bmVkIGhvdyB3ZSBjYW4gcHJldmVudCBhbiBhcHBsaWNhdGlvbiwgY2xhaW1pbmcgdG8gYmUg YQpicm93c2VyLCBmcm9tIHNlbmRpbmcgZGF0YSBiZWZvcmUgZ2V0dGluZyBjb25zZW50LiBJ dCB3YXMgaW5kaWNhdGVkCnRoYXQgc3VjaCBhIHNjZW5hcmlvIGlzIG91dHNpZGUgdGhlIHNj b3BlIG9mIHRoZSBXRy4KCgpOZWdvdGlhdGlvbiBhbmQgRXh0ZW5zaWJpbGl0eQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpQcmVzZW50ZXI6IEN1bGxlbiBKZW5uaW5ncwoKLSBU aGUgcHJlc2VudGVyIGluZGljYXRlZCB0aGF0IHRoZSBzb2x1dGlvbiBtdXN0IGJlIGV4dGVu ZGlibGUsIGFuZCBpdAptdXN0IHByb3ZpZGUgYSBtZWNoYW5pc20gd2hpY2ggYWxsb3dzIHRo ZSBuZWdvdGlhdGlvbiBvZiBkaWZmZXJlbnQKZmVhdHVyZXMuCi0gSXQgd2FzIGluZGljYXRl ZCB0aGF0IGZ1bGwgbGVnYWN5IGludGVyb3BlcmFiaWxpdHkgbWlnaHQgbm90IGJlCnBvc3Np YmxlLCBtb3N0bHkgZHVlIHRvIHNlY3VyaXR5IGNvbnN0cmFpbnRzLCB3aXRob3V0IGludGVy bWVkaWFyeQpmdW5jdGlvbnMgb24gdGhlIG1lZGlhIHBsYW5lLgotIEl0IHdhcyBpbmRpY2F0 ZWQgdGhhdCB0aGUgV0cgbmVlZHMgdG8gZGVjaWRlIG9uIHRoZSBsZXZlbCBvbiBsZWdhY3kK aW50ZXJvcGVyYWJpbGl0eS4KCgpDaGFydGVyOgotLS0tLS0tLQotIEEgbGFyZ2UgbnVtYmVy IG9mIGluZGl2aWR1YWxzIGhhZCByZWFkIHRoZSBwcm9wb3NlZCBjaGFydGVyIHRleHQuCi0g VGhlcmUgd2FzIGEgcXVlc3Rpb24gd2hldGhlciBkb2N1bWVudCBwcm9kdWNlZCBieSBJRVRG IGFuZCBXM0MgbmVlZHMKdG8gYmUgYXBwcm92ZWQgYnkgYm90aCBTRE9zLiBJdCB3YXMgaW5k aWNhdGVkIHRoYXQgaG9wZWZ1bGx5IHRoZXJlCndpbGwgbm90IGJlIGEgbmVlZCBmb3IgYm90 aCBncm91cHMgdG8gZm9ybWFsbHkgYXBwcm92ZSBkb2N1bWVudHMgb2YKdGhlIG90aGVyIGdy b3VwLCBidXQgZWFjaCBTRE8gc2hvdWxkIGZvbGxvdyBhbmQgcmV2aWV3IHRoZSB3b3JrIG9m IHRoZQpvdGhlciBncm91cC4KLSBJdCB3YXMgY29tbWVudGVkIHRoYXQgdGhlIGNoYXJ0ZXIg ZG9lcyBub3QgdGFsayBhYm91dCBsZWdhY3kKaW50ZXJvcGVyYWJpbGl0eS4KLSBJdCB3YXMg Y29tbWVudGVkIHRoYXQgbm9uZSBvZiB0aGUgcHJlc2VudGF0aW9ucyBoYXZlIGRlc2NyaWJl ZCB0aGUKaGFuZGxpbmcgb2Ygbm9uLVJUUCBjb25uZWN0aW9ucy4gSXQgd2FzIGluZGljYXRl ZCB0aGF0IHRoZSBNRyBtaWdodAp3YW50IHRvIGNvbnNpZGVyIHNlbmRpbmcgYWxzbyBub24t YXVkaW8vdmlkZW8gZGF0YSBvdmVyIFJUUC4KLSBJdCB3YXMgY29tbWVudGVkIHRoYXQgdGhl IGNoYXJ0ZXIgc2hvdWxkIG5vdCBjb250YWluIGEgbGlzdCBvZgpmZWF0dXJlcyB0aGF0IG1p Z2h0IGJlIGFkZGVkIHRvIHRoZSBjaGFydGVyIGF0IGEgbGF0ZXIgcG9pbnQuCgpQb2xsczoK LS0tLS0tCgotIFN1cHBvcnQgZm9yIGNoYXJ0ZXJpbmcgdGhlIGdyb3VwOiBWZXJ5IHN0cm9u Zywgd2l0aCBubyBvcHBvc2l0aW9uLgotIFdpbGxpbmduZXNzIHRvIHJldmlldyBkb2N1bWVu dHM6IGFwcHJveCA1MC02MCBpbmRpdmlkdWFscy4KLSBXaWxsaW5nbmVzcyB0byB3cml0ZSBh bmQgcHJvdmlkZSB0ZXh0IHRvIGRvY3VtZW50czogYXBwcm94IDI0IGluZGl2aWR1YWxzLgoK Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCkZSSURBWSAoTWFyeSBCYXJuZXMsIEN1bGxlbiBKZW5uaW5ncyBj by1jaGFpcmluZykKCldlbGNvbWUsIEFnZW5kYSBiYXNoaW5nLCBldGMuLi4gLSBDdWxsZW4g SmVubmluZ3MKaHR0cDovL3Rvb2xzLmlldGYub3JnL2FnZW5kYS84MC9zbGlkZXMvZGlzcGF0 Y2gtNC5wcHQKClJUQyBXZWIgQ2hhcnRlciBTdGF0dXM6CiogQ3VycmVudGx5IGJlaW5nIGlu dGVybmFsbHkgcmV2aWV3ZWQgYnkgdGhlIElFU0cuCkFmdGVyIHRoZSBJRVNHIGNvbXBsZXRl cyB0aGUgaW50ZXJuYWwgcmV2aWV3OgoqIElFU0cgd2lsbCBtZWV0IHRvIGRlY2lkZSBpZiB0 aGUgY2hhcnRlciBpcyByZWFkeSBmb3IgZXh0ZXJuYWwKcmV2aWV3CiogRXh0ZXJuYWwgcmV2 aWV3CiogSUVTRyBjb25kdWN0cyBmaW5hbCByZXZpZXcKKiBDaGFydGVyIGlzIGFwcHJvdmVk IGFuZCBpcyBzb2NpYWxpemVkIHdpdGggb3RoZXIgU0RPcwoKTm90ZSBXZWxsIE5vdGljZSB3 YXMgcHJlc2VudGVkLgoKQmlnIFBpY3R1cmUgQXJjaGl0ZWN0dXJlIC0gTWFyeSBCYXJuZXMK ClJldmlldyBvZiB0aGUgY3VycmVudCBhcmNoaXRlY3R1cmFsIHByb3Bvc2FscwoqIEJhc2Ug Q2FzZSAtIHN0YW5kYXJkcy1iYXNlZCBvciBwcm9wcmlldGFyeSBzaWduYWxpbmcgVEJECiog UHJvdmlkZXIgSW50ZXJvcCBDYXNlCgpBIEJyYWluLUR1bXAgb2YgQ2FuZGlkYXRlIFJUQyBX ZWIgV29yayBJdGVtcyAtIE1hdHRoZXcgS2F1Zm1hbgpodHRwOi8vdG9vbHMuaWV0Zi5vcmcv YWdlbmRhLzgwL3NsaWRlcy9kaXNwYXRjaC0zLnBkZgpTbGlkZSBPdmVydmlldzoKKiBDaGFy dGVyZWQgV29yawoKKiBPcGVuIFF1ZXN0aW9ucwpBIGJ1bmNoIC0gc3Bhbm5pbmcgYWNyb3Nz IHRoZSB3b3JrIGNhdGVnb3JpZXMKCiogQ29tbXVuaWNhdGlvbiBNb2RlbC9TZXNzaW9uIE1n dApFdmVyeXRoaW5nIHdlIGRvIE1VU1QgYmUgcG9zc2libGUgaW4gYSB3ZWIgYnJvd3NlcgpN ZWRpYSBTdHJlYW1zIC0gU0RQIGVxdWl2YWxlbnQgb3IgYWQgaG9jIEFQSTJBUEk/ClByb3Zp ZGVyIEludGVyb3AKTXVsdGlwYXJ0eSBjYWxsaW5nIC0gQVBJIGNvbnNpZGVyYXRpb25zLCBN ZWRpYQpjb25zaWRlcmF0aW9ucwoqIFNlY3VyaXR5IGFuZCBwcml2YWN5IHNsaWRlCiogRmly ZXdhbGwgYW5kIE5BVCB0cmF2ZXJzYWwKKiBDbGllbnQgUlQgbWVkaWEgZnVuY3Rpb25zCiog RXh0ZW5zaWJpbGl0eSBQb2ludHMKKiBTdXBwb3J0ZWQgTWVkaWEgRm9ybWF0cwpBdWRpbz8K VmlkZW8/CgoqIE5vbi1NZWRpYSBEYXRhCkNvbmdlc3Rpb24gY29udHJvbCAtIGUuZy4gZmls ZSB0cmFuc2ZlcgoKKiBXM0MgaW5wdXQgZm9yIEFQSXMKCiogSW50ZXJ3b3JraW5nIHdpdGgg bGVnYWN5IFZPSVAKT3BlbiBEaXNjdXNzaW9uCgoqIE5vbi1NZWRpYSBEYXRhIC0gc3VwcG9y dCBvZiBub3QKT3BlbiBkaXNjdXNzaW9uIG9uIHdoZXRoZXIgb3Igbm90IHRvIHN1cHBvcnQg bm9uLW1lZGlhIGRhdGEuClRoZSBpc3N1ZSBmb3IgdGhlIGdyb3VwIHRvIHdvcmsgb24gaXMg d2hldGhlciBvciBub3QgdG8gc2VuZApub24tbWVkaWEgZGF0YSBvdmVyIFJUUC4KCiogSW50 ZXJvcApCcm93c2VyIHRvIGJyb3dzZXIgaW50ZXJvcCAtIHdvcmthYmxlIGlmIGRlaWduIGlz IGtlcHQgdG8gYSBsb3cKbGV2ZWwsIGxpYnJhcmllcyBjYW4gYmUgYnVpbHQgdG8gZG8gY3Jv c3MgYnJvd3Nlcgpjb21wYXRpYmlsaXR5LgpEaXNjdXNzaW9uIGFyb3VuZCByZWFsLXRpbWUg Y29tbXVuaWNhdGlvbnMgLSBlbmQtMi1lbmQgdnMuCnBvaW50LTItcG9pbnQKCiogTWFuZGF0 b3J5IHRvIGltcGxlbWVudCBDb2RlY3M/Ck5vIGFncmVlbWVudCBvbiB0aGlzCgoqIEludGVy ZXN0IGluIE1lZXRpbmc/IC0gTWFyeSBCYXJuZXMKRG9vZGxlIHBvbGwgZm9yIG5leHQgbWVl dGluZwpBdWRpZW5jZSB3YXMgcG9sbGVkOgo0MC01MCBwZW9wbGUgLSBGYWlybHkgbGlrZWx5 IHRvIGNvbWUgdG8gV2ViRXggbWVldGluZwoxMCBwZW9wbGUgLSBmb3IgZmFjZS0yLWZhY2Ug bWVldGluZyBiZWZvcmUgbmV4dCBJRVRGCgoqIFBhdGVudCBQb2xpY2llcwpCb3RoIHRoZSBX M0MgYW5kIElFVEYgd2lsbCBiZSB3b3JraW5nIHRvZ2V0aGVyIHVuZGVyIHRoZWlyCnJlc3Bl Y3RpdmUgcGF0ZW50IHBvbGljaWVzLgo= --------------000306000901080008000208-- From magnus.westerlund@ericsson.com Thu May 12 05:21:22 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82782E06D3 for ; Thu, 12 May 2011 05:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.396 X-Spam-Level: X-Spam-Status: No, score=-106.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ui+6G7dMo9Lg for ; Thu, 12 May 2011 05:21:18 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 40E03E06D7 for ; Thu, 12 May 2011 05:21:17 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-64-4dcbd0bcae18 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D6.E0.11171.CB0DBCD4; Thu, 12 May 2011 14:21:16 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Thu, 12 May 2011 14:21:15 +0200 Message-ID: <4DCBD0BB.6090408@ericsson.com> Date: Thu, 12 May 2011 14:21:15 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Cullen Jennings References: <21B5AA97-549A-4782-8E34-E04EF431D591@cisco.com> In-Reply-To: <21B5AA97-549A-4782-8E34-E04EF431D591@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: [rtcweb] RTCWeb Interim Meeting on the 8th of June at 4.30 PM CEST X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 12:21:22 -0000 Hi, Based on the poll data of today, the WG will hold its interim meeting on the 8th of June at 4.30 PM CEST. More information regarding agenda and how to join will be announced later. Best Regards Magnus On 2011-05-03 19:33, Cullen Jennings wrote: > > I'm thrilled to see that the RTCWeb working group has been approved. > > > At the last IETF meeting, many people felt we should considering > having a virtual interim meeting for the IETF RTCWeb WG. Let us know > which dates could work for you. I have proposed four dates at the > following doodle pool. > > http://doodle.com/zf8wq624py96rkxx > > The meeting would likely be 3 or 4 hours long so it starts really > early if you live in Silicon valley and goes really late it you live > in Europe. Sorry. Please choose the dates that you would be able to > attend a virtual interim meeting. On May 12, we will look at the data > from the poll and try to pick an appropriate date. > > Thanks, Cullen, Magnus & Ted > > -- 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 ---------------------------------------------------------------------- From wwwrun@ietfa.amsl.com Tue May 17 07:33:41 2011 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 61EDDE0822; Tue, 17 May 2011 07:33:41 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110517143341.61EDDE0822@ietfa.amsl.com> Date: Tue, 17 May 2011 07:33:41 -0700 (PDT) Cc: rtcweb@ietf.org Subject: [rtcweb] RTCWEB WG Virtual Interim Meeting June 8, 2011 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 14:33:41 -0000 The RTCWEB WG will hold an virtual interim meeting: Date: Wednesday 2011-06-08 Time: 16.30-20.30 CEST 7.30-11.30 US Pacific time Details about agenda and how to participate will be announced on the RTCWEB WG mailing list: https://datatracker.ietf.org/wg/rtcweb/charter/ From christer.holmberg@ericsson.com Thu May 26 23:24:00 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D9FE06B1 for ; Thu, 26 May 2011 23:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ht91gDwqVoXt for ; Thu, 26 May 2011 23:23:59 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABF1E0686 for ; Thu, 26 May 2011 23:23:59 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-2d-4ddf437edbad Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 75.AC.20773.E734FDD4; Fri, 27 May 2011 08:23:58 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 27 May 2011 08:23:58 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Date: Fri, 27 May 2011 08:23:56 +0200 Thread-Topic: Web real-time communication enabled browser Thread-Index: AcwcNqicp+oXCFQuQ1OivaV1JcrOBg== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25CE9D@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585194E25CE9DESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Web real-time communication enabled browser X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 06:24:00 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E25CE9DESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I know this mailing list is not supposed to be used for marketing and adver= tising, so I appologise if this e-mail is seen as inapproriate by people. However, as it is very much related to our work, I would like to inform you= that we have done some experiments with the WhatWG APIs for web real-time = communication, and have made the implementation available for anyone who wo= uld like to test: https://labs.ericsson.com/developer-community/blog/beyond-html5-experiment-= real-time-communication-browserhttps://labs.ericsson.com/developer-communit= y/blog/beyond-html5-experiment-real-time-communication-browser You will find contact persons etc on the web page. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585194E25CE9DESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
I know this mailing list is not supposed to be used for market= ing and advertising, so I appologise if this e-mail is seen as inapproriate= by people.
However, as it is very much related to our work, I would like = to inform you that we have done some experiments with the WhatWG APIs for w= eb real-time communication, and have made the implementation available for anyone who would like to test:
You will find contact persons etc on the web page.
Regards,
Christer
 = ;
--_000_7F2072F1E0DE894DA4B517B93C6A0585194E25CE9DESESSCMS0356e_-- From xavier.marjou@gmail.com Fri May 27 00:26:55 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEADBE078A for ; Fri, 27 May 2011 00:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAFnXROCgSU2 for ; Fri, 27 May 2011 00:26:55 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 04B95E0785 for ; Fri, 27 May 2011 00:26:54 -0700 (PDT) Received: by vws12 with SMTP id 12so1447436vws.31 for ; Fri, 27 May 2011 00:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=qoQO2NquVdgXiF8MkmV9OA7Ofj6zrpqTl1zrWxD9xyo=; b=N0r7bNOEsbtjD61PoIepi6WzYHifNe1UpLNVurAUGXybUb8SamZTQQ0GpsIwMLZmfz WgAkiwM4gpnxtxScDgolGZ/qNeiwF+BC0Ye2j9bcHXH8lPOI9h0IlHpjzOiaJ+m47cc3 cYWPAU0lfJk2GlvJaphcKLPmZy+gZyb1lfFd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=CHVslgYUNZ/n7VFGaFiqIy5K6cMqBOorJl3LCpCygrOzwo4E4xV15+eT9Bvb9fsQDP LvdnUxq2XvtIRnJhFoKYWqjgqHeaOdMXLfFSJyBsCeZYpHZfMwQqXZcbCafKzGU/nBNq SelzvoIfcGVuKKYZlvU6f8XMCx4mYnfSvRE88= MIME-Version: 1.0 Received: by 10.52.180.194 with SMTP id dq2mr2575763vdc.105.1306481214159; Fri, 27 May 2011 00:26:54 -0700 (PDT) Sender: xavier.marjou@gmail.com Received: by 10.52.160.35 with HTTP; Fri, 27 May 2011 00:26:54 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E0F11D5@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E0F11D5@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 27 May 2011 09:26:54 +0200 X-Google-Sender-Auth: Rs29QaTTcaP_nFSrxobNA5XahJU Message-ID: From: Xavier Marjou To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=bcaec51967adacfa6804a43cdc31 Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 07:26:56 -0000 --bcaec51967adacfa6804a43cdc31 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, We are willing to contribute to the work on the use-case & requirements document especially with inputs from the "draft- marjou-dispatch-rtcweb-sip-rtp-interwk-reqs". Cheers, Xavier and Jean-Fran=E7ois > > > > > -----Original Message----- > > From: rtcweb-bounces@ietf.org > > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie > > Sent: 4. toukokuuta 2011 3:08 > > To: rtcweb@ietf.org > > Subject: [rtcweb] Contributions for the Interim meeting > > > > As you will have seen from Cullen's announcement, we are now > > officially a working group and starting to collect data on > > the possible timing of an interim meeting. > > > > For the interim meeting, we want to start work on the > > chartered deliverables. If you are interested in being an > > editor for one of the working group docs, the chairs would > > like you to prepare something for the Interim as a draft-00 > > of your take. If you can, raise your hand on the list to say > > you're doing so, so as to let others know to talk to you > > about collaborating. If you are not able to attend any of > > the times put forward for the interim, you can still > > volunteer to edit a document--it just means you'll have to > > have the -00 done early enough for the chairs to find a > > stuckee for feedback coming in at the interim. > > > > regards, > > > > Ted, Cullen, and Magnus > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec51967adacfa6804a43cdc31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

We are will= ing to contribute to the work on the use-case=20 & requirements document especially with inputs from the "draft-marjou-dispatch-rtcweb-sip-rtp-interwk-reqs"= ;.

<= font class=3D"Apple-style-span" color=3D"#000080" face=3D"Arial">Cheers,
Xavier and Jean-Fran=E7ois





> -----Original Message-----
> From: rtcweb-bounces@ietf.o= rg
> [mailto:rtcweb-bounces@ietf= .org] On Behalf Of Ted Hardie
> Sent: 4. toukokuuta 2011 3:08
> To: rtcweb@ietf.org
> Subject: [rtcweb] Contributions for the Interim meeting
>
> As you will have seen from Cullen's announcement, we are now
> officially a working group and starting to collect data on
> the possible timing of an interim meeting.
>
> For the interim meeting, we want to start work on the
> chartered deliverables. =A0If you are interested in being an
> editor for one of the working group docs, the chairs would
> like you to prepare something for the Interim as a draft-00
> of your take. =A0If you can, raise your hand on the list to say
> you're doing so, so as to let others know to talk to you
> about collaborating. =A0If you are not able to attend any of
> the times put forward for the interim, you can still
> volunteer to edit a document--it just means you'll have to
> have the -00 done early enough for the chairs to find a
> stuckee for feedback coming in at the interim.
>
> regards,
>
> Ted, Cullen, and Magnus
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--bcaec51967adacfa6804a43cdc31-- From magnus.westerlund@ericsson.com Mon May 30 08:06:32 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E70BE07E0 for ; Mon, 30 May 2011 08:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.247 X-Spam-Level: X-Spam-Status: No, score=-106.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59GcSuIiwnWq for ; Mon, 30 May 2011 08:06:30 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6BAE07DC for ; Mon, 30 May 2011 08:06:30 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-5a-4de3b2752d0d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 21.5F.09774.572B3ED4; Mon, 30 May 2011 17:06:29 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Mon, 30 May 2011 17:06:29 +0200 Message-ID: <4DE3B274.90803@ericsson.com> Date: Mon, 30 May 2011 17:06:28 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Contributions for the Interim meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 15:06:32 -0000 WG, The Interim meeting is coming up. I would like to remind everyone that has promised to contribute update documents, that these needs to be available to everyone prior to the meeting. And prior enough that people have a chance to read them. Thus before the end of these week they do need to be submitted to IETF as drafts. Cheers Magnus On 2011-05-04 02:07, Ted Hardie wrote: > As you will have seen from Cullen's announcement, we are now > officially a working group and starting to collect data on the > possible timing of an interim meeting. > > For the interim meeting, we want to start work on the chartered > deliverables. If you are interested in being an editor for one of > the working group docs, the chairs would like you to prepare > something for the Interim as a draft-00 of your take. If you can, > raise your hand on the list to say you're doing so, so as to let > others know to talk to you about collaborating. If you are not able > to attend any of the times put forward for the interim, you can still > volunteer to edit a document--it just means you'll have to have the > -00 done early enough for the chairs to find a stuckee for feedback > coming in at the interim. > > regards, > > Ted, Cullen, and Magnus -- 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 ---------------------------------------------------------------------- From fluffy@cisco.com Tue May 31 08:54:24 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906D0E07D6 for ; Tue, 31 May 2011 08:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.495 X-Spam-Level: X-Spam-Status: No, score=-110.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFIOnl+kR6MZ for ; Tue, 31 May 2011 08:54:19 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 56704E0701 for ; Tue, 31 May 2011 08:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2655; q=dns/txt; s=iport; t=1306857259; x=1308066859; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=U578zP7yMIs48h/Mi64NVGyr5AKQt/9ECNWS9PYiWSo=; b=m3tfXItAP4ZxaoYkJrFmn2Fe+TV1jKYtmj1vluY10xRqqx4jHTt4arUI dIC3VSHty1eIbGPn62uY8e7MdXVe10XEmURbeNdXfS8bIkahwufw95pmg XJFwp84v5XiNSfEbwDFspZFcn8YC4dOmFtFhTHObp2mGtbbvvD5URtpuX 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIIAE0O5U2rRDoG/2dsb2JhbAAoDxYDA5gLjhJ3iRCfM5BLjRACgygHBoJnBIZkiWuEPop7 X-IronPort-AV: E=Sophos;i="4.65,297,1304294400"; d="scan'208";a="367386138" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 31 May 2011 15:54:17 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4VFsE8c000476; Tue, 31 May 2011 15:54:14 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 31 May 2011 09:54:13 -0600 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Harald Tveit Alvestrand Subject: [rtcweb] Draft Agenda for RTCWeb Interim Meeting June 8 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 15:54:24 -0000 The main goal for meeting is try to get as much consensus about which = use cases we will try to satisfy and which ones we don't care about. We = will update the draft agenda after we see the drafts come out.=20 Architecture: 30 minutes Use Cases & Solution Requirements: 60 minutes NAT Traversal: 30 minutes Security: 30 minutes RTP Usage: 20 Minutes Non audio/video data: 20 min Any other business: 10 minutes The deadline for drafts is Sunday and we will probably update the agenda = on tuesday, so if you are submitting a draft assume you might need = slides to present on wednesday.=20 Conference bridge information is=20 Topic: RTC Web WG=20 Date: Wednesday, June 8, 2011=20 Time: 7:30 am, Pacific Daylight Time (San Francisco, GMT-07:00)=20 Meeting Number: 204 987 300=20 Meeting Password: ietf=20 ------------------------------------------------------=20 To start the online meeting=20 -------------------------------------------------------=20 1. Go to = https://cisco.webex.com/ciscosales/j.php?ED=3D166273742&UID=3D482186897&PW= =3DNMTAyNWI0Yzdl&RT=3DMiM0=20 2. Log in to your account.=20 3. Click "Start Now".=20 4. Follow the instructions that appear on your screen.=20 -------------------------------------------------------=20 To join the teleconference only=20 -------------------------------------------------------=20 0. Find a local phone number from = http://cisco.com/en/US/about/doing_business/conferencing/index.html=20 A few numbers are=20 San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330=20 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117=20 India: +91.80.4350.1111 Germany: +49.619.6773.9002=20 Japan: +81.3.5763.9394 China: +86.10.8515.5666=20 1. Dial into Cisco WebEx=20 2. Follow the prompts to enter the Meeting Number (l204 987 300) = followed by the # sign.=20 -------------------------------------------------------=20 For assistance=20 -------------------------------------------------------=20 1. Go to https://cisco.webex.com/ciscosales/mc=20 2. On the left navigation bar, click "Support".=20 To add this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 = https://cisco.webex.com/ciscosales/j.php?ED=3D166273742&UID=3D482186897&IC= S=3DMS&LD=3D1&RD=3D2&ST=3D1&SHA2=3DIGsAhT8DkosTrdfDP4EqSGFzCAm14Z1H9uq-AYQ= xgv0=3D=20 To check whether you have the appropriate players installed for UCF = (Universal Communications Format) rich media files, go to = https://cisco.webex.com/ciscosales/systemdiagnosis.php=20 If something goes really wrong, SMS my mobile phone at +1 408 421 9990 From hta@google.com Tue May 31 16:05:26 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9CAE0936 for ; Tue, 31 May 2011 16:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASQDQbuID9Jb for ; Tue, 31 May 2011 16:05:25 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 11EBAE07C5 for ; Tue, 31 May 2011 16:05:24 -0700 (PDT) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p4VN5OWJ019577 for ; Tue, 31 May 2011 16:05:24 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306883124; bh=Q7P+EHycSjkdf1NsEfSQJjtsuKI=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=w5PCAGiwnCuF2yPzRC7HTALuQqr+xMOa6dDxx/tKEn/PnDQOeTfVeqnu6LVIwO8Gy QF9dRjuqy3P6clEzZLo8w== Received: from wwi18 (wwi18.prod.google.com [10.241.243.18]) by kpbe16.cbf.corp.google.com with ESMTP id p4VN5MM5017082 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 31 May 2011 16:05:23 -0700 Received: by wwi18 with SMTP id 18so4644345wwi.17 for ; Tue, 31 May 2011 16:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=UbNZitnirgw7OQDEInV/lloX4w2OoE2OkxlMUORBv5I=; b=Jwunv+BnooUhqJDwQFlu4lFlEWTEv6s0HcOgvOm37lUzoYvlwklFw+2KN+upQU3WoG 9Malbl4Xe64AspOw1Zzw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:content-type; b=eoLmOcpnQmPbcQ2Wq+7tERMvmn5AEi6OTfFe7DZCXaTk/8qxPOG3HPiRLQB833dg7m kePGBdwZWBdZOsbbJexg== Received: by 10.216.50.135 with SMTP id z7mr6279598web.112.1306883122188; Tue, 31 May 2011 16:05:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.153.26 with HTTP; Tue, 31 May 2011 16:05:02 -0700 (PDT) From: Harald Alvestrand Date: Wed, 1 Jun 2011 01:05:02 +0200 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Mailman-Approved-At: Tue, 31 May 2011 17:53:50 -0700 Subject: [rtcweb] Release of WebRTC source code X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 23:05:26 -0000 Today, Google made available WebRTC, an open source software package for real-time voice and video on the web that we will be integrating in Chrome. This is our initial contribution to achieve the mission of making audio and video available in all browsers, through a uniform standard set of APIs. This initial release will provide the functionality we envision for WebRTC/RTCWEB, as detailed at https://sites.google.com/site/webrtc/. Working with the browser community and working groups like this, our goal is to expand the available APIs over the next few months for developers to create voice and video applications on the web. The underlying components we're releasing are stable and the interfaces for this initial release are consistent with the discussions in this working group. We will continue to provide working implementations for consideration and feedback to collectively ensure stable standards are finalized. Google is committed to fully supporting these standards and we look forward to your input in the coming months. Harald, speaking for Google. From alan.b.johnston@gmail.com Tue May 31 20:21:03 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C53E07BC for ; Tue, 31 May 2011 20:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.542 X-Spam-Level: X-Spam-Status: No, score=-103.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjLxRGvZLuSx for ; Tue, 31 May 2011 20:21:02 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B027EE07B9 for ; Tue, 31 May 2011 20:21:02 -0700 (PDT) Received: by ywp31 with SMTP id 31so2830015ywp.31 for ; Tue, 31 May 2011 20:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CFBCvJ5FrovgW+4ukQJSdctVV7BJTfD3/q2tNGxuG/Y=; b=b/SchnJvFqEmcieoVSJVNvqzz+qhF4Vc5UsD1niMibBWr1DOcvIwKJGXuOq3K8rWUO 6PHB2VhtP5n07tj6UNLTxDJQmyyd0M4aszNzKYs8zpI7P8RAH5Yn/O5SMGm8uIQO7p3Q hB08mnunrKKVHzdb3RwaaLuixXzE+NyI4JeiE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DRjbC7pdcTDhftTMOpsGPKED+P7hFnxiZ2sMQu3XTnouSC8QvaqfxekvG5d+QE9aum oBL6GfeX/Fg+2QAEQElMygp8IVGASgOR4QL05mu8we0v816hjoi7htxDo5j2c2oTHtcI 4EiFhy0yg5+F0KbnO+kgMgktxXQrCMDjfNg84= MIME-Version: 1.0 Received: by 10.151.7.5 with SMTP id k5mr5657597ybi.89.1306898462114; Tue, 31 May 2011 20:21:02 -0700 (PDT) Received: by 10.150.138.8 with HTTP; Tue, 31 May 2011 20:21:02 -0700 (PDT) In-Reply-To: <20110601031504.20944.62409.idtracker@ietfa.amsl.com> References: <20110601031504.20944.62409.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2011 22:21:02 -0500 Message-ID: From: Alan Johnston To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Phil Zimmermann Subject: [rtcweb] Fwd: I-D Action: draft-johnston-rtcweb-media-privacy-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 03:21:03 -0000 All, Here is a new draft with some thoughts on media privacy in RTCWEB. We discuss the challenge of providing media privacy for browser users when there is no standardization of the signaling protocol. We also discuss the need to sometimes allow trusted Man in the Middle (MitM) servers to provide media services. We also discuss how ZRTP ("Media Path Key Agreement for Unicast Secure RTP" RFC 6189) meets these requirements. Comments most welcome. - Alan - ---------- Forwarded message ---------- From: Date: Tue, May 31, 2011 at 10:15 PM Subject: I-D Action: draft-johnston-rtcweb-media-privacy-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : RTCWEB Media Privacy =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Alan Johnston =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Philip Zimmermann =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-johnston-rtcweb-media-privac= y-00.txt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 7 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-05-31 =A0 RTCWEB is the joint effort between the IETF and the W3C to add real- =A0 time voice, video, and communication capabilities to browsers. =A0This =A0 document looks at the requirements for media privacy and existing =A0 mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-johnston-rtcweb-media-privacy-00.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-johnston-rtcweb-media-privacy-00.t= xt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From juberti@google.com Tue May 31 20:41:56 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC71E06A1 for ; Tue, 31 May 2011 20:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tk+tU5Nl+c2n for ; Tue, 31 May 2011 20:41:55 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 74ADCE0658 for ; Tue, 31 May 2011 20:41:54 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p513fq44015043 for ; Tue, 31 May 2011 20:41:53 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306899713; bh=Un28Nh9rYUAYQsF9jjm832w/4/A=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=bqadraMyKo5z3tSbQp8yAJMXZ4HyZpF9QGld8muAy1hUZ1fjpZ5SfjnArcxbaVtms lEKjlo1tzcbgadFjLLvag== Received: from qwi2 (qwi2.prod.google.com [10.241.195.2]) by wpaz24.hot.corp.google.com with ESMTP id p513fpbH004037 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 31 May 2011 20:41:51 -0700 Received: by qwi2 with SMTP id 2so2981625qwi.36 for ; Tue, 31 May 2011 20:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iiGgV9xy0xBV3anduOOXaThwT3rEShCHRsgn/8zuDek=; b=wyvaRxBBperNk0yKWnL9qBryptL/9RIepahmTmMpTe6h2PhgmyjIGhUMc2lYEyEZzy IOaU7NhVMFIxyyioYHgQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=i4G2qlg6jnUw3sOc7/mWg0PiUvi8tuX7aZ66vvx6uU87rZHaAtpl5zhDAxvy5P8u8/ p9+HhE1QQbcIEoasc/fQ== Received: by 10.229.88.144 with SMTP id a16mr4824568qcm.45.1306899711139; Tue, 31 May 2011 20:41:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.111.228 with HTTP; Tue, 31 May 2011 20:41:31 -0700 (PDT) In-Reply-To: References: <20110601031504.20944.62409.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Tue, 31 May 2011 20:41:31 -0700 Message-ID: To: Alan Johnston Content-Type: multipart/alternative; boundary=0016364175330a1f5004a49e4dea X-System-Of-Record: true Cc: "rtcweb@ietf.org" , Phil Zimmermann Subject: Re: [rtcweb] Fwd: I-D Action: draft-johnston-rtcweb-media-privacy-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 03:41:56 -0000 --0016364175330a1f5004a49e4dea Content-Type: text/plain; charset=UTF-8 Interesting read. One comment - I believe the statement in this draft "In the RTCWEB architecture, there is no standardization of the signaling protocol possible, and hence this [SRTP SDES] approach can not be used" is not completely accurate. While the syntax of the signaling protocol (e.g. HTTP, XMPP, SIP) is left up to the web application, we must have a clear definition of the protocol semantics, as well as the format of session descriptions (as understood by the browser), so that they can be mapped to SDP / XMPP if desired. Therefore there is no reason we cannot include SRTP keying information in these session descriptions. On Tue, May 31, 2011 at 8:21 PM, Alan Johnston wrote: > All, > > Here is a new draft with some thoughts on media privacy in RTCWEB. We > discuss the challenge of providing media privacy for browser users > when there is no standardization of the signaling protocol. We also > discuss the need to sometimes allow trusted Man in the Middle (MitM) > servers to provide media services. We also discuss how ZRTP ("Media > Path Key Agreement for Unicast Secure RTP" RFC 6189) meets these > requirements. > > Comments most welcome. > > - Alan - > > > ---------- Forwarded message ---------- > From: > Date: Tue, May 31, 2011 at 10:15 PM > Subject: I-D Action: draft-johnston-rtcweb-media-privacy-00.txt > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : RTCWEB Media Privacy > Author(s) : Alan Johnston > Philip Zimmermann > Filename : draft-johnston-rtcweb-media-privacy-00.txt > Pages : 7 > Date : 2011-05-31 > > RTCWEB is the joint effort between the IETF and the W3C to add real- > time voice, video, and communication capabilities to browsers. This > document looks at the requirements for media privacy and existing > mechanisms. > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-johnston-rtcweb-media-privacy-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-johnston-rtcweb-media-privacy-00.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0016364175330a1f5004a49e4dea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Interesting read. One comment - I believe the statement in this draft
<= br>
"In the RTCW= EB architecture, there is no standardization of th= e signaling protocol possible, and hence this [SRTP SDES] approach can not = be used"
is not completely accurate. While the syntax of t= he signaling protocol (e.g. HTTP, XMPP, SIP) is left up to the web applicat= ion, we must have a clear definition of the protocol semantics, as well as = the format of session descriptions (as understood by the browser), so that = they can be mapped to SDP / XMPP if desired.=C2=A0
Therefore there is no reason we cannot include= SRTP keying information in these session descriptions.

On Tue, May 31, 2011 at 8:21 P= M, Alan Johnston <alan.b.johnston@gmail.com> wrote:
All,

Here is a new draft with some thoughts on media privacy in RTCWEB. =C2=A0We=
discuss the challenge of providing media privacy for browser users
when there is no standardization of the signaling protocol. =C2=A0We also discuss the need to sometimes allow trusted Man in the Middle (MitM)
servers to provide media services. We also discuss how ZRTP ("Media Path Key Agreement for Unicast Secure RTP" RFC 6189) meets these
requirements.

Comments most welcome.

- Alan -


---------- Forwarded message ----------
From: =C2=A0<internet-drafts= @ietf.org>
Date: Tue, May 31, 2011 at 10:15 PM
Subject: I-D Action: draft-johnston-rtcweb-media-privacy-00.txt
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : RTCWE= B Media Privacy
=C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : Alan Johnston =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Philip Zimmermann
=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-john= ston-rtcweb-media-privacy-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = 2011-05-31

=C2=A0 RTCWEB is the joint effort between the IETF and the W3C to add real-=
=C2=A0 time voice, video, and communication capabilities to browsers. =C2= =A0This
=C2=A0 document looks at the requirements for media privacy and existing =C2=A0 mechanisms.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft= -johnston-rtcweb-media-privacy-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-j= ohnston-rtcweb-media-privacy-00.txt
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--0016364175330a1f5004a49e4dea--