From nobody Mon Dec 1 00:55:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564E61A1A13 for ; Mon, 1 Dec 2014 00:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTIxkYZ6HK5C for ; Mon, 1 Dec 2014 00:55:24 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 811181A0379 for ; Mon, 1 Dec 2014 00:55:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E33597C3257 for ; Mon, 1 Dec 2014 09:55:21 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nY-eNfaR8Pfj for ; Mon, 1 Dec 2014 09:55:17 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:dda9:53b6:c5d9:2f80]) by mork.alvestrand.no (Postfix) with ESMTPSA id A51CE7C0C5E for ; Mon, 1 Dec 2014 09:55:17 +0100 (CET) Message-ID: <547C2CF5.5000204@alvestrand.no> Date: Mon, 01 Dec 2014 09:55:17 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20141128131903.18180.87191.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/yNT-dkV35goZOwLBEPKsv_qLJx0 Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-13.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2014 08:55:27 -0000 On 11/30/2014 08:44 PM, Makaraju, Maridi Raju (Raju) wrote: >> A WebRTC browser (also called a WebRTC User Agent or WebRTC UA) is >something that conforms to both the protocol specification and the >> Javascript API defined above. > Thanks for adding updates to the terminology, which now captures most > of it. > I have a comment on the above text in 2.2. > > This seem to focus more on WebRTC **browser**. But, there are hybrid > environments, such as Apache Cordova, which are not browsers but can > conform to protocol specification and Javascript API just like a > browser (as most of the times they share same source code as a browser). Android KitKat provided WebView component, that supports WebRTC APIs+Javascript, is one example which is close to native than hybrid environment. To include these use cases, I suggest changing the above text to: > > "A WebRTC User Agent or WebRTC UA is something that conforms to both the protocol specification and the Javascript API defined above. WebRTC browser is one such WebRTC UA. However, other non-browser implementations may conform to WebRTC UA as well." I find it simpler to call all these browsers. The W3C has chosen to coin the term "interactive user agents", but I find that term clumsy in practice. As written: o A WebRTC browser is something that conforms to both the protocol specification and the Javascript API defined above. Browser: Used synonymously with "Interactive User Agent" as defined in the HTML specification [W3C.WD-html5-20110525]. Android WebView in particular is actually Chrome with some of the user interface stripped away. I don't see a compelling reason to use a different term here. > > BR > Raju > >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Friday, November 28, 2014 7:19 AM >> To: i-d-announce@ietf.org >> Cc: rtcweb@ietf.org >> Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-13.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Real-Time Communication in WEB-browsers >> Working Group of the IETF. >> >> Title : Overview: Real Time Protocols for Browser-based >> Applications >> Author : Harald T. Alvestrand >> Filename : draft-ietf-rtcweb-overview-13.txt >> Pages : 22 >> Date : 2014-11-28 >> >> Abstract: >> This document gives an overview and context of a protocol suite >> intended for use with real-time applications that can be deployed in >> browsers - "real time communication on the Web". >> >> It intends to serve as a starting and coordination point to make sure >> all the parts that are needed to achieve this goal are findable, and >> that the parts that belong in the Internet protocol suite are fully >> specified and on the right publication track. >> >> This document is an Applicability Statement - it does not itself >> specify any protocol, but specifies which other specifications WebRTC >> compliant implementations are supposed to follow. >> >> This document is a work item of the RTCWEB working group. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-rtcweb-overview-13 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-13 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 From nobody Mon Dec 1 06:47:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16A61A0174; Mon, 1 Dec 2014 06:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJaBkgFRAQOe; Mon, 1 Dec 2014 06:47:17 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92CFA1A1BF6; Mon, 1 Dec 2014 06:47:15 -0800 (PST) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB1ElC8J009246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Dec 2014 09:47:14 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com sB1ElC8J009246 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1417445234; bh=uStIu0mFVsXd9ZSzSrXAwQlh23M=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=stv0xgJd/PTAXn99Yx+UoUrZTgK+4gJiQttDaKtANkJxxX5L8qRcNTDfJx49XuFdS ALDqJ3FGZUQpbZg82MU8ggSZQwe2SXfM6VtXSo2pKVdjRY8lYOppTWPJ38PsRuREjX W9pqkyntN8evZ0oaRDchXt4ortNI4yoajvC9wS0Q= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com sB1ElC8J009246 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd04.lss.emc.com (RSA Interceptor); Mon, 1 Dec 2014 09:46:20 -0500 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB1Ekvm9016759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Dec 2014 09:46:57 -0500 Received: from MXHUB205.corp.emc.com (10.253.68.31) by mxhub26.corp.emc.com (10.254.110.182) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 1 Dec 2014 09:46:56 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.125]) by MXHUB205.corp.emc.com ([fe80::2b:c770:c6f4:ee06%12]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 09:46:56 -0500 From: "Black, David" To: "tsvwg@ietf.org" , "rtcweb@ietf.org" Thread-Topic: Randell Jesup - where are you? Thread-Index: AdANdaZx097bFkFoT8SszkjA7R8APw== Importance: high X-Priority: 1 Date: Mon, 1 Dec 2014 14:46:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CbqkMOvORqF-NNkpQXxtmngykFk Cc: "Black, David" Subject: [rtcweb] Randell Jesup - where are you? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2014 14:47:20 -0000 Having seen no response from Randell, I'm now adding both the tsvwg and rtcweb lists. If anyone is in touch w/Randell, would you please "encourage" him to get back to us (tsvwg chairs), so that we can move the SCTP DTLS draft forward. Thanks, --David -----Original Message----- From: Black, David [mailto:david.black@emc.com]=20 Sent: Monday, November 17, 2014 5:38 PM To: randell-ietf@jesup.org Cc: tsvwg-chairs@tools.ietf.org; rtcweb-chairs@tools.ietf.org Subject: FW: Author IPR info: draft-ietf-tsvwg-sctp-dtls-encaps-06 Importance: High Randell, Your response to the email below is the only thing currently delaying the RFC Publication request for the SCTP DTLS draft - please respond to the message below at your earliest convenience (and we do need you to respond directly). I've cc:'d the RTCWEB WG chairs in the hope that they can help move this along (Ted - this is what we talked about briefly on Friday morning). Thanks, --David -----Original Message----- From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk]=20 Sent: Wednesday, November 12, 2014 5:30 AM To: Randell Jesup Cc: tsvwg-chairs@tools.ietf.org Subject: Author IPR info: draft-ietf-tsvwg-sctp-dtls-encaps-06 Randell, I don't recall seeing a reply for IPR information about the above draft (if you sent, I'm sorry - but could you send me an email again?) Can you confirm that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? As an incentive - at this moment you are the only thing stopping me submitting this to our AD for publication! Gorry https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-06 From nobody Mon Dec 1 09:27:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A191A86E9 for ; Mon, 1 Dec 2014 09:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qh5w7oNcxg3R for ; Mon, 1 Dec 2014 09:26:55 -0800 (PST) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895F71A86F6 for ; Mon, 1 Dec 2014 09:26:49 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id le20so4922453vcb.38 for ; Mon, 01 Dec 2014 09:26:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ur1MzORuc7PPRKPxJbGCSZi5rWIranjTJgvukvBzl8g=; b=m2RR1ouF5qFPlJaoESDE0SMIN2umpMesmT4AmM0OO/dm+BHq5a8D2cqoNIozA5Y2AD TfSXYj1y0uhlEZss/Nt1ISIzwslztVHh6YsKq+Zz3ATx6rOId5A9bKkPjiXEMY4EmZXI O/a57OPkKNyENuD9kRHt3R0PTMV25FNth88qIOgBWOqyj7mxL/lnR99gD5py1iGHzPmA IAa8FqJ0uKHJEjAoOCJuIygg9R0QoTWkhVFSj01v5RrNQ3V8ktR99lJQQw5lDvxy/QF5 0v+jEAq8vGdOc+Psz8n9erPQLTAy8B/G2MMOLti3aADpR9sUNpGr/OeaBX9bllt2kHbA pbOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ur1MzORuc7PPRKPxJbGCSZi5rWIranjTJgvukvBzl8g=; b=e3TIR6ATopCb0bYMU/6eHwQMgPXvNMFwVGIRPZF6/mi1VaIPU2W3UbP1fN83opJhKZ pfLpsOl2My4da5LdDnpOGx3RLBje/naijMvVPz3SaXsquvqQLflWP6ShFS0Wy88k/cN8 ChTnLkDUnqqpVdjGuMMh+kix6Wr9+WJp+EL5W+VTTt46/mmHdZbdTRHkmzvDwDQqT2hl vHklMqq7REzXbYY6nqaidnE1lDN5dfgLRLwVastGktY/EgnvbdtPpdm874qjrPWoMh0v y380eArYv51QTMuTCdhFUTdNnDXQyHGpHaCdYbYRcsR1HZSpZqjGcct17TVZuu2XWiGf zqDg== X-Gm-Message-State: ALoCoQl5wKMWzXtyBLEydil61E9fm/GbETwDLj5eqtioHGPxm6HteD165xXVgRcyIkqEoCO/ACxz X-Received: by 10.52.136.80 with SMTP id py16mr24458967vdb.54.1417454808197; Mon, 01 Dec 2014 09:26:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Mon, 1 Dec 2014 09:26:28 -0800 (PST) In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> From: Justin Uberti Date: Mon, 1 Dec 2014 09:26:28 -0800 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: multipart/alternative; boundary=bcaec52d4dad54169105092aea35 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HyQfLyZz2yUIMwkkM74blCR7WIk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2014 17:26:57 -0000 --bcaec52d4dad54169105092aea35 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Nov 30, 2014 at 7:26 AM, Stefan H=C3=A5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 30/11/14 16:06, Makaraju, Maridi Raju (Raju) wrote: > >> On 30/11/14 14:51, Makaraju, Maridi Raju (Raju) wrote: > >>>> Hi, > >>>> > >>>>>> RFC 7345 (UDPTL-DTLS) says the following: > >>>>>> > >>>>>> "Once an offer/answer exchange has been completed, either > >>>>>> endpoint > >>>> MAY > >>>>>> send a new offer in order to modify the session. The > >>>>>> endpoints > >>>> can > >>>>>> reuse the existing DTLS association if the key fingerprint > >>>>>> values > >>>> and > >>>>>> transport parameters indicated by each endpoint are unchanged. > >>>>>> Otherwise, following the rules for the initial offer/answer > >>>> exchange, > >>>>>> the endpoints can negotiate and create a new DTLS association > >>>>>> and, once created, delete the previous DTLS association, > >>>>>> following the same rules for the initial offer/answer exchange. > >>>>>> Each endpoint needs to be prepared to receive data on both the > >>>>>> new and old DTLS associations as long as both are alive." > >>>>>> > >>>>>> So, I guess that can be read in a way that the setup attribute > >>>>>> as such > >>>> does not impact previously > >>>>>> negotiated TLS roles - unless the key fingerprint values and/or > >>>>>> transport > >>>> parameters are modified. > >>>>>> > >>>>>> The SCTP-SDP draft currently says that a subsequent offer must > >>>>>> not change > >>>> the previously negotiated roles. But, I guess > >>>>>> we could say something similar as in RFC 7345. > >>>>> > >>>>> I have struggled with this language quite a bit from the > >>>>> implementation > >>>> perspective. I think we need to explicitly state > >>>>> that endpoints MUST reuse the existing association if the key > >>>>> fingerprint > >>>> values and transport parameters indicated > >>>>> by each endpoint are unchanged. > >>>> > >>>> We could take such general approach. > >>>> > >>>> However, for 'SCTP/DTLS' (DTLS over SCTP), I assume that the DTLS > >>>> connection will also be re-established if the underlying SCTP > >>>> association is re- established - even if no transport parameters > >>>> etc are changed. > >>>> > >>>> Also, RFC 6083 says: > >>>> > >>>> "Each DTLS connection MUST be established and terminated within the > >>>> same SCTP association." > >>>> > >>>> > >>>>> The way this language reads to me is that endpoints can reuse the > >>>>> existing > >>>> association if they want to, but they can create a new one if they > >>>> don't. Also, when this new > >>>>> association is created, it is unclear if old setup roles MUST be > >>>>> preserved > >>>> or if they MUST be selected based on the current offer/answer > >>>> exchange. It seems the current > >>>>> specification language is not strong or clear enough on this > >>>>> topic. > >>>> > >>>> In my opinion, IF a new DTLS connection needs to be established > >>>> (for whatever reasons), the current roles should be used. > >>> > >>> When ICE is NOT used, how does the offerer know that the > >>> answerer does not change the fingerprint and/or transport parameters? > >>> I guess it does not know. So, offerer has to be prepared for new DTLS > >>> association by offering actpass. When ICE is used, the answerer can't > >>> change transport parameter unless offerer does ICE restart (which > >>> changes offerer transport parameters); Ref [1] is very clear on this > >>> indicating "DTLS handshake procedure is repeated". However, even when > >>> ICE is used, I do not find any restriction about answerer not > >>> changing fingerprint. So, even without ICE restart answerer can > >>> trigger a DTLS renegotiation by changing its fingerprint. > >>> > >>> To conclude all this, IMO whether ICE is used or not, sending actpass > >>> for all new offers may be cover all possible scenarios. > >> > >> That is also my conclusion based on the discussion so far. > >> > >> I also think the JSEP draft as far as detailed out is correct, but inf= o > >> about how the implementation should behave for Subsequent answers is > >> missing. Text saying that the role must be maintained (unless there is > >> an ICE restart) should be put in there. > > > > > > Hi Stefan, > > Looks like, there is some misunderstanding here. > > Probably my fault in that case :) > > > My conclusion is to include > > actpass, but not the previously negotiated role, in all subsequent > offers, > > not just during ICE-restarts. > > I think that is what the JSEP draft says - and my conclusion is that it > _is_ correct. > > My point was that the _answer_ should (when it is a subsequent answer) > should say the same role as in previous answers (unless there is an ICE > restart). > > I agree the JSEP text should indicate that roles should stay the same. We have had this as a TODO for a while: https://github.com/rtcweb-wg/jsep/issues/72 > > This is to handle the scenario of answerer changing fingerprint, which > > is allowed (i.e. not explicitly disallowed), in a more > > natural way by renegotiating the roles. Entity which wants to change > fingerprint > > may also want to renegotiate the role even when transport parameters ar= e > not changed. > > > > Also, when ICE is not used answerer can change transport parameters > which needs > > renegotiation of roles. > > > > So, to have uniform rules for ICE (restart or not) and no ICE it is > better to > > send the role in subsequent offer as if it is an initial offer (i.e. > actpass). > > That is also my understanding (and what the JSEP draft says). > > > > > > > BR > > Raju > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec52d4dad54169105092aea35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Nov 30, 2014 at 7:26 AM, Stefan H=C3=A5kansson LK <stefan.lk.hakansson@ericsson.com> wrote:
On 30/11/14 16:06, Makaraju, Maridi Raju (Raju) wrote:
>> On 30/11/14 14:51, Makaraju, Maridi Raju (Raju) wrote:
>>>> Hi,
>>>>
>>>>>> RFC 7345 (UDPTL-DTLS) says the following:
>>>>>>
>>>>>> "Once an offer/answer exchange has been compl= eted, either
>>>>>> endpoint
>>>> MAY
>>>>>> send a new offer in order to modify the session.= =C2=A0 The
>>>>>> endpoints
>>>> can
>>>>>> reuse the existing DTLS association if the key fin= gerprint
>>>>>> values
>>>> and
>>>>>> transport parameters indicated by each endpoint ar= e unchanged.
>>>>>> Otherwise, following the rules for the initial off= er/answer
>>>> exchange,
>>>>>> the endpoints can negotiate and create a new DTLS = association
>>>>>> and, once created, delete the previous DTLS associ= ation,
>>>>>> following the same rules for the initial offer/ans= wer exchange.
>>>>>> Each endpoint needs to be prepared to receive data= on both the
>>>>>> new and old DTLS associations as long as both are = alive."
>>>>>>
>>>>>> So, I guess that can be read in a way that the set= up attribute
>>>>>> as such
>>>> does not impact previously
>>>>>> negotiated TLS roles - unless the key fingerprint = values and/or
>>>>>> transport
>>>> parameters are modified.
>>>>>>
>>>>>> The SCTP-SDP draft currently says that a subsequen= t offer must
>>>>>> not change
>>>> the previously negotiated roles. But, I guess
>>>>>> we could say something similar as in RFC 7345.
>>>>>
>>>>> I have struggled with this language quite a bit from t= he
>>>>> implementation
>>>> perspective. I think we need to explicitly state
>>>>> that endpoints MUST reuse the existing association if = the key
>>>>> fingerprint
>>>> values and transport parameters indicated
>>>>> by each endpoint are unchanged.
>>>>
>>>> We could take such general approach.
>>>>
>>>> However, for 'SCTP/DTLS' (DTLS over SCTP), I assum= e that the DTLS
>>>> connection will also be re-established if the underlying S= CTP
>>>> association is re- established - even if no transport para= meters
>>>> etc are changed.
>>>>
>>>> Also, RFC 6083 says:
>>>>
>>>> "Each DTLS connection MUST be established and termina= ted within the
>>>> same SCTP association."
>>>>
>>>>
>>>>> The way this language reads to me is that endpoints ca= n reuse the
>>>>> existing
>>>> association if they want to, but they can create a new one= if they
>>>> don't. Also, when this new
>>>>> association is created, it is unclear if old setup rol= es MUST be
>>>>> preserved
>>>> or if they MUST be selected based on the current offer/ans= wer
>>>> exchange. It seems the current
>>>>> specification language is not strong or clear enough o= n this
>>>>> topic.
>>>>
>>>> In my opinion, IF a new DTLS connection needs to be establ= ished
>>>> (for whatever reasons), the current roles should be used.<= br> >>>
>>> <Raju> When ICE is NOT used, how does the offerer know t= hat the
>>> answerer does not change the fingerprint and/or transport para= meters?
>>> I guess it does not know. So, offerer has to be prepared for n= ew DTLS
>>> association by offering actpass. When ICE is used, the answere= r can't
>>> change transport parameter unless offerer does ICE restart (wh= ich
>>> changes offerer transport parameters); Ref [1] is very clear o= n this
>>> indicating "DTLS handshake procedure is repeated". H= owever, even when
>>> ICE is used, I do not find any restriction about answerer not<= br> >>> changing fingerprint. So, even without ICE restart answerer ca= n
>>> trigger a DTLS renegotiation by changing its fingerprint.
>>>
>>> To conclude all this, IMO whether ICE is used or not, sending = actpass
>>> for all new offers may be cover all possible scenarios.
>>
>> That is also my conclusion based on the discussion so far.
>>
>> I also think the JSEP draft as far as detailed out is correct, but= info
>> about how the implementation should behave for Subsequent answers = is
>> missing. Text saying that the role must be maintained (unless ther= e is
>> an ICE restart) should be put in there.
>
> <Raju>
> Hi Stefan,
> Looks like, there is some misunderstanding here.

Probably my fault in that case :)

> My conclusion is to include
> actpass, but not the previously negotiated role, in all subsequent off= ers,
> not just during ICE-restarts.

I think that is what the JSEP draft says - and my conclusion is that= it
_is_ correct.

My point was that the _answer_ should (when it is a subsequent answer)
should say the same role as in previous answers (unless there is an ICE
restart).

=C2=A0
I agree the JSEP text s= hould indicate that roles should stay the same. We have had this as a TODO = for a while:
https://github.com/rtcweb-wg/jsep/issues/72
=C2=A0
> This is to handle the scenario of answerer changing fingerprint, which=
> is allowed (i.e. not explicitly disallowed), in a more
> natural way by renegotiating the roles. Entity which wants to change f= ingerprint
> may also want to renegotiate the role even when transport parameters a= re not changed.
>
> Also, when ICE is not used answerer can change transport parameters wh= ich needs
> renegotiation of roles.
>
> So, to have uniform rules for ICE (restart or not) and no ICE it is be= tter to
> send the role in subsequent offer as if it is an initial offer (i.e. a= ctpass).

That is also my understanding (and what the JSEP draft says).

> </Raju>
>
> BR
> Raju
>
>


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--bcaec52d4dad54169105092aea35-- From nobody Mon Dec 1 14:43:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0671A9136 for ; Mon, 1 Dec 2014 14:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOdGIMUj_ARp for ; Mon, 1 Dec 2014 14:43:00 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04DC51AC431 for ; Mon, 1 Dec 2014 14:42:59 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id b13so15510794wgh.17 for ; Mon, 01 Dec 2014 14:42:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=mJbOpZDjPjKk8nsr11KjpKcbKR/CoPaPvPVp2tkIQ8M=; b=gLMKCmOvUNVRUBP6Kyyav2PapujlJzbBv46NmTP61bTg5PhTdeRWnWOpyUnCOxLJTP X9lgTMK8NvqaDid13XN3xoxvAsTCGbyopw7ILsFmDJ1NXifLvPGetFq/+KQUKZV+NbpR LKWdLroVUpcGRaWNGSBV6arqLHSNlwRjwl8FUuJxkTIq28aBMfPwICd+gVMbBbhRm/KP 8A0jqoPRE5/pMJ7fb8dJFYR1y4gFzFPkgk1HGxvD2vnjIea/3vHL0z6SePTj5SWC/slb Qlm9TYNL9i1MgjDtRP+e/V+bQORHrQwdwH7Xh02YAfgD86YkAiE37RlkR8EYr0zVrJ9S 5xLQ== X-Gm-Message-State: ALoCoQlK/zVBGv1AgzY39gX/LMpPc61pjEhTFgLp9+6r+0nxWIQrv3Lww3Na/yRbp1gtg1Z0bl+I X-Received: by 10.180.77.170 with SMTP id t10mr89670583wiw.57.1417473778835; Mon, 01 Dec 2014 14:42:58 -0800 (PST) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com. [209.85.212.175]) by mx.google.com with ESMTPSA id h14sm30264548wic.8.2014.12.01.14.42.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Dec 2014 14:42:57 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so26270941wiw.14 for ; Mon, 01 Dec 2014 14:42:57 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.92.116 with SMTP id cl20mr100099508wjb.71.1417473777586; Mon, 01 Dec 2014 14:42:57 -0800 (PST) Received: by 10.216.70.16 with HTTP; Mon, 1 Dec 2014 14:42:57 -0800 (PST) Date: Mon, 1 Dec 2014 17:42:57 -0500 Message-ID: From: Roman Shpount To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7bd910c2fddb3b05092f544e Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RCNt7ykbutF-Dz2XD1R48cvsgN8 Subject: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2014 22:43:01 -0000 --047d7bd910c2fddb3b05092f544e Content-Type: text/plain; charset=UTF-8 Should browsers support new DTLS handshake without it being triggered by offer/answer? I think new DTLS handshake can be triggered at any time by ClientHello or HelloRequest DTLS message. At this point, unless I am missing something, it looks like neither Chrome no Firefox update SRTP keys unless transport parameters or fingerprint is changed due to offer/answer. On the other hand, DTLS end-point can initiate a handshake at any time, for instance to do the DTLS-SRTP rekey. Is this a missing feature or is this some new behavior that needs to be defined? Regards. _____________ Roman Shpount --047d7bd910c2fddb3b05092f544e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Should browsers support new DTLS handshake without it being triggered by offer/ans= wer?

I think ne= w DTLS handshake can be=C2=A0triggered=C2=A0at any time by ClientHello or H= elloRequest DTLS message. At this point, unless I=C2=A0am missing something= , it looks like neither Chrome no Firefox update SRTP keys unless transport= parameters or fingerprint is changed due to offer/answer. On the other han= d, DTLS end-point can initiate a handshake at any time, for instance to do = the DTLS-SRTP rekey. Is this a missing feature or is this some new behavior= that needs to be defined?

Regards.
_____________
Roman Shpount
--047d7bd910c2fddb3b05092f544e-- From nobody Mon Dec 1 15:20:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF9E1ACDE6 for ; Mon, 1 Dec 2014 15:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1khV2KpoVcV for ; Mon, 1 Dec 2014 15:20:07 -0800 (PST) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1BF1ACDE0 for ; Mon, 1 Dec 2014 15:19:51 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id i17so8556472qcy.21 for ; Mon, 01 Dec 2014 15:19:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=GAX85c96A+yKLrnY+gsiISYgPBKpHQsxhtA3zI7foy4=; b=ZVpw/SSKhH7AnGzNLKyu1LBviE5QHPbzzhU1HPINA2y9QLG4HETy6sytom00r9/bww S1PaC/Ii6M5CQKJgg3SBQnV34SUP8pL+oztL+InqFYnhMKueXz0H+Lv7bOCIKNrv4jxP 1YH/Hsl56INSryUcRFxXbDKlyFidYdgJA6Me/8X7uQChPMr5oZn5B/EUpJqZCZNFCQMz aEBu5fqU2YHwYxO261vF3k/9/f8WQPCLYmL42zDJyvLjsmSTTnKNfR6YRpdDqjSuUyA4 hBqaeDMMYz9P4SlpRYS54k5dUr1v1t3xnpny8snJrlv1aGbcBULsYVY9XviTIuayWjKB yYsQ== X-Gm-Message-State: ALoCoQloKBELeFGArcxffu//wDm3AhBMWOzTQB2O6jwWbNGEYvEN2/Ofa1NX46yXIqe/AC+9G0WC X-Received: by 10.229.190.71 with SMTP id dh7mr10739426qcb.5.1417475989912; Mon, 01 Dec 2014 15:19:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Mon, 1 Dec 2014 15:19:29 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 2 Dec 2014 00:19:29 +0100 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tQGVJ7k4KhJeq3tvgrtW9NUE5Ao Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2014 23:20:09 -0000 2014-12-01 23:42 GMT+01:00 Roman Shpount : > Should browsers support new DTLS handshake without it being triggered by > offer/answer? IMHO yes as that is part of DTLS itself and DTLS does not need a SDP O/A in order to renegotiate (assuming same fingerprint is used, of course). > I think new DTLS handshake can be triggered at any time by ClientHello or > HelloRequest DTLS message. At this point, unless I am missing something, = it > looks like neither Chrome no Firefox update SRTP keys unless transport > parameters or fingerprint is changed due to offer/answer. Are you sure of that? AFAIR last time I inspected Chrome DTLS stack (the one based on BoringSSL/OpenSSL) it did include code for DTLS renegotiation and SRTP re-key stuff. I may be wrong. --=20 I=C3=B1aki Baz Castillo From nobody Mon Dec 1 17:36:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3881ACE0E for ; Mon, 1 Dec 2014 17:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9rznqX8Mjj0 for ; Mon, 1 Dec 2014 17:36:09 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2F31ACE0A for ; Mon, 1 Dec 2014 17:36:09 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wp18so9079720obc.1 for ; Mon, 01 Dec 2014 17:36:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Eu5+9YlR25NHG1xqqXUQaVn3J1cu22ELL1vUExTrkCs=; b=GqoPNKqWqAd3FLBXHe+W8qQ6uHs4a62XVKK8fXrErQTFm8cX5nj3VU3wK7RR59Vlvu UicJSs0LB55H7liUOHqZr48e2GCACDuawSgoHM9bC0DuyxO5Z24dwjG9ItY66b0KaNSw oct78K8CzzIVSgKViyYejdSbPwYec9m8rRsAgDVlPr2Bk1Sw/HHxKLBrucOoCVAiosvs o7oTSBwaSx0mWGd4OLhMXe7JePv1HuAkjsxgx1CIHzRVfegqysRl1iHLamTLPyipEMWW QSGrV/Fb9KMPluq39NRLtH09wSmHErF187QE1vTQCqMGBwRxlbMksc19gxC8AP9xc4Eu WfiQ== MIME-Version: 1.0 X-Received: by 10.60.161.76 with SMTP id xq12mr37829687oeb.59.1417484168256; Mon, 01 Dec 2014 17:36:08 -0800 (PST) Received: by 10.202.115.4 with HTTP; Mon, 1 Dec 2014 17:36:08 -0800 (PST) In-Reply-To: References: Date: Mon, 1 Dec 2014 15:36:08 -1000 Message-ID: From: Martin Thomson To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/a_rD8BL4CuHCSemhbpg7nEbXJVU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2014 01:36:10 -0000 On 1 December 2014 at 13:19, I=C3=B1aki Baz Castillo wrote: > IMHO yes as that is part of DTLS itself and DTLS does not need a SDP > O/A in order to renegotiate (assuming same fingerprint is used, of > course). Depends on whether you are talking about renegotiation or a whole new handshake. The former should be OK. I'm fairly certain that the latter fails on Firefox. From nobody Mon Dec 1 18:29:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D22E1A006E for ; Mon, 1 Dec 2014 18:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpFfqUbrdPnx for ; Mon, 1 Dec 2014 18:29:42 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676F41A006C for ; Mon, 1 Dec 2014 18:29:42 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so19499901wiv.2 for ; Mon, 01 Dec 2014 18:29:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OS0zYRdurIzpq74TBmX/QgCPPTOUGLDo9EotOgUjMXw=; b=WOGCdFB3eKeg6OlLKVVsttL+7MA+9Sp34sqV9xGjtYRbuy+8lHdCz2BDLxn3ijypjp 9W+lDKHd3hpW9hRRWawoIuXG2Xzc7rhZNCSA6J2l74QvQG3YzeN9azURfrVlqavZdJmI kik44rJu6ORlKR2mU7r4Kzbxy/3CsSbMx4p17kUb/Zohqyzl6LP0OMlZZPkE3T/O4GaZ HuqfSDaCpCXyHK2iFe/2Ib3/CDIha4pdlyCa9C/z6bDZsqq9yfVIa+camLxifArMKSnD rAAYopqkZTX9CqBVI8hzA5JsnvYlzYymxzqEbuOm6LCYOBuqCfgmRQbolmd4aihS+lgK PFCw== X-Gm-Message-State: ALoCoQl/V+bRUpV6J36f+jNKUhnlHM4i8joQGGRccn3vnC4HKaSK17X98/ga3H/KQTOiaNTMhqKm X-Received: by 10.180.99.1 with SMTP id em1mr1241993wib.29.1417487381232; Mon, 01 Dec 2014 18:29:41 -0800 (PST) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com. [209.85.212.175]) by mx.google.com with ESMTPSA id d5sm29918983wjb.34.2014.12.01.18.29.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Dec 2014 18:29:40 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so26646042wiw.14 for ; Mon, 01 Dec 2014 18:29:40 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.92.116 with SMTP id cl20mr101263294wjb.71.1417487380125; Mon, 01 Dec 2014 18:29:40 -0800 (PST) Received: by 10.216.70.16 with HTTP; Mon, 1 Dec 2014 18:29:40 -0800 (PST) In-Reply-To: References: Date: Mon, 1 Dec 2014 21:29:40 -0500 Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bd910c2c41f800509327f7a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mWPZTcU_13wc-_FFtBrMKLKiBz8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2014 02:29:44 -0000 --047d7bd910c2c41f800509327f7a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Dec 1, 2014 at 8:36 PM, Martin Thomson wrote: > On 1 December 2014 at 13:19, I=C3=B1aki Baz Castillo wrot= e: > > IMHO yes as that is part of DTLS itself and DTLS does not need a SDP > > O/A in order to renegotiate (assuming same fingerprint is used, of > > course). > > Depends on whether you are talking about renegotiation or a whole new > handshake. The former should be OK. I'm fairly certain that the > latter fails on Firefox. > I am talking about renegotiation, such as in https://tools.ietf.org/html/rfc5764#section-5.2, which is essentially a new handshake. The other reason I am asking is the following language: https://tools.ietf.org/html/rfc5763#section-6.6: "The peers can reuse the existing associations if they are compatible (i.e., they have the same key fingerprints and transport parameters), or establish a new one following the same rules are for initial exchanges, tearing down the existing association as soon as the offer/answer exchange is completed. Note that if the active/passive status of the endpoints changes, a new connection MUST be established." Since, based on this paragraph one side can decide that it can reuse and the other side decides to re-establish new DTLS connection, you will end up with an unsolicited handshake on one side. _____________ Roman Shpount --047d7bd910c2c41f800509327f7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 1, 2014 at 8:36 PM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
On 1 December 2014 at 13:= 19, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
> IMHO yes as that is part of DTLS itself and DTLS does not need a SDP > O/A in order to renegotiate (assuming same fingerprint is used, of
> course).

Depends on whether you are talking about renegotiation or a whole ne= w
handshake.=C2=A0 The former should be OK.=C2=A0 I'm fairly certain that= the
latter fails on Firefox.

I am talking about = renegotiation, such as in=C2=A0https://tools.ietf.org/html/rfc5764#secti= on-5.2, which is essentially a new handshake.

The other reason I am asking is= the following language:=C2=A0=C2=A0https://tools.ietf.org/html/rfc5763#section-6.6<= /a>:=C2=A0"The peers can=C2=A0reuse the existing associatio= ns if they are compatible (i.e., they=C2=A0have the same key finge= rprints and transport parameters), or=C2=A0establish a new one fol= lowing the same rules are for initial=C2=A0exchanges, tearing down= the existing association as soon as the=C2=A0offer/answer exchang= e is completed.=C2=A0 Note that if the active/passive=C2=A0status = of the endpoints changes, a new connection MUST be=C2=A0establishe= d."

=
_____________
Roman Shpount

--047d7bd910c2c41f800509327f7a-- From nobody Mon Dec 1 23:28:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711E81A0151 for ; Mon, 1 Dec 2014 23:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlV9gORJtoQ5 for ; Mon, 1 Dec 2014 23:28:03 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4A51A014C for ; Mon, 1 Dec 2014 23:28:02 -0800 (PST) Received: by mail-oi0-f48.google.com with SMTP id u20so8565995oif.35 for ; Mon, 01 Dec 2014 23:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O+0P7C4L4emwrnmVp2817EwdOEkXEpzienKTCwo6pgk=; b=jnx9BRWzkv4y1rUb3WsYud2MCcd96jlUat59kUPvCFnuMtOOMrVWQLN9Q3FBCoFrwq 6FLZ3FDVP+VzEpxJJ5bTqQCF6FVF53eFS2g1ZpDmHZJh6l9N08/vv3THvJqRMQz+gfcb P4KDEe/Qsxolpkwt0fCc1TeBUFEvmJFIZYRXkY3/a4NeIMzz49KOMEUuAcTnKtaqrSS2 XGX8b61/g0xeDWMJxTWDULAatI8az8HRUGijhDjKy28OA4OmmzWCEMHBwJxA5bELTN9X 5/JwyXrcxIm3Uv2Uu8aLvVohSwW1qOgZaP3zFS66r5unMBVVI+Y+TOz5c7dcaEkrQrXw plnw== MIME-Version: 1.0 X-Received: by 10.183.24.129 with SMTP id ii1mr36608398obd.34.1417505282332; Mon, 01 Dec 2014 23:28:02 -0800 (PST) Received: by 10.202.115.4 with HTTP; Mon, 1 Dec 2014 23:28:02 -0800 (PST) In-Reply-To: References: Date: Mon, 1 Dec 2014 21:28:02 -1000 Message-ID: From: Martin Thomson To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5gwwvpRYn3-CVvzwmnPSibdTArM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2014 07:28:04 -0000 On 1 December 2014 at 16:29, Roman Shpount wrote: > I am talking about renegotiation, such as in > https://tools.ietf.org/html/rfc5764#section-5.2, which is essentially a new > handshake. ekr corrected me. Firefox explicitly disables renegotiation. We don't have the machinery in place to re-export SRTP keying material anyway (I suspect that it requires use of MKI). As for the text in RFC 5763, I read that as : if you have a connection, use it; if you don't, or the existing one is "bad" for any reason, make a new one. That is not renegotiation. From nobody Tue Dec 2 01:10:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2E21A19FA for ; Tue, 2 Dec 2014 01:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l89vujPreJ3m for ; Tue, 2 Dec 2014 01:10:51 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C671C1A0AF7 for ; Tue, 2 Dec 2014 01:10:50 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-88-547d8218f1fa Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7C.4A.04231.8128D745; Tue, 2 Dec 2014 10:10:49 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 10:10:48 +0100 From: Christer Holmberg To: Martin Thomson , Roman Shpount Thread-Topic: [rtcweb] Unsolicited DTLS Handshake Thread-Index: AQHQDbgwjr0wkzj8TUKVKwdS4+MXBJx7Tk6AgAAmLgCAAA71AIAAU10AgAAtIvA= Date: Tue, 2 Dec 2014 09:10:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D56BFB2@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvja5kU22IQe8yJotrZ/4xWsy4MJXZ Yu2/dnYHZo+ds+6yeyxZ8pPJ49aUggDmKC6blNSczLLUIn27BK6Me8d9Cz5xVHy+8YC5gXE5 excjB4eEgInE6//mXYycQKaYxIV769lAbCGBI4wS1z86QNiLGSXW7CsHKWcTsJDo/qcNEhYR CJJ4+PAxC4jNLKAucWfxOXYQW1jAQGL6pOnMEDWGEs2nz7JA2H4S2w4vBouzCKhIdC+YAGbz CvhKTNzbCFTDBbTqDZPEsfmzGUESnAKBEh8X3gS7hxHotu+n1jBBLBOXuPVkPhPEzQISS/ac Z4awRSVePv7HCmErSfzYcAnqOB2JBbs/sUHY2hLLFr6GWiwocXLmE5YJjGKzkIydhaRlFpKW WUhaFjCyrGIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjKWDW37r7mBc/drxEKMAB6MSD+/H TzUhQqyJZcWVuYcYpTlYlMR5F52bFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUd+tsb30 R7qsw7uwTo+HczKuSvVPqt7z4rxzzbTON2sPZnWty/n1KaXGrOss1+XGZpV8u0mi+yde6Nnp 2JJo8uThFIl/jqGSXqf+5ByrUprmpZnSr1RbkjvP6NeydvP/Fw6+niLqf+XH20OzebNEsxjv Hfx09f5Gq8Q2e/YPHDttJ/AeOht0QYmlOCPRUIu5qDgRAMfHkCuGAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2j0IS3IeoSkP5AR2sMarQHq5jts Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2014 09:10:53 -0000 Hi, Related to this, session resumption is another feature not commonly support= ed, afaik. (Of course, when using BUNDLE you don't need it.) Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin Thomson Sent: 2. joulukuuta 2014 9:28 To: Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Unsolicited DTLS Handshake On 1 December 2014 at 16:29, Roman Shpount wrote: > I am talking about renegotiation, such as in=20 > https://tools.ietf.org/html/rfc5764#section-5.2, which is essentially=20 > a new handshake. ekr corrected me. Firefox explicitly disables renegotiation. We don't hav= e the machinery in place to re-export SRTP keying material anyway (I suspec= t that it requires use of MKI). As for the text in RFC 5763, I read that as : if you have a connection, use= it; if you don't, or the existing one is "bad" for any reason, make a new = one. That is not renegotiation. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Dec 2 01:47:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5951A1A3C for ; Tue, 2 Dec 2014 01:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.045 X-Spam-Level: X-Spam-Status: No, score=-5.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_LOLITA1=1.865, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9F1vKe8dMATs for ; Tue, 2 Dec 2014 01:46:58 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FEB1A0381 for ; Tue, 2 Dec 2014 01:46:57 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 9FBB9C3AFD092; Tue, 2 Dec 2014 09:46:50 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sB29kqiO004146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 10:46:52 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.75]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 10:46:52 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Christer Holmberg Thread-Topic: [rtcweb] Unsolicited DTLS Handshake Thread-Index: AQHQDbgxEt8/vgw9SE+iQU4BLGVkCJx7Tk6AgAAmLgCAAA71AIAAU10AgAActYCAABmfYA== Date: Tue, 2 Dec 2014 09:46:51 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC36CCE2@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D56BFB2@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D56BFB2@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XIVQIxnLh3v4RlFb4dTS_bgLt3I Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2014 09:47:00 -0000 Hello Christer, fail to see any tight coupling between bundling and (D)TLS session resumpti= on. Both are orthogonal capabilities. You could execute a (D)TLS session resumption procedure for an established/= active (D)TLS session (under the condition of a resumable session) which is= shared by a bundled media group. Why not? Regards, Albrecht -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Dienstag, 2. Dezember 2014 10:11 To: Martin Thomson; Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Unsolicited DTLS Handshake Hi, Related to this, session resumption is another feature not commonly support= ed, afaik. (Of course, when using BUNDLE you don't need it.) Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Martin Thomson Sent: 2. joulukuuta 2014 9:28 To: Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Unsolicited DTLS Handshake On 1 December 2014 at 16:29, Roman Shpount wrote: > I am talking about renegotiation, such as in=20 > https://tools.ietf.org/html/rfc5764#section-5.2, which is essentially=20 > a new handshake. ekr corrected me. Firefox explicitly disables renegotiation. We don't hav= e the machinery in place to re-export SRTP keying material anyway (I suspec= t that it requires use of MKI). As for the text in RFC 5763, I read that as : if you have a connection, use= it; if you don't, or the existing one is "bad" for any reason, make a new = one. That is not renegotiation. _______________________________________________ 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 From nobody Tue Dec 2 04:54:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977101A1B2E for ; Tue, 2 Dec 2014 04:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gg1S3GBwc35 for ; Tue, 2 Dec 2014 04:54:46 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989AC1A1B43 for ; Tue, 2 Dec 2014 04:54:45 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so27919237wiv.11 for ; Tue, 02 Dec 2014 04:54:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UbQTcGhWttvmIvO2iwrHp4oUCY2owdF5aD0DP7UB6vc=; b=gIFzKG1nsVjmqdxR4sNz4TWn4nFSmXm7yO/Yp9Vd8bTEdLsqQ+IujinDAJuYXnGOWf FAbsI0ZSg30i5waOiVqkczY6CjneofKhXH2NITfd1PG+YOIGylqh57kdaqvBQL0wn5N3 BYRaQExrnVll+PT8/D2KD2XoXAf2lSFBIf3Nn1bWbqfcSpsxYPFc4fI2qPQU4CW4ASNJ XzMe8o5dq1/Sph1OABMwDMfp44K0/NSbeAPHePgA96tW+9l+LU1QJTSJWMSnbfmaHwBH 1Zw8qDEMvvWdjGXWuBN/kCN18IHF9h1iagt5Ti44VML+RciAW3XVD5F89u1tlxFNzDdU HzUg== X-Gm-Message-State: ALoCoQlUBsXD+ibnVU9PpqmBeSBi6HJ4QCs/P4s2hZt2JxzRVhOqVB0qAahgj8hGNWkp8S9dMFAo X-Received: by 10.194.83.8 with SMTP id m8mr103977191wjy.58.1417524884377; Tue, 02 Dec 2014 04:54:44 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com. [74.125.82.53]) by mx.google.com with ESMTPSA id eu15sm32653631wid.18.2014.12.02.04.54.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 04:54:43 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id l18so16996957wgh.12 for ; Tue, 02 Dec 2014 04:54:43 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.96.42 with SMTP id dp10mr84384682wib.38.1417524883146; Tue, 02 Dec 2014 04:54:43 -0800 (PST) Received: by 10.216.70.16 with HTTP; Tue, 2 Dec 2014 04:54:43 -0800 (PST) In-Reply-To: References: Date: Tue, 2 Dec 2014 07:54:43 -0500 Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d0444806d1ece6c05093b3ba8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Vw9ZEWijiyhcRu6y0OM09osg7t4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2014 12:54:49 -0000 --f46d0444806d1ece6c05093b3ba8 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 2, 2014 at 2:28 AM, Martin Thomson wrote: > ekr corrected me. Firefox explicitly disables renegotiation. We > don't have the machinery in place to re-export SRTP keying material > anyway (I suspect that it requires use of MKI). > Chrome on the other hand has renegotiation enabled but does not have the code to detect it and to re-export SRTP keys. My question is, should disabling renegotiation be codified somewhere (like JSEP) or is this something that is going to be implemented? If renegotiation is somehow an optional feature, how does one know that remote party supports it? Also, what happens when transport parameters stay the same but the fingerprint changes? This definitely requires a new DTLS connection, but you will still need to de-mux SRTP packets belonging to the old and new SRTP contexts somehow. This is not that different from rekey. > As for the text in RFC 5763, I read that as : if you have a > connection, use it; if you don't, or the existing one is "bad" for any > reason, make a new one. That is not renegotiation. > What happens if one side decides it does not like its connection and the other side decides to keep it? In such case one side will start a new handshake but the other side will not expect it. The specification needs to define when new connection MUST be created and when new connection MUST not be created to work consistently. Alternatively DTLS end point should be prepared to handle ClientHello or HelloRequest at any time, as well as, actively solicit the handshake when in passive mode by sending periodic HelloRequests to make sure both sides participate. Finally, JSEP should define what can be changed on the DTLS connection. I think it was already agreed on the list that the setup roles should be preserved (btw is this a SHOULD or a MUST?). What about the fingerprint? Is it legal to change it without changing transport parameters? _____________ Roman Shpount --f46d0444806d1ece6c05093b3ba8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 2, 2014 at 2:28 AM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
ekr corrected me.=C2=A0 Firefox= explicitly disables renegotiation.=C2=A0 We
don't have the machinery in place to re-export SRTP keying material
anyway (I suspect that it requires use of MKI).

Chrome on the other hand has renegotiation enabled but does not ha= ve the code to detect it and to re-export SRTP keys. My question is, should= disabling renegotiation be codified somewhere (like JSEP) or is this somet= hing that is going to be implemented? If renegotiation is somehow an option= al feature, how does one know that remote party supports it?

=
Also, what happens when transport parameters stay the same but t= he fingerprint changes? This definitely requires a new DTLS connection, but= you will still need to de-mux SRTP packets belonging to the old and new SR= TP contexts somehow. This is not that different from rekey.

<= /div>
=C2=A0
As for the text in RFC 5763, I read = that as : if you have a
connection, use it; if you don't, or the existing one is "bad"= ; for any
reason, make a new one.=C2=A0 That is not renegotiation.

What happens if one= side decides it does not like its connection and the other side decides to= keep it? In such case one side will start a new handshake but the other si= de will not expect it. The specification needs to define when new connectio= n MUST be created and when new connection MUST not be created to work consi= stently. Alternatively DTLS end point should be prepared to handle=C2=A0ClientHello or HelloRequest at any time, as well as, actively = solicit the handshake when in passive mode by sending periodic HelloRequest= s to make sure both sides participate.

Finally, JSEP should define what can be changed on the DTLS connection= . I think it was already agreed on the list that the setup roles should be = preserved (btw is this a SHOULD or a MUST?). What about the fingerprint? Is= it legal to change it without changing transport parameters?
<= div class=3D"gmail_extra">
_____________=
Roman Shpount

--f46d0444806d1ece6c05093b3ba8-- From nobody Tue Dec 2 05:06:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDE01A1B46 for ; Tue, 2 Dec 2014 05:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cX0Jnxi9CxXy for ; Tue, 2 Dec 2014 05:06:52 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10101A1B01 for ; Tue, 2 Dec 2014 05:06:51 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-99-547db969f398 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 31.7E.24955.969BD745; Tue, 2 Dec 2014 14:06:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 14:06:49 +0100 From: Christer Holmberg To: Roman Shpount , Martin Thomson Thread-Topic: [rtcweb] Unsolicited DTLS Handshake Thread-Index: AQHQDbgwjr0wkzj8TUKVKwdS4+MXBJx7Tk6AgAAmLgCAAA71AIAAU10AgABbRoCAABFToA== Date: Tue, 2 Dec 2014 13:06:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D56EA42@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+JvjW7WztoQg3X/mC2unfnHaDHjwlRm i7X/2tkdmD12zrrL7rFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgyFr3rYiu4JFnxu+0SYwPj H4kuRk4OCQETicV7z7NA2GISF+6tZ+ti5OIQEjjCKPHuz1omCGcxo8TH9n72LkYODjYBC4nu f9ogDSICQRLPp89nArGZBdQl7iw+xw5iCwsYSEyfNJ0ZosZQovn0WRYIO0zi47utYHEWARWJ v18vsYHYvAK+ElPuTGSB2LWZWeL3449gRZwCgRIPlsxkBbEZga77fmoN1DJxiVtPIBZLCAhI LNlznhnCFpV4+fgfK4StJPFjwyUWkJuZBTQl1u/Sh2hVlJjS/ZAdYq+gxMmZT1gmMIrNQjJ1 FkLHLCQds5B0LGBkWcUoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGE8Ht/xW3cF4+Y3jIUYB DkYlHt4Pn2pChFgTy4orcw8xSnOwKInzLjw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD Y+WU9DPafEleegtb9a9Yfa/XFmpwyxVawvHnotVsdtdP/7K+pUgHH6xuym3hbDnVIfuxV/F9 ftKeHXwlWx5EFp15oNv2dvXLWG6JBs3LfYfNn20xvxTJNaN2zZec3sz/SpH2mS0XmDlZw+OF mDVqN04tf7PLQTlW7k547Ke66DXiyTwPr7sosRRnJBpqMRcVJwIAywEUEYgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wx-y_fZ1Crnp9R1VKtK0X2XnydQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2014 13:06:56 -0000 SGksDQoNCj4+ZWtyIGNvcnJlY3RlZCBtZS7CoCBGaXJlZm94IGV4cGxpY2l0bHkgZGlzYWJsZXMg cmVuZWdvdGlhdGlvbi7CoCBXZQ0KPj5kb24ndCBoYXZlIHRoZSBtYWNoaW5lcnkgaW4gcGxhY2Ug dG8gcmUtZXhwb3J0IFNSVFAga2V5aW5nIG1hdGVyaWFsDQo+PmFueXdheSAoSSBzdXNwZWN0IHRo YXQgaXQgcmVxdWlyZXMgdXNlIG9mIE1LSSkuDQo+DQo+IENocm9tZSBvbiB0aGUgb3RoZXIgaGFu ZCBoYXMgcmVuZWdvdGlhdGlvbiBlbmFibGVkIGJ1dCBkb2VzIG5vdCBoYXZlIHRoZSBjb2RlIHRv IGRldGVjdCBpdCBhbmQgdG8gcmUtZXhwb3J0IFNSVFAga2V5cy4gTXkgcXVlc3Rpb24gaXMsIHNo b3VsZCBkaXNhYmxpbmcgcmVuZWdvdGlhdGlvbiANCj4gYmUgY29kaWZpZWQgc29tZXdoZXJlIChs aWtlIEpTRVApIG9yIGlzIHRoaXMgc29tZXRoaW5nIHRoYXQgaXMgZ29pbmcgdG8gYmUgaW1wbGVt ZW50ZWQ/IElmIHJlbmVnb3RpYXRpb24gaXMgc29tZWhvdyBhbiBvcHRpb25hbCBmZWF0dXJlLCBo b3cgZG9lcyBvbmUga25vdyB0aGF0IHJlbW90ZSBwYXJ0eSBzdXBwb3J0cyBpdD8NCg0KV2VsbCwg d2UgaGF2ZSBtZWNoYW5pc21zIHRvIGluZGljYXRlIHN1cHBvcnQgb2Ygc29tZXRoaW5nLiBJbiBT RFAgd2UgY2FuIGRlZmluZSBhbiBhdHRyaWJ1dGUsIGluIFNJUCB3ZSBjYW4gZGVmaW5lIGEgbWVk aWEgZmVhdHVyZSB0YWcvb3B0aW9uIHRhZy4gSSBhc3N1bWUgdGhlcmUgYXJlIHdheXMgb24gdGhl IERUTFMgbGV2ZWwgdG8gaW5kaWNhdGUgc3VwcG9ydCBhbHNvPw0KDQo+IEFsc28sIHdoYXQgaGFw cGVucyB3aGVuIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIHN0YXkgdGhlIHNhbWUgYnV0IHRoZSBmaW5n ZXJwcmludCBjaGFuZ2VzPyBUaGlzIGRlZmluaXRlbHkgcmVxdWlyZXMgYSBuZXcgRFRMUyBjb25u ZWN0aW9uLCBidXQgeW91IHdpbGwgc3RpbGwgbmVlZCB0byBkZS1tdXggDQo+IFNSVFAgcGFja2V0 cyBiZWxvbmdpbmcgdG8gdGhlIG9sZCBhbmQgbmV3IFNSVFAgY29udGV4dHMgc29tZWhvdy4gVGhp cyBpcyBub3QgdGhhdCBkaWZmZXJlbnQgZnJvbSByZWtleS4NCj4NCj4gQXMgZm9yIHRoZSB0ZXh0 IGluIFJGQyA1NzYzLCBJIHJlYWQgdGhhdCBhcyA6IGlmIHlvdSBoYXZlIGENCj4gY29ubmVjdGlv biwgdXNlIGl0OyBpZiB5b3UgZG9uJ3QsIG9yIHRoZSBleGlzdGluZyBvbmUgaXMgImJhZCIgZm9y IGFueQ0KPiByZWFzb24sIG1ha2UgYSBuZXcgb25lLsKgIFRoYXQgaXMgbm90IHJlbmVnb3RpYXRp b24uDQo+DQo+IFdoYXQgaGFwcGVucyBpZiBvbmUgc2lkZSBkZWNpZGVzIGl0IGRvZXMgbm90IGxp a2UgaXRzIGNvbm5lY3Rpb24gYW5kIHRoZSBvdGhlciBzaWRlIGRlY2lkZXMgdG8ga2VlcCBpdD8g SW4gc3VjaCBjYXNlIG9uZSBzaWRlIHdpbGwgc3RhcnQgYSBuZXcgaGFuZHNoYWtlIGJ1dA0KPiB0 aGUgb3RoZXIgc2lkZSB3aWxsIG5vdCBleHBlY3QgaXQuIFRoZSBzcGVjaWZpY2F0aW9uIG5lZWRz IHRvIGRlZmluZSB3aGVuIG5ldyBjb25uZWN0aW9uIE1VU1QgYmUgY3JlYXRlZCBhbmQgd2hlbiBu ZXcgY29ubmVjdGlvbiBNVVNUIG5vdCBiZSBjcmVhdGVkIHRvIA0KPiB3b3JrIGNvbnNpc3RlbnRs eS4gQWx0ZXJuYXRpdmVseSBEVExTIGVuZCBwb2ludCBzaG91bGQgYmUgcHJlcGFyZWQgdG8gaGFu ZGxlwqBDbGllbnRIZWxsbyBvciBIZWxsb1JlcXVlc3QgYXQgYW55IHRpbWUsIGFzIHdlbGwgYXMs IGFjdGl2ZWx5IHNvbGljaXQgdGhlIGhhbmRzaGFrZSANCj4gd2hlbiBpbiBwYXNzaXZlIG1vZGUg Ynkgc2VuZGluZyBwZXJpb2RpYyBIZWxsb1JlcXVlc3RzIHRvIG1ha2Ugc3VyZSBib3RoIHNpZGVz IHBhcnRpY2lwYXRlLg0KDQpJZiBubyBlbmRwb2ludCBzdXBwb3J0cyByZW5lZ290aWF0aW9uLCBJ IGd1ZXNzIHRoZXkgd29uJ3QgZGVjaWRlIG5vdCB0byBsaWtlIHRoZSBjb25uZWN0aW9uIChvciwg aWYgdGhleSBkbywgcGVyaGFwcyB0aGV5IHdpbGwgdGVybWluYXRlIHRoZSB3aG9sZSBjYWxsKS4N Cg0KPiBGaW5hbGx5LCBKU0VQIHNob3VsZCBkZWZpbmUgd2hhdCBjYW4gYmUgY2hhbmdlZCBvbiB0 aGUgRFRMUyBjb25uZWN0aW9uLiBJIHRoaW5rIGl0IHdhcyBhbHJlYWR5IGFncmVlZCBvbiB0aGUg bGlzdCB0aGF0IHRoZSBzZXR1cCByb2xlcyBzaG91bGQgYmUgcHJlc2VydmVkIChidHcgaXMgdGhp cyBhIFNIT1VMRCBvciBhIE1VU1Q/KS4gV2hhdCBhYm91dCB0aGUgZmluZ2VycHJpbnQ/IElzIGl0 IGxlZ2FsIHRvIGNoYW5nZSBpdCB3aXRob3V0IGNoYW5naW5nIHRyYW5zcG9ydCBwYXJhbWV0ZXJz Pw0KDQpBZ2FpbiwgSSBkb24ndCB0aGluayB0aGlzIGJlbG9uZyB0byBKU0VQLiBJdCBpcyBhIGdl bmVyaWMgU0RQIE9mZmVyL0Fuc3dlciBpc3N1ZS4NCg0KUmVnYXJkcw0KDQpDaHJpc3Rlcg0KDQoN Cg== From nobody Tue Dec 2 05:46:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84331A1BB0 for ; Tue, 2 Dec 2014 05:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXTkoKBWFLIK for ; Tue, 2 Dec 2014 05:45:58 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEAC81A1BAD for ; Tue, 2 Dec 2014 05:45:57 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id h11so20990088wiw.15 for ; Tue, 02 Dec 2014 05:45:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=afRDlcbn0T0oKKKtCqRLCDlVeztN8ZWbnRRMIaIDJwI=; b=VwUAkz7R+k9PLGltbu8jDukMwaaOTBsFEIkq//XqUbl7DEahnMZUkGLMlqx7bLnl+9 6t1FYFXuh0Q9uuwXOgS6KOBKhq0D1sDxoLtpHYiVWaounoI9F3PUnCAyV7Hc/yJZwVb8 Av4/DhdviyMCp3LM8ia9ff6MR8Enp9UE/hZAOrJp+uxCxbHEpXx/IuPj92GPWL7BRmDB HtFm4GiPh3Nazh9NY1RyehArOxjWTZqEXofo3SXOE79dqPqTucHDRghR7aQqQFLTuWME sRQZAJ1OqmlW2UdIawzBBBp/eEjSJfqHiaIueC7EcL7GQTaitlLRSnsIL10KU2x6z0XC vioA== X-Gm-Message-State: ALoCoQkbJb5h2eThEmJzVjbN8eFworovs6eGr/Xul8nlpeYNqYJfCYg6aD+ob8sx6Vz8D28U3Kk7 X-Received: by 10.180.21.140 with SMTP id v12mr94081904wie.44.1417527956371; Tue, 02 Dec 2014 05:45:56 -0800 (PST) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com. [209.85.212.175]) by mx.google.com with ESMTPSA id ej10sm6384465wib.2.2014.12.02.05.45.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 05:45:55 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so28159936wiw.2 for ; Tue, 02 Dec 2014 05:45:55 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.73.101 with SMTP id k5mr14326182wiv.43.1417527955028; Tue, 02 Dec 2014 05:45:55 -0800 (PST) Received: by 10.216.70.16 with HTTP; Tue, 2 Dec 2014 05:45:54 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D56EA42@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D56EA42@ESESSMB209.ericsson.se> Date: Tue, 2 Dec 2014 08:45:54 -0500 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=f46d043c7efa38076605093bf2b9 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eXXsUpDJmqRGQ8c4HquUZt1dLlY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2014 13:46:00 -0000 --f46d043c7efa38076605093bf2b9 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 2, 2014 at 8:06 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Chrome on the other hand has renegotiation enabled but does not have the > code to detect it and to re-export SRTP keys. My question is, should > disabling renegotiation > > be codified somewhere (like JSEP) or is this something that is going to > be implemented? If renegotiation is somehow an optional feature, how does > one know that remote party supports it? > > Well, we have mechanisms to indicate support of something. In SDP we can > define an attribute, in SIP we can define a media feature tag/option tag. I > assume there are ways on the DTLS level to indicate support also? > I do not think this was ever consider an optional feature and because of this there is no option to negotiate it. > > Finally, JSEP should define what can be changed on the DTLS connection. > I think it was already agreed on the list that the setup roles should be > preserved (btw is this a SHOULD or a MUST?). What about the fingerprint? Is > it legal to change it without changing transport parameters? > > Again, I don't think this belong to JSEP. It is a generic SDP Offer/Answer > issue. > > Supposedly, JSEP will already define that DTLS setup role cannot be changed. Why is fingerprint any different? I think DTLS and DTLS-SRTP end-points must supports rekey and renegotiation. I do not think DTLS or DTLS-SRTP is broken or unclear (of cause, this can always be improved). It looks like the mandatory DTLS capability is missing from the current browser implementations. So, either the rtcweb browsers should implement this or specification should be created to explain how browsers will work without it. If the second path is chosen, then this discussion should probably move to other groups, such as MMUSIC. The less attractive option is to argue that this is a rtcweb specific DTLS profile and keep it non-inter-operable with regular DTLS/DTLS-SRTP. _____________ Roman Shpount --f46d043c7efa38076605093bf2b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 2, 2014 at 8:06 AM, Christer Holmberg <christer.holmb= erg@ericsson.com> wrote:
> Chrome on the other hand has renegotiation enabled but does not have = the code to detect it and to re-export SRTP keys. My question is, should di= sabling renegotiation
> be codified somewhere (like JSEP) or is this something that is going t= o be implemented? If renegotiation is somehow an optional feature, how does= one know that remote party supports it?

Well, we have mechanisms to indicate support of something. In SDP we= can define an attribute, in SIP we can define a media feature tag/option t= ag. I assume there are ways on the DTLS level to indicate support also?
=

I do not think this was ever consider an o= ptional feature and because of this there is no option to negotiate it.=C2= =A0
> Finally, JSEP should define= what can be changed on the DTLS connection. I think it was already agreed = on the list that the setup roles should be preserved (btw is this a SHOULD = or a MUST?). What about the fingerprint? Is it legal to change it without c= hanging transport parameters?

Again, I don't think this belong to JSEP. It is a generic SDP Of= fer/Answer issue.

=C2=A0
Supposedly, JSEP will already define= that DTLS setup role cannot be changed. Why is fingerprint any different?<= br>

I think DTLS and DTLS-SRTP end-points must sup= ports rekey and renegotiation. I do not think DTLS or DTLS-SRTP is broken o= r unclear (of cause, this can always be improved). It looks like the mandat= ory DTLS capability is missing from the current browser implementations. So= , either the rtcweb browsers should implement =C2=A0this or specification s= hould be created to explain how browsers will work without it.=C2=A0 If the= second path is chosen, then this discussion should probably move to other = groups, such as MMUSIC.=C2=A0 The less attractive option is to argue that t= his is a rtcweb specific DTLS profile and keep it non-inter-operable with r= egular DTLS/DTLS-SRTP.=C2=A0
_____________
Roman Shpount

<= /div>
--f46d043c7efa38076605093bf2b9-- From nobody Tue Dec 2 06:40:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B6E1ACE23 for ; Tue, 2 Dec 2014 06:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAArIaK98OOA for ; Tue, 2 Dec 2014 06:40:45 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 89D0A1ACE20 for ; Tue, 2 Dec 2014 06:40:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id A34157C328E for ; Tue, 2 Dec 2014 15:40:44 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIB7ZQtENu1h for ; Tue, 2 Dec 2014 15:40:44 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:314f:ca23:f1d:9cee]) by mork.alvestrand.no (Postfix) with ESMTPSA id D8C717C3270 for ; Tue, 2 Dec 2014 15:40:43 +0100 (CET) Message-ID: <547DCF6A.5040007@alvestrand.no> Date: Tue, 02 Dec 2014 15:40:42 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FH033UAarPgq9oG3d-FhhZDdm-g Subject: [rtcweb] rtcweb-overview and rtcweb-transports are now on github X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2014 14:40:48 -0000 I have created repositories for these 2 documents under my account on github: git@github.com:alvestrand/rtcweb-transport.git git@github.com:alvestrand/rtcweb-overview.git Please file issues that you have with these documents there. Harald (PS: If the owners of the "rtcweb" account want to have repos and issue trackers hosted under that account, feel free to clone - I'll follow) From nobody Wed Dec 3 03:02:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02861A1A4E for ; Wed, 3 Dec 2014 03:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymr81Eqn5hUk for ; Wed, 3 Dec 2014 03:01:59 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDFAF1A0379 for ; Wed, 3 Dec 2014 03:01:58 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-26-547eeda4a123 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 02.3A.24955.4ADEE745; Wed, 3 Dec 2014 12:01:56 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 12:01:56 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Roman Shpount , Christer Holmberg Thread-Topic: [rtcweb] Unsolicited DTLS Handshake Thread-Index: AQHQDbgwUx1qYQbt0UW184QphZppJQ== Date: Wed, 3 Dec 2014 11:01:56 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D0EDF50@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D56EA42@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje6St3UhBvebLC1mXJjKbLH2Xzu7 A5PHkiU/mTxuTSkIYIrisklJzcksSy3St0vgyth0egtbwTmRivlvPjM3MB4V6GLk5JAQMJFY 0neAFcIWk7hwbz1bFyMXh5DAEUaJVwsXMEM4ixklNrevYwSpYhMIlNi6bwEbiC0iEC1xue0/ M4jNLKAucWfxOXYQW1jAQGLrgl2sEDWGEs2nz7JA2HoSm+ZMBqthEVCR+Nl3EKiXg4NXwFdi +T5niF37WCSe/z0KNpMR6KLvp9YwQcwXl7j1ZD4TxKUCEkv2nGeGsEUlXj7+B/WBksSi25+h 6vUkbkydwgZha0ssW/garJ5XQFDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxShanFqclJtu ZKyXWpSZXFycn6eXl1qyiREYJwe3/FbdwXj5jeMhRgEORiUe3g01dSFCrIllxZW5hxilOViU xHkXnpsXLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFxakIoO3tT4p8fc5gEeuamJpupRkjP XV3fPOfbas45u82qbTQX/Flq5c2yQ559we9TRYwvbzq1ec0utbl58+DRRLb7xT1sGic5OLM+ X39sfeyyZfT1T1ptlULm62OLJHWdmE8an5lmYejvqtXewjdN5t2nWau2XJNcvNNRl1/uVWfj qdWCPr+UWIozEg21mIuKEwFhZZ1hdAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7Nelp6tgr6qRr6_s0kuGiF3ajLA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 11:02:06 -0000 On 02/12/14 14:46, Roman Shpount wrote:=0A= > On Tue, Dec 2, 2014 at 8:06 AM, Christer Holmberg=0A= > >= =0A= > wrote:=0A= >=0A= > > Chrome on the other hand has renegotiation enabled but does not hav= e the code to detect it and to re-export SRTP keys. My question is, should = disabling renegotiation=0A= > > be codified somewhere (like JSEP) or is this something that is goin= g to be implemented? If renegotiation is somehow an optional feature, how d= oes one know that remote party supports it?=0A= >=0A= > Well, we have mechanisms to indicate support of something. In SDP we= =0A= > can define an attribute, in SIP we can define a media feature=0A= > tag/option tag. I assume there are ways on the DTLS level to=0A= > indicate support also?=0A= >=0A= >=0A= > I do not think this was ever consider an optional feature and because of= =0A= > this there is no option to negotiate it.=0A= >=0A= > > Finally, JSEP should define what can be changed on the DTLS connect= ion. I think it was already agreed on the list that the setup roles should = be preserved (btw is this a SHOULD or a MUST?). What about the fingerprint?= Is it legal to change it without changing transport parameters?=0A= >=0A= > Again, I don't think this belong to JSEP. It is a generic SDP=0A= > Offer/Answer issue.=0A= >=0A= > Supposedly, JSEP will already define that DTLS setup role cannot be=0A= > changed. Why is fingerprint any different?=0A= >=0A= > I think DTLS and DTLS-SRTP end-points must supports rekey and=0A= > renegotiation. I do not think DTLS or DTLS-SRTP is broken or unclear (of= =0A= > cause, this can always be improved). It looks like the mandatory DTLS=0A= > capability is missing from the current browser implementations. So,=0A= > either the rtcweb browsers should implement this or specification=0A= > should be created to explain how browsers will work without it.=0A= =0A= I agree, we really need to decide on this (and other stuff) to enable =0A= independent implementations to interoperate.=0A= =0A= Is there any reason for not implementing according to DTLS/DTLS-SRTP =0A= specs? If not, I think that is what we should mandate.=0A= =0A= > If the=0A= > second path is chosen, then this discussion should probably move to=0A= > other groups, such as MMUSIC. The less attractive option is to argue=0A= > that this is a rtcweb specific DTLS profile and keep it=0A= > non-inter-operable with regular DTLS/DTLS-SRTP.=0A= > _____________=0A= > Roman Shpount=0A= >=0A= =0A= From nobody Wed Dec 3 04:09:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09F51A0461 for ; Wed, 3 Dec 2014 04:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrZ1b6UmcmBK for ; Wed, 3 Dec 2014 04:09:48 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C051A1A80 for ; Wed, 3 Dec 2014 04:09:47 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-bd-547efd89b55b Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3E.27.24955.98DFE745; Wed, 3 Dec 2014 13:09:45 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 13:09:45 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= , Roman Shpount Thread-Topic: [rtcweb] Unsolicited DTLS Handshake Thread-Index: AQHQDbgwjr0wkzj8TUKVKwdS4+MXBJx9xuEg Date: Wed, 3 Dec 2014 12:09:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D573154@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D56EA42@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EDF50@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0EDF50@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjW7n37oQg4s/rC1mXJjKbLH2Xzu7 A5PHkiU/mTxuTSkIYIrisklJzcksSy3St0vgyuj6eJa5oEO64krzDdYGxu2iXYycHBICJhKt R1qYIWwxiQv31rN1MXJxCAkcYZR4MuU6E4SzmFFi74atQFUcHGwCFhLd/7RBGkQEiiS6/vWy gtjMAuoSdxafYwexhQUMJKZPms4MUWMo0Xz6LAuEbSSx58M6RhCbRUBF4tznzWA1vAK+Eisn PWWH2NXEKnH+2nsmkASngJ/Ek0t32UBsRqDrvp9awwSxTFzi1pP5TBBXC0gs2XMe6gNRiZeP /7FC2IoS7U8bGCHq9SRuTJ3CBmFrSyxb+BpqsaDEyZlPWCYwis1CMnYWkpZZSFpmIWlZwMiy ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwfg5u+a26g/HyG8dDjAIcjEo8vBtq6kKEWBPL iitzDzFKc7AoifMuPDcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjwDbve22W51RWZmql G5w91bpLlndR8HuvLN4kgSwmBcOJClp6r6qq7/Js3Jqk5/RL72XDj9evz/y4v05y4w/fkwlr 68/Xu/uwnVryqnNaxZv/psdz48/499y4o7TJOvC03ReWmI+JXwwWL4vkv6pqej7/pHL9tZeV 3rtNJ1598VjNIoRjy8kTSizFGYmGWsxFxYkA12cXdYACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wE8jhRQfLzmgR22yybST__pR7uE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 12:09:51 -0000 Hi, There are a number of issues we need to solve, so I'll try to separate them= . First, we need to agree on whether support of rekeying and renegotiation is= mandatory, optional or not supported in general. Second, we need to agree on how/if an updated offer affects an existing DTL= S connection. - If the transport parameters have changed, a new DTLS connection is obviou= sly needed. But, then, how are the roles determined? Using the SDP setup at= tribute, as in the initial offer? OR, do we use the roles determined in the= initial offer? - If the transport parameters have NOT changed, would an updated offer affe= ct an existing DTLS connection? Could the roles be changed (based on the SD= P setup attribute)? Regards, Christer -----Original Message----- From: Stefan H=E5kansson LK=20 Sent: 3. joulukuuta 2014 13:02 To: Roman Shpount; Christer Holmberg Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Unsolicited DTLS Handshake On 02/12/14 14:46, Roman Shpount wrote: > On Tue, Dec 2, 2014 at 8:06 AM, Christer Holmberg=20 > > > wrote: > > > Chrome on the other hand has renegotiation enabled but does not hav= e the code to detect it and to re-export SRTP keys. My question is, should = disabling renegotiation > > be codified somewhere (like JSEP) or is this something that is goin= g to be implemented? If renegotiation is somehow an optional feature, how d= oes one know that remote party supports it? > > Well, we have mechanisms to indicate support of something. In SDP we > can define an attribute, in SIP we can define a media feature > tag/option tag. I assume there are ways on the DTLS level to > indicate support also? > > > I do not think this was ever consider an optional feature and because=20 > of this there is no option to negotiate it. > > > Finally, JSEP should define what can be changed on the DTLS connect= ion. I think it was already agreed on the list that the setup roles should = be preserved (btw is this a SHOULD or a MUST?). What about the fingerprint?= Is it legal to change it without changing transport parameters? > > Again, I don't think this belong to JSEP. It is a generic SDP > Offer/Answer issue. > > Supposedly, JSEP will already define that DTLS setup role cannot be=20 > changed. Why is fingerprint any different? > > I think DTLS and DTLS-SRTP end-points must supports rekey and=20 > renegotiation. I do not think DTLS or DTLS-SRTP is broken or unclear=20 > (of cause, this can always be improved). It looks like the mandatory=20 > DTLS capability is missing from the current browser implementations.=20 > So, either the rtcweb browsers should implement this or specification=20 > should be created to explain how browsers will work without it. I agree, we really need to decide on this (and other stuff) to enable indep= endent implementations to interoperate. Is there any reason for not implementing according to DTLS/DTLS-SRTP specs?= If not, I think that is what we should mandate. > If the > second path is chosen, then this discussion should probably move to=20 > other groups, such as MMUSIC. The less attractive option is to argue=20 > that this is a rtcweb specific DTLS profile and keep it=20 > non-inter-operable with regular DTLS/DTLS-SRTP. > _____________ > Roman Shpount > From nobody Wed Dec 3 06:43:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E0C1A00E2 for ; Wed, 3 Dec 2014 06:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3AM-Cvbx7OT for ; Wed, 3 Dec 2014 06:43:11 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266AE1A1B38 for ; Wed, 3 Dec 2014 06:43:11 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id a1so19960886wgh.11 for ; Wed, 03 Dec 2014 06:43:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Y1F8fFljwwybGHdjBx8O41bdyAW8jYvyIBztHPC8tK0=; b=F7L95mqjDbekqkk1Q0uXVbPNBKaLBiJ+Mi51UO/rmSXasNEF3u37Fx+cDYhyhh7lI7 RFoxqxBnE0EsPEG+gpDEP6fN1Nel5qzB5PdMPujsfBJBFoqPj09zQNYqj8TwdkmCfIjw Wq8V9PfH+jM1Qt95375zS5sr7iS25399rlxoKUIqe+WoyXjDs+mnfWSuBV8JVGVSp94N Fo1O7tM1xrR1qxIDYP5vr8hPzU+a6omtvUVJbXGjH2xaZBe/+A5/AJfOOWZH32cJhZ4X OEsARpEOw107UUpxewt/4lCxVxs7pr9rQ2YM3MSZpAWpKTySQLzl67By+ztqPug4ioip Tseg== X-Gm-Message-State: ALoCoQksJChaP52p2R6ESN1jv9MFJQ2bnXReXe0fnvSeXaLX3PvybuJWUAzeGaeY8XVgMuFW1j0C X-Received: by 10.180.107.193 with SMTP id he1mr99537221wib.27.1417617789776; Wed, 03 Dec 2014 06:43:09 -0800 (PST) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com. [74.125.82.47]) by mx.google.com with ESMTPSA id t6sm25398250wjf.49.2014.12.03.06.43.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 06:43:08 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so20188117wgh.20 for ; Wed, 03 Dec 2014 06:43:08 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.76.7 with SMTP id g7mr14278736wiw.38.1417617788389; Wed, 03 Dec 2014 06:43:08 -0800 (PST) Received: by 10.216.70.16 with HTTP; Wed, 3 Dec 2014 06:43:08 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D573154@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D56EA42@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EDF50@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D573154@ESESSMB209.ericsson.se> Date: Wed, 3 Dec 2014 09:43:08 -0500 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=f46d043893c7b4522e050950dc8e Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RBTmgrtTukYRkDKpCMC6f_HaV6M Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 14:43:16 -0000 --f46d043893c7b4522e050950dc8e Content-Type: text/plain; charset=UTF-8 On Wed, Dec 3, 2014 at 7:09 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > There are a number of issues we need to solve, so I'll try to separate > them. > > First, we need to agree on whether support of rekeying and renegotiation > is mandatory, optional or not supported in general. > > Second, we need to agree on how/if an updated offer affects an existing > DTLS connection. > > - If the transport parameters have changed, a new DTLS connection is > obviously needed. But, then, how are the roles determined? Using the SDP > setup attribute, as in the initial offer? OR, do we use the roles > determined in the initial offer? > > - If the transport parameters have NOT changed, would an updated offer > affect an existing DTLS connection? Could the roles be changed (based on > the SDP setup attribute)? > > There is actually one more point to the second issue: If the transport parameter have NOT changed, can the fingerprint be changed? Does this cause the new DTLS connection to be created and if it does, how do you de-mux packets for the old and new connection (both DTLS data and SRTP)? _____________ Roman Shpount --f46d043893c7b4522e050950dc8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Dec 3, 2014 at 7:09 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
=
There are a number of iss= ues we need to solve, so I'll try to separate them.

First, we need to agree on whether support of rekeying and renegotiation is= mandatory, optional or not supported in general.

Second, we need to agree on how/if an updated offer affects an existing DTL= S connection.

- If the transport parameters have changed, a new DTLS connection is obviou= sly needed. But, then, how are the roles determined? Using the SDP setup at= tribute, as in the initial offer? OR, do we use the roles determined in the= initial offer?

- If the transport parameters have NOT changed, would an updated offer affe= ct an existing DTLS connection? Could the roles be changed (based on the SD= P setup attribute)?


There is actually one more point to th= e second issue: If the transport parameter have NOT changed, can the finger= print be changed? Does this cause the new DTLS connection to be created and= if it does, how do you de-mux packets for the old and new connection (both= DTLS data and SRTP)?
____________= _
Roman Shpount

=C2=A0
--f46d043893c7b4522e050950dc8e-- From nobody Wed Dec 3 06:59:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA371A1B38 for ; Wed, 3 Dec 2014 06:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MScEFhtOzLWs for ; Wed, 3 Dec 2014 06:59:15 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5D11A1B47 for ; Wed, 3 Dec 2014 06:59:14 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id i17so11221172qcy.18 for ; Wed, 03 Dec 2014 06:59:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=gefBAwx/Ec9WZ2Qnz0T9e2vtKSbmQuXL+ZpFSLs3MaM=; b=aUZeqWP1CRDJ9blvL4UXYTXHLtaaERopwEpqJ58nLfhU3txq0IPyaKTvP8/gZ9yrJe mIDIkoHTevUS42786tOWtSchAsDRgzL6x81CTbleunbGkPwYvTMKjMkS8GgqYD+e45zd wIRF94JxcpYctNRlYCY60mquogoBw7iJzvyE9C4wsJTz1+Zrt8V/IaQcuBlimgjnebMD vJ7NNh5MvUbKPPjTUoBXwyt4R6ZQV4CQazMjtKve6A43go5Aa2lx6CrD3I50KGyKvU0c eykt/J3woI9j4nUsihRTdLkCGQuk3AlUsBV5tUjcPo+eTE/ZPQfUMdkoZCVCUe48WzCx HB4w== X-Gm-Message-State: ALoCoQmV6Bni3nDQ7AkzCACYEZtusvwy2sHCMYY2GR9cq+tGRhjQeLtjVV1g7yIq5w3IESJk+yiB X-Received: by 10.140.43.133 with SMTP id e5mr8734189qga.10.1417618753429; Wed, 03 Dec 2014 06:59:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Wed, 3 Dec 2014 06:58:53 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D573154@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D56EA42@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EDF50@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D573154@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 3 Dec 2014 15:58:53 +0100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kdmrnrV1tqpirwe4MQKqmeQCRgM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 14:59:20 -0000 2014-12-03 13:09 GMT+01:00 Christer Holmberg : > First, we need to agree on whether support of rekeying and renegotiation = is mandatory, optional or not supported in general. WebRTC uses DTLS. DTLS allows that, so it must be supported. This is, any WebRTC device/endpoint/thing should be able to perform a DTLS renegotiation (regardless who sent the first ClientHello), and that could involve SRTP re-keyring. This is 100% transparent so no need at all for SDP O/A stuff. > Second, we need to agree on how/if an updated offer affects an existing D= TLS connection. > > - If the transport parameters have changed, a new DTLS connection is obvi= ously needed. But, then, how are the roles determined? Using the SDP setup = attribute, as in the initial offer? OR, do we use the roles determined in t= he initial offer? Each SDP O/A party is supposed to mean an independent round-trip, so the same mechanism used for the original SDP O/A should be used. Said that: What would happen in a SDP O/A renegotiation if "transport parameters" do not change but the a=3Dsetup attribute does change? Well, the world end. We are trying to signal everything in SDP but at the same time we use protocols that are self-sufficient, so yes, we get unnecessary conflicts. --=20 I=C3=B1aki Baz Castillo From nobody Wed Dec 3 07:01:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AF21A1B3E for ; Wed, 3 Dec 2014 07:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_111=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W-UnalLZ45P for ; Wed, 3 Dec 2014 07:01:43 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C3B1A1B2F for ; Wed, 3 Dec 2014 07:01:43 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id m20so11086811qcx.17 for ; Wed, 03 Dec 2014 07:01:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=SAIb2smuq8tzApbtaI1Rtz+qiuy4vm8LDSIfTwNS3tM=; b=AGFd+4rYzexbMAOqHbNLjp5K5yR4KlQD97D65Aif3B1VmEWkzOuITe8DJEnIkFMAel 461DPck9RU8NyU3Zd39LSokpoSmK4LinJsWPAXkGADNiag63CZ9IOQAtHtsGdj/Z78Ci ciM6y7AOc880XXauRnu6Cwy1w2fI6GVnfdfsWRusJ4EdcAEwNFgwd+L3wclIcv8o7dse cetA6VeXnklr5+XoBJOximLA7ihaufUXMduhBs4KjDWyOn/aJZb2fbpLcp/Xx8gmLRBe yr+h+D1T8HiaFGZ+NPps0SQ2QWYT2Xn63iRDXUrVykZR69vQrs2Ks0OrJ+xUB9dNVHvt 5EaA== X-Gm-Message-State: ALoCoQmFmwGGlSCIAUEgIkGiOyAyy/GmKcfNxLkOubEYGq1Grlo2nzpcUiVKdc9CLAxUUu2OsB5L X-Received: by 10.140.105.164 with SMTP id c33mr8249707qgf.11.1417618902307; Wed, 03 Dec 2014 07:01:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Wed, 3 Dec 2014 07:01:22 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D56EA42@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EDF50@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D573154@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 3 Dec 2014 16:01:22 +0100 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/O_atzm3T_M9eoEkRsaDuvvybBQ0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 15:01:45 -0000 2014-12-03 15:43 GMT+01:00 Roman Shpount : > If the transport parameter have NOT changed, can the fingerprint be chang= ed? Correct me if I'm wrong, but during a DTLS/TLS session certificates are sent just once, at the beginning. Changing the a=3Dfingerprint attribute in a new SDP O/A round-trip without forcing a new DTLS session should just be considered an error. Again: we are trying to signal too much in the SDP. --=20 I=C3=B1aki Baz Castillo From nobody Wed Dec 3 07:30:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09381A1B63 for ; Wed, 3 Dec 2014 07:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rKurLiboHjR for ; Wed, 3 Dec 2014 07:30:30 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657501A1A4E for ; Wed, 3 Dec 2014 07:30:30 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id l18so20390820wgh.2 for ; Wed, 03 Dec 2014 07:30:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bsoGS/sn3PsOzFVViS8VrvGz+QY8KLE/zZfJN61zG84=; b=f6SIXeirW25Wd2+evELay1qvivNQ24h5vrA+uA5j2J47HtFEcY0vmQoZ68s3eYlPGm /mSs4bEqDcmTzAeUZ7xRDHUxeQvSiDxOgFxMb4596SKymEvGLZm8oFL+ljo1oUn2C8N2 ncOo3mK6h8EpL1dQk8ioTBhdVk26MirhZIcCR0SWIRDuqyqdXRezmt+BUZa3LOHzHXoV 28iXimbaOWn+i01ANwrwRmXzVarFvJ9OvE7xrzY1b5vBmLG8GKcDVgs2obl/9HRQ/cXj hPFrAcruSkDdhps/rTGLF7fjAUBDGe8vfaRs8A71qH1BBcRS2HbPiFaEgQtovYIMDPBQ G3ZQ== X-Gm-Message-State: ALoCoQkiIc0vo3ITFxh4X9EcYZsc19Gjr5IB3tRsUJNBMlpXjBEmsfhrMQf4GOFc3bVgyU/oH6Wy X-Received: by 10.194.200.1 with SMTP id jo1mr8653548wjc.64.1417620629070; Wed, 03 Dec 2014 07:30:29 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com. [209.85.212.182]) by mx.google.com with ESMTPSA id w10sm36718468wje.10.2014.12.03.07.30.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 07:30:28 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id h11so24802721wiw.15 for ; Wed, 03 Dec 2014 07:30:28 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.92.116 with SMTP id cl20mr8351303wjb.71.1417620628020; Wed, 03 Dec 2014 07:30:28 -0800 (PST) Received: by 10.216.70.16 with HTTP; Wed, 3 Dec 2014 07:30:27 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D56EA42@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EDF50@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D573154@ESESSMB209.ericsson.se> Date: Wed, 3 Dec 2014 10:30:27 -0500 Message-ID: From: Roman Shpount To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7bd910c2f5a47f05095185dd Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jT1J5fDNB_Tsv2M_h5wV-KdGnLs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 15:30:31 -0000 --047d7bd910c2f5a47f05095185dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 3, 2014 at 10:01 AM, I=C3=B1aki Baz Castillo wr= ote: > 2014-12-03 15:43 GMT+01:00 Roman Shpount : > > If the transport parameter have NOT changed, can the fingerprint be > changed? > > > Correct me if I'm wrong, but during a DTLS/TLS session certificates > are sent just once, at the beginning. Changing the a=3Dfingerprint > attribute in a new SDP O/A round-trip without forcing a new DTLS > session should just be considered an error. > > Again: we are trying to signal too much in the SDP. > > This is not exactly the SDP issue. This is an issue of being able to stop DTLS session and start a new one on the same transport connection while being able to de-mux packets for both sessions. It is a valid operation for DTLS-SRTP, but it does complicate the implementation. I am sure there are some media proxy scenarios where fingerprint and setup role changes would be required, but this is definitely not required for normal webrtc use cases. I do not think it would be a great loss if changing fingerprint and setup role would not be allowed, but that would need to be defined somewhere. For instance JSEP can specify the offers or answers which change setup role or fingerprint should be treated as malformed or that these updates must be ignored. Re-key, on the other hand, must be supported, since support for it cannot be negotiated and it does provide valuable functionality. _____________ Roman Shpount --047d7bd910c2f5a47f05095185dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Dec 3, 2014 at 10:01 AM, I=C3=B1aki Baz Castillo <= ibc@aliax.net> wrote:
2014-12-03 15:43 GMT+01:00= Roman Shpount <roman@telurix.com>:
> If the transport parameter have NOT changed, can the fingerprint be ch= anged?


Correct me if I'm wrong, but during a DTLS/TLS session certifica= tes
are sent just once, at the beginning. Changing the a=3Dfingerprint
attribute in a new SDP O/A round-trip without forcing a new DTLS
session should just be considered an error.

Again: we are trying to signal too much in the SDP.


This is not exactly the SDP issue. This is an issue of being able t= o stop DTLS session and start a new one on the same transport connection wh= ile being able to de-mux packets for both sessions. It is a valid operation= for DTLS-SRTP, but it does complicate the implementation. I am sure there = are some media proxy scenarios where fingerprint and setup role changes wou= ld be required, but this is definitely not required for normal webrtc use c= ases. I do not think it would be a great loss if changing fingerprint and s= etup role would not be allowed, but that would need to be defined somewhere= . For instance JSEP can specify the offers or answers which change setup ro= le or fingerprint should be treated as malformed or that these updates must= be ignored.

Re-key, on the other hand, must be su= pported, since support for it cannot be negotiated and it does provide valu= able functionality.
_____________<= br>Roman Shpount
=C2=A0
--047d7bd910c2f5a47f05095185dd-- From nobody Wed Dec 3 07:49:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517871A1B38 for ; Wed, 3 Dec 2014 07:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPye9cfo053t for ; Wed, 3 Dec 2014 07:48:53 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA20D1A1B9B for ; Wed, 3 Dec 2014 07:48:47 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-41-547f30dd9f34 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CC.B0.04231.DD03F745; Wed, 3 Dec 2014 16:48:45 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 16:48:45 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Justin Uberti Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JA== Date: Wed, 3 Dec 2014 15:48:45 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D0EE2BC@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+Jvje5dg/oQg40PrSy2ThWyaNh4hdVi xoWpzBZr/7WzO7B4tD7by+qxYFOpx5IlP5k8bk0pCGCJ4rJJSc3JLEst0rdL4Mp4seYBe8Ey w4rtHx4xNTCuVeli5OSQEDCRuPSonxHCFpO4cG89WxcjF4eQwBFGiQ/z/rFCOIsZJb6d+8wO UsUmECixdd8CNhBbREBN4uGsXWBFzAJHGSXOL94AViQsYCox6eIyJogiM4mFJycwQth6Eje/ XGABsVkEVCRmdi4Fi/MK+Eo8OPEYavVETok1u26CNTMC3fT91Bowm1lAXOLWk/lMELcKSCzZ c54ZwhaVePkY5FQOIFtRYnm/HES5nsSNqVPYIGxtiWULXzND7BKUODnzCcsERtFZSKbOQtIy C0nLLCQtCxhZVjGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIERtPBLb91dzCufu14iFGAg1GJ h3dDTV2IEGtiWXFl7iFGaQ4WJXHeRefmBQsJpCeWpGanphakFsUXleakFh9iZOLglGpgnLbu vKDkHJuQJWaycqsVCk223lQ2fHQqbn2WvuoLsxVP1adbJLnnFgiIP81YuPHhiaa4Q+nHPuQI h1/ki9vNU7+DQ2NlCf+UkBgOg0Un3gZOvCht+mNyQYiRi7eQXt288qLauMeCuzU9/bOko9ca GZR+n7Rrb6vs/K6pn2pqq1O9vFiN2GYrsRRnJBpqMRcVJwIAX1FESIcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nCnFWWCptJwS3VgiLeWHRZ8Cixc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 15:48:59 -0000 On 01/12/14 18:26, Justin Uberti wrote:=0A= >=0A= >=0A= > On Sun, Nov 30, 2014 at 7:26 AM, Stefan H=E5kansson LK=0A= > > wrote:=0A= >=0A= > On 30/11/14 16:06, Makaraju, Maridi Raju (Raju) wrote:=0A= > >> On 30/11/14 14:51, Makaraju, Maridi Raju (Raju) wrote:=0A= > >>>> Hi,=0A= > >>>>=0A= > >>>>>> RFC 7345 (UDPTL-DTLS) says the following:=0A= > >>>>>>=0A= > >>>>>> "Once an offer/answer exchange has been completed, either=0A= > >>>>>> endpoint=0A= > >>>> MAY=0A= > >>>>>> send a new offer in order to modify the session. The=0A= > >>>>>> endpoints=0A= > >>>> can=0A= > >>>>>> reuse the existing DTLS association if the key fingerprint=0A= > >>>>>> values=0A= > >>>> and=0A= > >>>>>> transport parameters indicated by each endpoint are unchanged= .=0A= > >>>>>> Otherwise, following the rules for the initial offer/answer= =0A= > >>>> exchange,=0A= > >>>>>> the endpoints can negotiate and create a new DTLS association= =0A= > >>>>>> and, once created, delete the previous DTLS association,=0A= > >>>>>> following the same rules for the initial offer/answer exchang= e.=0A= > >>>>>> Each endpoint needs to be prepared to receive data on both th= e=0A= > >>>>>> new and old DTLS associations as long as both are alive."=0A= > >>>>>>=0A= > >>>>>> So, I guess that can be read in a way that the setup attribut= e=0A= > >>>>>> as such=0A= > >>>> does not impact previously=0A= > >>>>>> negotiated TLS roles - unless the key fingerprint values and/= or=0A= > >>>>>> transport=0A= > >>>> parameters are modified.=0A= > >>>>>>=0A= > >>>>>> The SCTP-SDP draft currently says that a subsequent offer mus= t=0A= > >>>>>> not change=0A= > >>>> the previously negotiated roles. But, I guess=0A= > >>>>>> we could say something similar as in RFC 7345.=0A= > >>>>>=0A= > >>>>> I have struggled with this language quite a bit from the=0A= > >>>>> implementation=0A= > >>>> perspective. I think we need to explicitly state=0A= > >>>>> that endpoints MUST reuse the existing association if the key= =0A= > >>>>> fingerprint=0A= > >>>> values and transport parameters indicated=0A= > >>>>> by each endpoint are unchanged.=0A= > >>>>=0A= > >>>> We could take such general approach.=0A= > >>>>=0A= > >>>> However, for 'SCTP/DTLS' (DTLS over SCTP), I assume that the DT= LS=0A= > >>>> connection will also be re-established if the underlying SCTP= =0A= > >>>> association is re- established - even if no transport parameter= s=0A= > >>>> etc are changed.=0A= > >>>>=0A= > >>>> Also, RFC 6083 says:=0A= > >>>>=0A= > >>>> "Each DTLS connection MUST be established and terminated=0A= > within the=0A= > >>>> same SCTP association."=0A= > >>>>=0A= > >>>>=0A= > >>>>> The way this language reads to me is that endpoints can reuse = the=0A= > >>>>> existing=0A= > >>>> association if they want to, but they can create a new one if t= hey=0A= > >>>> don't. Also, when this new=0A= > >>>>> association is created, it is unclear if old setup roles MUST = be=0A= > >>>>> preserved=0A= > >>>> or if they MUST be selected based on the current offer/answer= =0A= > >>>> exchange. It seems the current=0A= > >>>>> specification language is not strong or clear enough on this= =0A= > >>>>> topic.=0A= > >>>>=0A= > >>>> In my opinion, IF a new DTLS connection needs to be established= =0A= > >>>> (for whatever reasons), the current roles should be used.=0A= > >>>=0A= > >>> When ICE is NOT used, how does the offerer know that the= =0A= > >>> answerer does not change the fingerprint and/or transport=0A= > parameters?=0A= > >>> I guess it does not know. So, offerer has to be prepared for=0A= > new DTLS=0A= > >>> association by offering actpass. When ICE is used, the answerer= =0A= > can't=0A= > >>> change transport parameter unless offerer does ICE restart (whic= h=0A= > >>> changes offerer transport parameters); Ref [1] is very clear on= =0A= > this=0A= > >>> indicating "DTLS handshake procedure is repeated". However,=0A= > even when=0A= > >>> ICE is used, I do not find any restriction about answerer not=0A= > >>> changing fingerprint. So, even without ICE restart answerer can= =0A= > >>> trigger a DTLS renegotiation by changing its fingerprint.=0A= > >>>=0A= > >>> To conclude all this, IMO whether ICE is used or not, sending=0A= > actpass=0A= > >>> for all new offers may be cover all possible scenarios.=0A= > >>=0A= > >> That is also my conclusion based on the discussion so far.=0A= > >>=0A= > >> I also think the JSEP draft as far as detailed out is correct,=0A= > but info=0A= > >> about how the implementation should behave for Subsequent answers= is=0A= > >> missing. Text saying that the role must be maintained (unless=0A= > there is=0A= > >> an ICE restart) should be put in there.=0A= > >=0A= > > =0A= > > Hi Stefan,=0A= > > Looks like, there is some misunderstanding here.=0A= >=0A= > Probably my fault in that case :)=0A= >=0A= > > My conclusion is to include=0A= > > actpass, but not the previously negotiated role, in all subsequent = offers,=0A= > > not just during ICE-restarts.=0A= >=0A= > I think that is what the JSEP draft says - and my conclusion is that = it=0A= > _is_ correct.=0A= >=0A= > My point was that the _answer_ should (when it is a subsequent answer= )=0A= > should say the same role as in previous answers (unless there is an I= CE=0A= > restart).=0A= >=0A= > I agree the JSEP text should indicate that roles should stay the same.=0A= > We have had this as a TODO for a while:=0A= > https://github.com/rtcweb-wg/jsep/issues/72=0A= =0A= Great. I should have checked that out before.=0A= =0A= From nobody Wed Dec 3 10:32:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC011A8F40 for ; Wed, 3 Dec 2014 10:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.91 X-Spam-Level: X-Spam-Status: No, score=0.91 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyAgnwoEwLp3 for ; Wed, 3 Dec 2014 10:32:39 -0800 (PST) Received: from hs8.name.com (hs8.name.com [173.193.131.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804851A8F4A for ; Wed, 3 Dec 2014 10:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ranjitvoip.com; s=default; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=yEZLcfVgQfCOXJmTK9UAxfbn3Vfkv9W7DonRjb0BIRw=; b=mMIFXPz6MTJFt2jypeDZ/+s47AnDYwTCB8uBeKXI4mk56m60t1XakglOaFQelfYmI7g11dmpF1tYeH+FkZF8XIjdhwpNjhp8IawnJRp6EFV5wT/5l1Js/Sy3jbXxvtii3wSYRdCKsM5cqOGZ12bhb496o054J0wkTtjBXejdSQM=; Received: from localhost.localdomain ([127.0.0.1]:35757 helo=webmail.ranjitvoip.com) by hs8.name.com with esmtpa (Exim 4.84) (envelope-from ) id 1XwEiV-004KqV-QI for rtcweb@ietf.org; Wed, 03 Dec 2014 12:31:59 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 03 Dec 2014 12:31:59 -0600 From: ranjit@ranjitvoip.com To: rtcweb@ietf.org Message-ID: <6bef1cce67d1c9da7c29d8e0804f2551@ranjitvoip.com> X-Sender: ranjit@ranjitvoip.com User-Agent: Roundcube Webmail/1.0.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hs8.name.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ranjitvoip.com X-Get-Message-Sender-Via: hs8.name.com: authenticated_id: ranjit@ranjitvoip.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lbI1SrIMokfIFDHRxYYlSVFvfQM Subject: [rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 18:32:40 -0000 Hi With websockets as a de-facto transport protocol for WebRTC signaling and JSEP being the format of encoding information, there is a need for a defining a websocket sub-protocol : jsep. So I would like to know if there is any interest in the community and also the views from experts about the need for a websocket-sub protocol for JSEP. The main purpose of defining the sub protocol (jsep) is to make sure that the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving JSEP encoded messages. Thanks Ranjit From nobody Wed Dec 3 10:33:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8F91A8BC4 for ; Wed, 3 Dec 2014 10:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LMqaLMDjOBl for ; Wed, 3 Dec 2014 10:33:38 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853371A8F40 for ; Wed, 3 Dec 2014 10:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417631586; x=2281545186; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9+7wSe7f40sX6rl3Zm0bl/2ZJ6l8k8NhdXvhSKsN3XA=; b=THzL+anof/n4XfQ9pibTB6q0KbaJu27d3VgL3PGjAVbQlMt5Caa9VSbsA7Vxwe2W /L3Lursy7VmEZtM1lKkjb7gBjyTIRmYxFpMMNANJ9/g7n6pV6KSDOFawj8Mu5vKC KhP49uIhnDXrjK6180Ylf6LiRefSETZRQ8yjTyFxhZEbf+rh7YSX/5C172PrSMsM AJYQ8mz8VwI9mqzH/1KTw5z4AsvO5quVG548MSVF/EeFOzvv4OuCsOftX9VIzSIQ XifDpNm0KCXdS6bC2npKfEPT8aAQefoI7j4osLvAhZemfAhk+HUnO+Q94LXeQP9y q5zb7FxDWl/u2dVnupYaEg==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 93.2B.02334.2675F745; Wed, 3 Dec 2014 10:33:06 -0800 (PST) X-AuditID: 11973e13-f79ee6d00000091e-08-547f57628dd7 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id BE.B4.05775.D475F745; Wed, 3 Dec 2014 10:32:45 -0800 (PST) Received: from [17.153.58.181] (unknown [17.153.58.181]) by aniseed.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG0004QORJ4UN40@aniseed.apple.com> for rtcweb@ietf.org; Wed, 03 Dec 2014 10:33:05 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: David Singer In-reply-to: <5476092D.4010406@nostrum.com> Date: Wed, 03 Dec 2014 10:33:04 -0800 Content-transfer-encoding: quoted-printable Message-id: <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1990.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FAYpZsUXh9icPATj8Xaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK+H3jGnvBV/6KK21N7A2MV3m6GDk5JARMJLb+P8UIYYtJXLi3 nq2LkYtDSGAvo8SftafZYYp6vt5lh0j0M0nsnPmBFcKZyCQx9+ld5i5GDg5mAXWJKVNyQRp4 BQwkbp2ZATZVWCBC4kjnGbBBbAKqEg/mHAOLcwpoS+xZuIQNxGYBiv+YPAXMZgaKP3l3gRVi jo3EmbbnYL1CAhkS5zdNYwaxRYBWXX54Aeo4eYk5F06AXS0h8JBV4uHsdUwTGIVmIZw0C8lJ s5CsWMDIvIpRKDcxM0c3M89UL7GgICdVLzk/dxMjKFyn2wnvYDy9yuoQowAHoxIP74PouhAh 1sSy4srcQ4zSHCxK4rz7FYFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGPNfq+wsfpos6ndx /+wWh4YzUo7b/J4xXHjmfHaGo+GZ8lkyeaVPzaebW/0Ku9K4YEHTqeeJQodeBJgv2LlW4UTK eoO7ZWp3FNUDk4S2bNOdszqRcW3B9hWLXfKnTQyz7zX9c6nLqJg9qGP+nXdyJ579v+xpOCVq 1pWuU/M28Nz/3Pt5E+Pj6nQlluKMREMt5qLiRAA5mIagOAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUi2FAsrusbXh9icGW2msXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK+H3jGnvBV/6KK21N7A2MV3m6GDk5JARMJHq+3mWHsMUkLtxb z9bFyMUhJNDPJLFz5gdWCGcik8Tcp3eZuxg5OJgF1CWmTMkFaeAVMJC4dWYGI4gtLBAhcaTz DNggNgFViQdzjoHFOQW0JfYsXMIGYrMAxX9MngJmMwPFn7y7wAoxx0biTNtzsF4hgQyJ85um MYPYIkCrLj+8AHWcvMScCyfYJjDyz0K4YhaSK2YhmbqAkXkVo0BRak5ipZleYkFBTqpecn7u JkZweBVG7WBsWG51iFGAg1GJh/dBdF2IEGtiWXFl7iFGCQ5mJRFeccf6ECHelMTKqtSi/Pii 0pzU4kOM0hwsSuK8ZSpA1QLpiSWp2ampBalFMFkmDk6pBsbYuKmf+RYv/SfdpHHQ+Pka1Xjd 7suimk+evJO/KqJ74144T0fO9jdvlEP5/9wu9EkJ5vxtymK94f+ir5dj3/D4+bjtvvJgReTC rnfh8menZrPM/nxBeUvbPvXrtseYP+UGzEmrmjHhx/I1PT8bOnTPtu762/3Z8cDf6OKC0pLA WLFNJTVOW24qsRRnJBpqMRcVJwIAs2ZcRSsCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WeqjX72nwPLwjBins-0sFCALqBQ Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 18:33:39 -0000 As I understand it, the recent face to face meeting decided to draft the = requirement that WebRTC browsers be required to implement both VP8 and = H.264, and get feedback on this, on the list. This is some feedback. I=E2=80=99d like to point out that this could easily place companies in = an impossible position. Consider: it is not uncommon for IPR owners to grant a license (often = free) only to =E2=80=98conforming implementations=E2=80=99. (A common = rationale is that they want to use their IPR to bring convergence and = interoperability to the industry). Let=E2=80=99s hypothesize that this = happens, now or in future, from Company X, for some IPR in the WebRTC = specifications. Consider also: we have an =E2=80=9Cunwilling to license=E2=80=9D = statement from Nokia on VP8, on the formal record (and including a long = list of patents). Consider finally: a small company for whom WebRTC is important. Let=E2=80=99s look at the choices: 1. Follow the mandate, implement VP8, and risk a ruinous lawsuit from = Nokia. 2. Reject the mandate, do not implement VP8, and be formally therefore = not conformant and therefore not in receipt of a license from company X; = risk a ruinous lawsuit from X. 3. Do not implement WebRTC, and risk a ruinous loss of relevance. I do not think that the IETF should be placing anyone into the position = of having three extremely unpalatable choices. (Yes, I am aware that #2 is =E2=80=98unlikely=E2=80=99, but one day = someone will decide that the =E2=80=9Conly to conformant = implementations=E2=80=9D clause needs to be real and enforced, and will = do this; our hypothetical small company might prefer not to be the = example case.) (I use a small company as the example, because for them the risk is = bankruptcy, but of course no-one likes to step into the path of trouble = even if they have the resources to weather it.) Dave Singer singer@mac.com David Singer Manager, Software Standards, Apple Inc. From nobody Wed Dec 3 10:36:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40981A6F9E for ; Wed, 3 Dec 2014 10:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g74Psl3ANtIZ for ; Wed, 3 Dec 2014 10:36:09 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5237C1A1AC3 for ; Wed, 3 Dec 2014 10:36:09 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wp18so11936412obc.15 for ; Wed, 03 Dec 2014 10:36:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JhMmAKSdMM9p5qtLTfxO4w6Qbm1CbpuQAksesFneGAI=; b=Xna53QtYTwfAkC/aYFLvwd1PkoPVwdRcQib0sqwkoVRn6Smt9gxQoyCJM9qIQ5rFpw JYD7x+kf5iq/I+c6cN4zaQE3gmf+SPgWMg8743NZXo0wG4fwMAna2CO8ordm4q98QVX6 HNdYMmmAtbTs7EfEM25MI6SczLmt6OscmNDXejiZF2fOfBrjo8hKeMlJdFBZc0YzWD1w +Yu/tZxkkLTvbS23q5WCtMs0pttG5cYlVyhrVHmyIA14v8SUDJ2aAe5bFVsHWFYZMWQV uyoweZfe6AqTPy2mH7z77Leg4tEEL4RmjzOaQAoxuViphp7TD/AJnEk7uFvKtrt/GDZR e4gw== MIME-Version: 1.0 X-Received: by 10.202.168.204 with SMTP id r195mr3962690oie.72.1417631768440; Wed, 03 Dec 2014 10:36:08 -0800 (PST) Received: by 10.202.115.4 with HTTP; Wed, 3 Dec 2014 10:36:08 -0800 (PST) In-Reply-To: <6bef1cce67d1c9da7c29d8e0804f2551@ranjitvoip.com> References: <6bef1cce67d1c9da7c29d8e0804f2551@ranjitvoip.com> Date: Wed, 3 Dec 2014 10:36:08 -0800 Message-ID: From: Martin Thomson To: ranjit@ranjitvoip.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rTsDOta8RSeHiD4VavuMnDHaxRI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 18:36:11 -0000 On 3 December 2014 at 10:31, wrote: > The main purpose of defining the sub protocol (jsep) is to make sure that > the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving JSEP > encoded messages. Who are you interoperating with? From nobody Wed Dec 3 10:38:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF13F1A1EEA for ; Wed, 3 Dec 2014 10:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbPKmep591m8 for ; Wed, 3 Dec 2014 10:37:59 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5CC1A1A57 for ; Wed, 3 Dec 2014 10:37:58 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id r20so32393240wiv.6 for ; Wed, 03 Dec 2014 10:37:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eKFVgVnfpUCppyLiEJSe3kZBmE2mcjSZ4KmEDavX0xA=; b=hXZJh+kC5wCRQrA0WStUJltXgLVBXNewaOmjmL9pSZxQLgKAyJRjLhv5LnD1yYZVJM hKeFpK06TJLZOcxSkGjCUUwj9rPnAmMSMtqgacteXC8f+DxY4qcrLsah6U83a8WB2vCh LsJPBh4G42xzsDx0Goo6zvqn/R/85Je12sN2FevnFrIRtJhyTBmmmoZNY5mZSsLuEq39 /aCuvbQMTtahuFYIhmw73BRMvuBbD/kZ7Iaoh+B0+ijl0JtW0KozMQ/YLrLoc4GZq0qu lUa+oTAuCZ0xPdHzWWzOFNBXbkKR2150V+Imvs7wl4hOHhZZQQy6ccGAquxFVHITB378 zo0g== X-Gm-Message-State: ALoCoQmi7QPnr45ZJ1bjWdT+klh12vXS5TponXBePCH8U4ZXMx3EmO2kq/idSaFwCPyUr6X75Ipb X-Received: by 10.180.90.206 with SMTP id by14mr15628516wib.67.1417631877650; Wed, 03 Dec 2014 10:37:57 -0800 (PST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com. [209.85.212.177]) by mx.google.com with ESMTPSA id o2sm855316wja.45.2014.12.03.10.37.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 10:37:57 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id l15so25444407wiw.10 for ; Wed, 03 Dec 2014 10:37:56 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.92.116 with SMTP id cl20mr9698136wjb.71.1417631876711; Wed, 03 Dec 2014 10:37:56 -0800 (PST) Received: by 10.216.70.16 with HTTP; Wed, 3 Dec 2014 10:37:56 -0800 (PST) In-Reply-To: <6bef1cce67d1c9da7c29d8e0804f2551@ranjitvoip.com> References: <6bef1cce67d1c9da7c29d8e0804f2551@ranjitvoip.com> Date: Wed, 3 Dec 2014 13:37:56 -0500 Message-ID: From: Roman Shpount To: ranjit@ranjitvoip.com Content-Type: multipart/alternative; boundary=047d7bd910c26f0c730509542418 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eRWD639dwnKgjEDtyKUtCOUEsI4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 18:38:04 -0000 --047d7bd910c26f0c730509542418 Content-Type: text/plain; charset=UTF-8 Is there any reason you cannot use SIP over WebSocket ( https://tools.ietf.org/html/rfc7118)? Call signaling will require a lot more information then what is provided in JSEP. JSEP mostly deals with offer and answer processing. Signaling will also need to deal with things like who is calling, why they are calling, transfers, other application specific details. In other words, I think this is a very bad idea. _____________ Roman Shpount On Wed, Dec 3, 2014 at 1:31 PM, wrote: > Hi > With websockets as a de-facto transport protocol for WebRTC signaling and > JSEP being the format of encoding information, there is a need for a > defining a websocket sub-protocol : jsep. So I would like to know if there > is any interest in the community and also the views from experts about the > need for a websocket-sub protocol for JSEP. > > The main purpose of defining the sub protocol (jsep) is to make sure that > the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving JSEP > encoded messages. > > Thanks > Ranjit > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bd910c26f0c730509542418 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there any reason you cannot use SIP over WebSocket (https://tools.ietf.org/html/rf= c7118)?

Call signaling will require a lot more infor= mation then what is provided in JSEP. JSEP mostly deals with offer and answ= er processing. Signaling will also need to deal with things like who is cal= ling, why they are calling, transfers, other application specific details. = In other words, I think this is a very bad idea.

_________= ____
Roman Shpount

On Wed, Dec 3, 2014 at 1:31 PM, <ran= jit@ranjitvoip.com> wrote:
= Hi
With websockets as a de-facto transport protocol for WebRTC signaling and J= SEP being the format of encoding information, there is a need for a definin= g a websocket sub-protocol : jsep. So I would like to know if there is any = interest in the community and also the views from experts about the need fo= r a websocket-sub protocol for JSEP.

The main purpose of defining the sub protocol (jsep) is to make sure that t= he WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving JSEP encode= d messages.

Thanks
Ranjit

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--047d7bd910c26f0c730509542418-- From nobody Wed Dec 3 10:40:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0ACC1A6F9A for ; Wed, 3 Dec 2014 10:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1TI0ml6kKs5 for ; Wed, 3 Dec 2014 10:40:14 -0800 (PST) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7244C1A1AC3 for ; Wed, 3 Dec 2014 10:40:14 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id r2so13269176igi.6 for ; Wed, 03 Dec 2014 10:40:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PrRSIIuzkhEn330UjgBPKpVX3b0OYonrNW3OvSaK/O8=; b=PAFKLH08saHe6ghIlkggVbWFsVCclcyn4IHqzZ1Cw3tPe4ZV0mSerGACqrd6q4Q4m2 q6ZW7RkxueZCMhT/hoPnYYs+c7Z2d2/EgL8StqRpQkXNxrw02HMs7LQlsUOw1Fa52Tx2 AnpmOI7z6lPJtqKG1u38VIzsSCJmIC6Oj+lsFO8+GANvwVBejDR0dY+UI9/j8x5tSBXq EYJADPjlTkZVjSzUh6ueShfo4PXmQXmXUbkcQmuW6nHEp6hnygH5CJlyaF2jcsznr+Tu 4CjRUYFuG5gA6yyKBD8tyDfdw3+uX94eJXoP8AaiJ4OrcDOjVSntj0fPFSw3GReTbS3j RUwQ== X-Gm-Message-State: ALoCoQlgs0enRD05ZDyXIsLmPQF24dm3SNjYT9oNJ/Bw4XYQtcWkSBOgRm1h8iHghwQrItbOxYGK X-Received: by 10.107.13.12 with SMTP id 12mr6155896ion.68.1417632013885; Wed, 03 Dec 2014 10:40:13 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id g70sm13105145ioe.18.2014.12.03.10.40.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 10:40:13 -0800 (PST) Message-ID: <547F590C.7010608@andyet.net> Date: Wed, 03 Dec 2014 11:40:12 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Roman Shpount , ranjit@ranjitvoip.com References: <6bef1cce67d1c9da7c29d8e0804f2551@ranjitvoip.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/aBGB4KqWixWSGb7Vs1linouOF7s Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 18:40:16 -0000 On 12/3/14, 11:37 AM, Roman Shpount wrote: > Is there any reason you cannot use SIP over WebSocket > (https://tools.ietf.org/html/rfc7118)? Or XMPP over WebSocket for that matter: https://tools.ietf.org/html/rfc7395 > Call signaling will require a lot more information then what is provided > in JSEP. JSEP mostly deals with offer and answer processing. Signaling > will also need to deal with things like who is calling, why they are > calling, transfers, other application specific details. Indeed. > In other words, > I think this is a very bad idea. At the least, limited and irrelevant. :-) Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Dec 3 10:41:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421C31A904D for ; Wed, 3 Dec 2014 10:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AuJugduWnJn for ; Wed, 3 Dec 2014 10:41:02 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8DC1A6F66 for ; Wed, 3 Dec 2014 10:41:01 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id E1BC4FEC53993; Wed, 3 Dec 2014 18:40:55 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id sB3Ieuh6023358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Dec 2014 13:40:57 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 13:40:56 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Roman Shpount , "ranjit@ranjitvoip.com" Thread-Topic: [rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets Thread-Index: AQHQDyisWxxS9lJ1KUyV9s38pGWFQQ== Date: Wed, 3 Dec 2014 18:40:56 +0000 Message-ID: References: <6bef1cce67d1c9da7c29d8e0804f2551@ranjitvoip.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E64BCABUS70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QsFGvNmk2raqoUCT5NyyOu_7hsU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 18:41:04 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E64BCABUS70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KyAxIGZvciB1c2luZyBTSVAgb3ZlciBXZWJTb2NrZXQuDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRv OnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9tYW4gU2hwb3VudA0KU2Vu dDogV2VkbmVzZGF5LCBEZWNlbWJlciAwMywgMjAxNCAxMjozOCBQTQ0KVG86IHJhbmppdEByYW5q aXR2b2lwLmNvbQ0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIElu dGVyZXN0IGFuZCBuZWVkIGZvciBXZWJzb2NrZXQgc3VicHJvdG9jb2wgLSBKU0VQIG92ZXIgd2Vi c29ja2V0cw0KDQpJcyB0aGVyZSBhbnkgcmVhc29uIHlvdSBjYW5ub3QgdXNlIFNJUCBvdmVyIFdl YlNvY2tldCAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcxMTgpPw0KDQpDYWxsIHNp Z25hbGluZyB3aWxsIHJlcXVpcmUgYSBsb3QgbW9yZSBpbmZvcm1hdGlvbiB0aGVuIHdoYXQgaXMg cHJvdmlkZWQgaW4gSlNFUC4gSlNFUCBtb3N0bHkgZGVhbHMgd2l0aCBvZmZlciBhbmQgYW5zd2Vy IHByb2Nlc3NpbmcuIFNpZ25hbGluZyB3aWxsIGFsc28gbmVlZCB0byBkZWFsIHdpdGggdGhpbmdz IGxpa2Ugd2hvIGlzIGNhbGxpbmcsIHdoeSB0aGV5IGFyZSBjYWxsaW5nLCB0cmFuc2ZlcnMsIG90 aGVyIGFwcGxpY2F0aW9uIHNwZWNpZmljIGRldGFpbHMuIEluIG90aGVyIHdvcmRzLCBJIHRoaW5r IHRoaXMgaXMgYSB2ZXJ5IGJhZCBpZGVhLg0KDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50 DQoNCk9uIFdlZCwgRGVjIDMsIDIwMTQgYXQgMTozMSBQTSwgPHJhbmppdEByYW5qaXR2b2lwLmNv bTxtYWlsdG86cmFuaml0QHJhbmppdHZvaXAuY29tPj4gd3JvdGU6DQpIaQ0KV2l0aCB3ZWJzb2Nr ZXRzIGFzIGEgZGUtZmFjdG8gdHJhbnNwb3J0IHByb3RvY29sIGZvciBXZWJSVEMgc2lnbmFsaW5n IGFuZCBKU0VQIGJlaW5nIHRoZSBmb3JtYXQgb2YgZW5jb2RpbmcgaW5mb3JtYXRpb24sIHRoZXJl IGlzIGEgbmVlZCBmb3IgYSBkZWZpbmluZyBhIHdlYnNvY2tldCBzdWItcHJvdG9jb2wgOiBqc2Vw LiBTbyBJIHdvdWxkIGxpa2UgdG8ga25vdyBpZiB0aGVyZSBpcyBhbnkgaW50ZXJlc3QgaW4gdGhl IGNvbW11bml0eSBhbmQgYWxzbyB0aGUgdmlld3MgZnJvbSBleHBlcnRzIGFib3V0IHRoZSBuZWVk IGZvciBhIHdlYnNvY2tldC1zdWIgcHJvdG9jb2wgZm9yIEpTRVAuDQoNClRoZSBtYWluIHB1cnBv c2Ugb2YgZGVmaW5pbmcgdGhlIHN1YiBwcm90b2NvbCAoanNlcCkgaXMgdG8gbWFrZSBzdXJlIHRo YXQgdGhlIFdlYlJUQyBjbGllbnQgKFdJQykgYW5kIFdlYlJUQyBzZXJ2ZXIgKEUtQ1NDRikgYXJl IHJlY2VpdmluZyBKU0VQIGVuY29kZWQgbWVzc2FnZXMuDQoNClRoYW5rcw0KUmFuaml0DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFp bGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== --_000_E1FE4C082A89A246A11D7F32A95A17828E64BCABUS70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mIzQzOyAxIGZvciB1c2luZyBTSVAgb3ZlciBXZWJTb2Nr ZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYiBb bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb21h biBTaHBvdW50PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRGVjZW1iZXIgMDMsIDIwMTQg MTI6MzggUE08YnI+DQo8Yj5Ubzo8L2I+IHJhbmppdEByYW5qaXR2b2lwLmNvbTxicj4NCjxiPkNj OjwvYj4gcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBJ bnRlcmVzdCBhbmQgbmVlZCBmb3IgV2Vic29ja2V0IHN1YnByb3RvY29sIC0gSlNFUCBvdmVyIHdl YnNvY2tldHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SXMgdGhlcmUgYW55IHJlYXNvbiB5b3UgY2Fubm90IHVzZSBTSVAgb3ZlciBXZWJTb2Nr ZXQgKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTE4Ij5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzExODwvYT4pPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2FsbCBzaWduYWxpbmcgd2lsbCByZXF1aXJlIGEgbG90 IG1vcmUgaW5mb3JtYXRpb24gdGhlbiB3aGF0IGlzIHByb3ZpZGVkIGluIEpTRVAuIEpTRVAgbW9z dGx5IGRlYWxzIHdpdGggb2ZmZXIgYW5kIGFuc3dlciBwcm9jZXNzaW5nLiBTaWduYWxpbmcgd2ls bCBhbHNvIG5lZWQgdG8gZGVhbCB3aXRoIHRoaW5ncyBsaWtlIHdobyBpcyBjYWxsaW5nLCB3aHkg dGhleSBhcmUgY2FsbGluZywgdHJhbnNmZXJzLCBvdGhlcg0KIGFwcGxpY2F0aW9uIHNwZWNpZmlj IGRldGFpbHMuIEluIG90aGVyIHdvcmRzLCBJIHRoaW5rIHRoaXMgaXMgYSB2ZXJ5IGJhZCBpZGVh LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIERlYyAzLCAy MDE0IGF0IDE6MzEgUE0sICZsdDs8YSBocmVmPSJtYWlsdG86cmFuaml0QHJhbmppdHZvaXAuY29t IiB0YXJnZXQ9Il9ibGFuayI+cmFuaml0QHJhbmppdHZvaXAuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaTxicj4NCldpdGggd2Vic29ja2V0 cyBhcyBhIGRlLWZhY3RvIHRyYW5zcG9ydCBwcm90b2NvbCBmb3IgV2ViUlRDIHNpZ25hbGluZyBh bmQgSlNFUCBiZWluZyB0aGUgZm9ybWF0IG9mIGVuY29kaW5nIGluZm9ybWF0aW9uLCB0aGVyZSBp cyBhIG5lZWQgZm9yIGEgZGVmaW5pbmcgYSB3ZWJzb2NrZXQgc3ViLXByb3RvY29sIDoganNlcC4g U28gSSB3b3VsZCBsaWtlIHRvIGtub3cgaWYgdGhlcmUgaXMgYW55IGludGVyZXN0IGluIHRoZSBj b21tdW5pdHkgYW5kIGFsc28NCiB0aGUgdmlld3MgZnJvbSBleHBlcnRzIGFib3V0IHRoZSBuZWVk IGZvciBhIHdlYnNvY2tldC1zdWIgcHJvdG9jb2wgZm9yIEpTRVAuPGJyPg0KPGJyPg0KVGhlIG1h aW4gcHVycG9zZSBvZiBkZWZpbmluZyB0aGUgc3ViIHByb3RvY29sIChqc2VwKSBpcyB0byBtYWtl IHN1cmUgdGhhdCB0aGUgV2ViUlRDIGNsaWVudCAoV0lDKSBhbmQgV2ViUlRDIHNlcnZlciAoRS1D U0NGKSBhcmUgcmVjZWl2aW5nIEpTRVAgZW5jb2RlZCBtZXNzYWdlcy48YnI+DQo8YnI+DQpUaGFu a3M8YnI+DQpSYW5qaXQ8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRj d2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_E1FE4C082A89A246A11D7F32A95A17828E64BCABUS70UWXCHMBA02z_-- From nobody Wed Dec 3 10:57:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD561A9091 for ; Wed, 3 Dec 2014 10:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2RwUA9A1NJG for ; Wed, 3 Dec 2014 10:57:37 -0800 (PST) Received: from hs8.name.com (hs8.name.com [173.193.131.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB481A90B9 for ; Wed, 3 Dec 2014 10:57:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ranjitvoip.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=NmFa/nXpoPiYLj2YhUNf67fZrCCGEolNiKs3sks+GAw=; b=KWGRlB7TXcZP/XRBpxCzt93PkHj95sTTrDN6+WLT3hhz3uUBs8bxgdIqCJ5YQtiCFu8zPkLxFAmAvR7Pjkf0stkTq0VXoy3NxcWfXOfxOOh/mhwdS2v6IUcLzNVIkxBveUCQVOSwSyUXlbcWjtOBw3KdXyaALN11bySxG9IGm0Y=; Received: from localhost.localdomain ([127.0.0.1]:38691 helo=webmail.ranjitvoip.com) by hs8.name.com with esmtpa (Exim 4.84) (envelope-from ) id 1XwF6x-0003Fo-Ex; Wed, 03 Dec 2014 12:57:15 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 03 Dec 2014 12:57:15 -0600 From: ranjit@ranjitvoip.com To: "Makaraju, Maridi Raju (Raju)" In-Reply-To: References: <6bef1cce67d1c9da7c29d8e0804f2551@ranjitvoip.com> Message-ID: <554d17d3779404eed3868ae587510e2f@ranjitvoip.com> X-Sender: ranjit@ranjitvoip.com User-Agent: Roundcube Webmail/1.0.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hs8.name.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ranjitvoip.com X-Get-Message-Sender-Via: hs8.name.com: authenticated_id: ranjit@ranjitvoip.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/V3082tZZXwjaa9v6WuvfBUh3wy4 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 18:57:38 -0000 Hello all While I agree SIP over Websockets is default signaling protocol for WebRTC while working with IMS, there could be scenarios where WebRTC calls can get initiated from non SIP UAs like web browsers which do not support SIP. Then in such cases, the following things could happen 1) the WebRTC client on the browser can use JSEP to send its signaling information over WebSocket, 2) the JSEP message would then land on the WebRTC GW over WS. 3) This JSEP message would then be converted to a SIP message and then sent to IMS core. 4) within IMS core, its a regular SIP message 5) Again in the reverse direction, WebRTC GW would convert SIP to JSEP 6) JSEP message is sent over Websocket to UE. now we see JSEP messages getting exchanged over Websockets. so if the websocket sub-protocol does not define the type as "jsep", then the WebRTC GW would not know the incoming message type and hence may discard it or its behavior may be uncertain. Also the JSEP message needs to be enhanced to add more message types (along with current OFFER / ANSWER) to be able to map it with standard signaling protocol like SIP as defined in https://tools.ietf.org/html/draft-partha-rtcweb-jsep-sip-01 Regards Ranjit On 2014-12-03 12:40 pm, Makaraju, Maridi Raju (Raju) wrote: > + 1 for using SIP over WebSocket. > > FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF Roman > Shpount > SENT: Wednesday, December 03, 2014 12:38 PM > TO: ranjit@ranjitvoip.com > CC: rtcweb@ietf.org > SUBJECT: Re: [rtcweb] Interest and need for Websocket subprotocol - > JSEP over websockets > > Is there any reason you cannot use SIP over WebSocket > (https://tools.ietf.org/html/rfc7118 [1])? > > Call signaling will require a lot more information then what is > provided in JSEP. JSEP mostly deals with offer and answer processing. > Signaling will also need to deal with things like who is calling, why > they are calling, transfers, other application specific details. In > other words, I think this is a very bad idea. > > _____________ > Roman Shpount > > On Wed, Dec 3, 2014 at 1:31 PM, wrote: > > Hi > With websockets as a de-facto transport protocol for WebRTC signaling > and JSEP being the format of encoding information, there is a need for > a defining a websocket sub-protocol : jsep. So I would like to know if > there is any interest in the community and also the views from experts > about the need for a websocket-sub protocol for JSEP. > > The main purpose of defining the sub protocol (jsep) is to make sure > that the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving > JSEP encoded messages. > > Thanks > Ranjit > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb [2] > > > > Links: > ------ > [1] https://tools.ietf.org/html/rfc7118 > [2] https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Dec 3 11:02:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417161A6F24 for ; Wed, 3 Dec 2014 11:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIkJ-_42nX3k for ; Wed, 3 Dec 2014 11:02:09 -0800 (PST) Received: from hs8.name.com (hs8.name.com [173.193.131.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C95F11A6F27 for ; Wed, 3 Dec 2014 11:02:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ranjitvoip.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=NmFa/nXpoPiYLj2YhUNf67fZrCCGEolNiKs3sks+GAw=; b=FMNGChNw0b/F3I83LPE5N9qVaZYr4jR76LFbWgDWaD0ABh3lKCCcfBHafb9g8uRUVaBzM3RD4xl/b61YLbYXEnHK7hMXXbstFaN9dil4sBLjR9afbU1sDD7JgbUDXf/qEhlX72m8K5MF7M76PpTlVRgfp/Y+SqAZQQ4OHHqdNkM=; Received: from localhost.localdomain ([127.0.0.1]:39239 helo=webmail.ranjitvoip.com) by hs8.name.com with esmtpa (Exim 4.84) (envelope-from ) id 1XwFBg-0004ly-54; Wed, 03 Dec 2014 13:02:08 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 03 Dec 2014 13:02:08 -0600 From: ranjit@ranjitvoip.com To: "Makaraju, Maridi Raju (Raju)" In-Reply-To: References: <6bef1cce67d1c9da7c29d8e0804f2551@ranjitvoip.com> Message-ID: X-Sender: ranjit@ranjitvoip.com User-Agent: Roundcube Webmail/1.0.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hs8.name.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ranjitvoip.com X-Get-Message-Sender-Via: hs8.name.com: authenticated_id: ranjit@ranjitvoip.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/I10ZU2UboyP6EJBWLbrdsBw3cFw Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 19:02:10 -0000 Hello all While I agree SIP over Websockets is default signaling protocol for WebRTC while working with IMS, there could be scenarios where WebRTC calls can get initiated from non SIP UAs like web browsers which do not support SIP. Then in such cases, the following things could happen 1) the WebRTC client on the browser can use JSEP to send its signaling information over WebSocket, 2) the JSEP message would then land on the WebRTC GW over WS. 3) This JSEP message would then be converted to a SIP message and then sent to IMS core. 4) within IMS core, its a regular SIP message 5) Again in the reverse direction, WebRTC GW would convert SIP to JSEP 6) JSEP message is sent over Websocket to UE. now we see JSEP messages getting exchanged over Websockets. so if the websocket sub-protocol does not define the type as "jsep", then the WebRTC GW would not know the incoming message type and hence may discard it or its behavior may be uncertain. Also the JSEP message needs to be enhanced to add more message types (along with current OFFER / ANSWER) to be able to map it with standard signaling protocol like SIP as defined in https://tools.ietf.org/html/draft-partha-rtcweb-jsep-sip-01 Regards Ranjit On 2014-12-03 12:40 pm, Makaraju, Maridi Raju (Raju) wrote: > + 1 for using SIP over WebSocket. > > FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF Roman > Shpount > SENT: Wednesday, December 03, 2014 12:38 PM > TO: ranjit@ranjitvoip.com > CC: rtcweb@ietf.org > SUBJECT: Re: [rtcweb] Interest and need for Websocket subprotocol - > JSEP over websockets > > Is there any reason you cannot use SIP over WebSocket > (https://tools.ietf.org/html/rfc7118 [1])? > > Call signaling will require a lot more information then what is > provided in JSEP. JSEP mostly deals with offer and answer processing. > Signaling will also need to deal with things like who is calling, why > they are calling, transfers, other application specific details. In > other words, I think this is a very bad idea. > > _____________ > Roman Shpount > > On Wed, Dec 3, 2014 at 1:31 PM, wrote: > > Hi > With websockets as a de-facto transport protocol for WebRTC signaling > and JSEP being the format of encoding information, there is a need for > a defining a websocket sub-protocol : jsep. So I would like to know if > there is any interest in the community and also the views from experts > about the need for a websocket-sub protocol for JSEP. > > The main purpose of defining the sub protocol (jsep) is to make sure > that the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving > JSEP encoded messages. > > Thanks > Ranjit > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb [2] > > > > Links: > ------ > [1] https://tools.ietf.org/html/rfc7118 > [2] https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Dec 3 11:08:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A711A8772 for ; Wed, 3 Dec 2014 11:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9Zvsc7Sckxu for ; Wed, 3 Dec 2014 11:07:56 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057CD1A90D1 for ; Wed, 3 Dec 2014 11:07:52 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex7so32424637wid.9 for ; Wed, 03 Dec 2014 11:07:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ijnaWJ0zGHPEEoS9ebtR9csNrsCqTXWaGUGWipswvXE=; b=gCEsrRN9CUEIIFwch7SgW2Qs3qgx3IqHHuH2m7RPeseFNzNeiNMOnbOAa5RH/fj5zL CALLwmOadac0tq/5Q/YMsdDBXZTJJi/tU3Oo4aw4XEiYucQ4v9UeSm/wygBF/pNXPQ8P E0DJuPN7d1bfN8rvw0jb/pebjj4+goP1JS05LzP0UpRpbTXlkd8656aqsaSOBBynb2Rj QdccboPnO4eYTjNxCxBSQauTuxsyddOR8uIBgqx4ytzZLnB2T/+K8n7T/JNQpCzmxi03 hzHMdzrElultmss1bYHfbvOgOelUuBd613xKZ+S7aYrrDgvtJHIkou0n2sbQUFqrrivO bwYQ== X-Gm-Message-State: ALoCoQmqYlLEWqAH/0RXh5uM/5ItYvcm+YVzqemqO9rkmLWFuOH1BBrd8Hk82yQ2nstnRwa1foQs X-Received: by 10.180.108.235 with SMTP id hn11mr47276467wib.14.1417633671741; Wed, 03 Dec 2014 11:07:51 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com. [74.125.82.44]) by mx.google.com with ESMTPSA id cq4sm37449782wjc.35.2014.12.03.11.07.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 11:07:51 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id b13so20710715wgh.17 for ; Wed, 03 Dec 2014 11:07:50 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.21.166 with SMTP id w6mr15431808wie.43.1417633670762; Wed, 03 Dec 2014 11:07:50 -0800 (PST) Received: by 10.216.70.16 with HTTP; Wed, 3 Dec 2014 11:07:50 -0800 (PST) In-Reply-To: <554d17d3779404eed3868ae587510e2f@ranjitvoip.com> References: <6bef1cce67d1c9da7c29d8e0804f2551@ranjitvoip.com> <554d17d3779404eed3868ae587510e2f@ranjitvoip.com> Date: Wed, 3 Dec 2014 14:07:50 -0500 Message-ID: From: Roman Shpount To: ranjit@ranjitvoip.com Content-Type: multipart/alternative; boundary=047d7b6d9a865e158d0509548f19 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ni7KchPgorm5pIon9H6sZnveNQ0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 19:07:59 -0000 --047d7b6d9a865e158d0509548f19 Content-Type: text/plain; charset=UTF-8 Ranjit, If you want to create yet another signaling protocol which uses WebSockets as a transport, please do. No one is stopping you. Just don't call it JSEP. Signaling is very different from JSEP, does a lot more then JSEP and requires a lot of effort to design properly and then map to JSEP API. If you create something compelling, other people will implement it and standardize it. At this point, I do not think this group is interested in creating yet another signaling protocol. I do not think this is something which is covered by this group charter. _____________ Roman Shpount On Wed, Dec 3, 2014 at 1:57 PM, wrote: > Hello all > > While I agree SIP over Websockets is default signaling protocol for WebRTC > while working with IMS, there could be scenarios where WebRTC calls can get > initiated from non SIP UAs like web browsers which do not support SIP. Then > in such cases, the following things could happen > 1) the WebRTC client on the browser can use JSEP to send its signaling > information over WebSocket, > 2) the JSEP message would then land on the WebRTC GW over WS. > 3) This JSEP message would then be converted to a SIP message and then > sent to IMS core. > 4) within IMS core, its a regular SIP message > 5) Again in the reverse direction, WebRTC GW would convert SIP to JSEP > 6) JSEP message is sent over Websocket to UE. > > now we see JSEP messages getting exchanged over Websockets. so if the > websocket sub-protocol does not define the type as "jsep", then the WebRTC > GW would not know the incoming message type and hence may discard it or its > behavior may be uncertain. > > Also the JSEP message needs to be enhanced to add more message types > (along with current OFFER / ANSWER) to be able to map it with standard > signaling protocol like SIP as defined in https://tools.ietf.org/html/ > draft-partha-rtcweb-jsep-sip-01 > > Regards > Ranjit > > On 2014-12-03 12:40 pm, Makaraju, Maridi Raju (Raju) wrote: > >> + 1 for using SIP over WebSocket. >> >> FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF Roman >> Shpount >> SENT: Wednesday, December 03, 2014 12:38 PM >> TO: ranjit@ranjitvoip.com >> CC: rtcweb@ietf.org >> SUBJECT: Re: [rtcweb] Interest and need for Websocket subprotocol - >> JSEP over websockets >> >> Is there any reason you cannot use SIP over WebSocket >> (https://tools.ietf.org/html/rfc7118 [1])? >> >> Call signaling will require a lot more information then what is >> provided in JSEP. JSEP mostly deals with offer and answer processing. >> Signaling will also need to deal with things like who is calling, why >> they are calling, transfers, other application specific details. In >> other words, I think this is a very bad idea. >> >> _____________ >> Roman Shpount >> >> On Wed, Dec 3, 2014 at 1:31 PM, wrote: >> >> Hi >> With websockets as a de-facto transport protocol for WebRTC signaling >> and JSEP being the format of encoding information, there is a need for >> a defining a websocket sub-protocol : jsep. So I would like to know if >> there is any interest in the community and also the views from experts >> about the need for a websocket-sub protocol for JSEP. >> >> The main purpose of defining the sub protocol (jsep) is to make sure >> that the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving >> JSEP encoded messages. >> >> Thanks >> Ranjit >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb [2] >> >> >> >> Links: >> ------ >> [1] https://tools.ietf.org/html/rfc7118 >> [2] https://www.ietf.org/mailman/listinfo/rtcweb >> > --047d7b6d9a865e158d0509548f19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ranjit,

If you want to create yet another= signaling protocol which uses WebSockets as a transport, please do. No one= is stopping you. Just don't call it JSEP. Signaling is very different = from JSEP, does a lot more then JSEP and requires a lot of effort to=C2=A0d= esign=C2=A0properly and then map to JSEP API. If you create something=C2=A0= compelling, other people will implement it and=C2=A0standardize=C2=A0it. At= this point, I do not think this group is interested in creating yet anothe= r signaling protocol. I do not think this is something which is covered by = this group charter.

_____________
Roman Shpount=

On Wed, Dec 3, 2014 at 1:57 PM, <ran= jit@ranjitvoip.com> wrote:
= Hello all

While I agree SIP over Websockets is default signaling protocol for WebRTC = while working with IMS, there could be scenarios where WebRTC calls can get= initiated from non SIP UAs like web browsers which do not support SIP. The= n in such cases, the following things could happen
1) the WebRTC client on the browser can use JSEP to send its signaling info= rmation over WebSocket,
2) the JSEP message would then land on the WebRTC GW over WS.
3) This JSEP message would then be converted to a SIP message and then sent= to IMS core.
4) within IMS core, its a regular SIP message
5) Again in the reverse direction, WebRTC GW would convert SIP to JSEP
6) JSEP message is sent over Websocket to UE.

now we see JSEP messages getting exchanged over Websockets. so if the webso= cket sub-protocol does not define the type as "jsep", then the We= bRTC GW would not know the incoming message type and hence may discard it o= r its behavior may be uncertain.

Also the JSEP message needs to be enhanced to add more message types (along= with current OFFER / ANSWER) to be able to map it with standard signaling = protocol like SIP as defined in https://tools.ietf.org/html/= draft-partha-rtcweb-jsep-sip-01

Regards
Ranjit

On 2014-12-03 12:40 pm, Makaraju, Maridi Raju (Raju) wrote:
+ 1 for using SIP over WebSocket.

 FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF Roman
Shpount
=C2=A0SENT: Wednesday, December 03, 2014 12:38 PM
=C2=A0TO: ranjit= @ranjitvoip.com
=C2=A0CC: rtcweb@ietf.= org
=C2=A0SUBJECT: Re: [rtcweb] Interest and need for Websocket subprotocol -
JSEP over websockets

Is there any reason you cannot use SIP over WebSocket
(https://= tools.ietf.org/html/rfc7118 [1])?

Call signaling will require a lot more information then what is
provided in JSEP. JSEP mostly deals with offer and answer processing.
Signaling will also need to deal with things like who is calling, why
they are calling, transfers, other application specific details. In
other words, I think this is a very bad idea.

_____________
=C2=A0Roman Shpount

On Wed, Dec 3, 2014 at 1:31 PM, <ranjit@ranjitvoip.com> wrote:

Hi
=C2=A0With websockets as a de-facto transport protocol for WebRTC signaling=
and JSEP being the format of encoding information, there is a need for
a defining a websocket sub-protocol : jsep. So I would like to know if
there is any interest in the community and also the views from experts
about the need for a websocket-sub protocol for JSEP.

=C2=A0The main purpose of defining the sub protocol (jsep) is to make sure<= br> that the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving
JSEP encoded messages.

=C2=A0Thanks
=C2=A0Ranjit

=C2=A0_______________________________________________
=C2=A0rtcweb mailing list
=C2=A0rtcweb@ietf.org<= /a>
 =C2=A0https://www.ietf.org/mailman/listinfo/rtcweb [2]



Links:
------
[1] https= ://tools.ietf.org/html/rfc7118
[2] https://www.ietf.org/mailman/listinfo/rtcweb

--047d7b6d9a865e158d0509548f19-- From nobody Wed Dec 3 11:13:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3911A1AC8 for ; Wed, 3 Dec 2014 11:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apwMABttEu2R for ; Wed, 3 Dec 2014 11:12:54 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 45DCD1A8F40 for ; Wed, 3 Dec 2014 11:12:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 8C3347C0972 for ; Wed, 3 Dec 2014 20:12:46 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_pmCPSJFrXU for ; Wed, 3 Dec 2014 20:12:42 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:70d4:5af0:ebdf:3bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 1AC287C0426 for ; Wed, 3 Dec 2014 20:12:42 +0100 (CET) Message-ID: <547F60A8.3080302@alvestrand.no> Date: Wed, 03 Dec 2014 20:12:40 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> In-Reply-To: <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fkDm672ZXRYubBJpOeVOgJt0Mio Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 19:12:59 -0000 On 12/03/2014 07:33 PM, David Singer wrote: > As I understand it, the recent face to face meeting decided to draft the requirement that WebRTC browsers be required to implement both VP8 and H.264, and get feedback on this, on the list. > > This is some feedback. > > > > I’d like to point out that this could easily place companies in an impossible position. > > Consider: it is not uncommon for IPR owners to grant a license (often free) only to ‘conforming implementations’. (A common rationale is that they want to use their IPR to bring convergence and interoperability to the industry). Let’s hypothesize that this happens, now or in future, from Company X, for some IPR in the WebRTC specifications. I'm having trouble following the logic here. What technology are you imagining that Company X will put IPR claims on, and what conformance do you imagine that it would require? (We could also consider the case of someone, call it Company G, claiming IPR on some non-codec part of WebRTC technology and refusing to license it at all. We can discuss the relative chances of the two things happening.) > > Consider also: we have an “unwilling to license†statement from Nokia on VP8, on the formal record (and including a long list of patents). > > Consider finally: a small company for whom WebRTC is important. > > > > Let’s look at the choices: > > 1. Follow the mandate, implement VP8, and risk a ruinous lawsuit from Nokia. > > 2. Reject the mandate, do not implement VP8, and be formally therefore not conformant and therefore not in receipt of a license from company X; risk a ruinous lawsuit from X. > > 3. Do not implement WebRTC, and risk a ruinous loss of relevance. > > > I do not think that the IETF should be placing anyone into the position of having three extremely unpalatable choices. If Company G does its thing, both 1 and 2 risk a ruinous lawsuit from Company G. > > (Yes, I am aware that #2 is ‘unlikely’, but one day someone will decide that the “only to conformant implementations†clause needs to be real and enforced, and will do this; our hypothetical small company might prefer not to be the example case.) > > (I use a small company as the example, because for them the risk is bankruptcy, but of course no-one likes to step into the path of trouble even if they have the resources to weather it.) My impression from the meeting was that the people speaking in favour of the proposed solution had evaluated the risks, and were ready to make a decision based on their evaluation. YMMV. > > Dave Singer > > singer@mac.com > > David Singer > Manager, Software Standards, Apple Inc. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Dec 3 11:16:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0351C1A1AA0 for ; Wed, 3 Dec 2014 11:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNagt6kXUOBM for ; Wed, 3 Dec 2014 11:15:59 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5DF1A6F59 for ; Wed, 3 Dec 2014 11:15:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4AB967C07F9 for ; Wed, 3 Dec 2014 20:15:57 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrteLH95R1W5 for ; Wed, 3 Dec 2014 20:15:53 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:70d4:5af0:ebdf:3bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 3C5367C0972 for ; Wed, 3 Dec 2014 20:15:53 +0100 (CET) Message-ID: <547F6168.9040801@alvestrand.no> Date: Wed, 03 Dec 2014 20:15:52 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <6bef1cce67d1c9da7c29d8e0804f2551@ranjitvoip.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HqEeh6iPfa1qSB1j-RmZGfDfOgg Subject: Re: [rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 19:16:01 -0000 This approach was proposed, discussed and abandoned by the WG in spring 2012. You might find https://tools.ietf.org/html/draft-jennings-rtcweb-signaling-01 interesting. On 12/03/2014 08:02 PM, ranjit@ranjitvoip.com wrote: > Hello all > > While I agree SIP over Websockets is default signaling protocol for > WebRTC while working with IMS, there could be scenarios where WebRTC > calls can get initiated from non SIP UAs like web browsers which do > not support SIP. Then in such cases, the following things could happen > 1) the WebRTC client on the browser can use JSEP to send its signaling > information over WebSocket, > 2) the JSEP message would then land on the WebRTC GW over WS. > 3) This JSEP message would then be converted to a SIP message and then > sent to IMS core. > 4) within IMS core, its a regular SIP message > 5) Again in the reverse direction, WebRTC GW would convert SIP to JSEP > 6) JSEP message is sent over Websocket to UE. > > now we see JSEP messages getting exchanged over Websockets. so if the > websocket sub-protocol does not define the type as "jsep", then the > WebRTC GW would not know the incoming message type and hence may > discard it or its behavior may be uncertain. > > Also the JSEP message needs to be enhanced to add more message types > (along with current OFFER / ANSWER) to be able to map it with standard > signaling protocol like SIP as defined in > https://tools.ietf.org/html/draft-partha-rtcweb-jsep-sip-01 > > Regards > Ranjit > > On 2014-12-03 12:40 pm, Makaraju, Maridi Raju (Raju) wrote: >> + 1 for using SIP over WebSocket. >> >> FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF Roman >> Shpount >> SENT: Wednesday, December 03, 2014 12:38 PM >> TO: ranjit@ranjitvoip.com >> CC: rtcweb@ietf.org >> SUBJECT: Re: [rtcweb] Interest and need for Websocket subprotocol - >> JSEP over websockets >> >> Is there any reason you cannot use SIP over WebSocket >> (https://tools.ietf.org/html/rfc7118 [1])? >> >> Call signaling will require a lot more information then what is >> provided in JSEP. JSEP mostly deals with offer and answer processing. >> Signaling will also need to deal with things like who is calling, why >> they are calling, transfers, other application specific details. In >> other words, I think this is a very bad idea. >> >> _____________ >> Roman Shpount >> >> On Wed, Dec 3, 2014 at 1:31 PM, wrote: >> >> Hi >> With websockets as a de-facto transport protocol for WebRTC signaling >> and JSEP being the format of encoding information, there is a need for >> a defining a websocket sub-protocol : jsep. So I would like to know if >> there is any interest in the community and also the views from experts >> about the need for a websocket-sub protocol for JSEP. >> >> The main purpose of defining the sub protocol (jsep) is to make sure >> that the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving >> JSEP encoded messages. >> >> Thanks >> Ranjit >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb [2] >> >> >> >> Links: >> ------ >> [1] https://tools.ietf.org/html/rfc7118 >> [2] https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Dec 3 11:28:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437B31A1B18 for ; Wed, 3 Dec 2014 11:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9AzHhYMcpnO for ; Wed, 3 Dec 2014 11:28:15 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3AE1A1EF6 for ; Wed, 3 Dec 2014 11:28:13 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bs8so32467456wib.10 for ; Wed, 03 Dec 2014 11:28:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=oU6tzGSPA3R6iF/GISo4vghnjyX2KUUcEfQyeEauqF0=; b=SYAUhERlzj+Q1Hw4pH2Hm6O2TMGn9EfnHtJYe5jdchEFHdHuErt/cX9+lr7OZMT+Kl T9Tguoxh+EGuoMok+Q0suUlsjjpbILWzWLswKJdIAi+5CxeFih4irZ9YZo+dae+f+bnM ZWi8ej906rH+AejxYZgz1jpJmjQ9Z3icSKYkkSFTFtejasyzwz2fRClpYumDMh5tiMIs 3hewWTFHSnnXRe+d8twbahSPbi7ilQrLVm4R9Y90FEBD07t8+72VUPPTUSmGc0XhboRl NpbSdCW3eU1GZXKHvrtSB1OxYprg3Uf9l7ruSpcLTdG1ShFIAmMZQUPNQrKe3vUBfoAk GzrQ== X-Received: by 10.180.90.81 with SMTP id bu17mr15120839wib.23.1417634891860; Wed, 03 Dec 2014 11:28:11 -0800 (PST) Received: from [192.168.0.193] ([95.61.111.78]) by mx.google.com with ESMTPSA id wx3sm37512969wjc.19.2014.12.03.11.28.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 11:28:11 -0800 (PST) Message-ID: <547F644C.4020508@gmail.com> Date: Wed, 03 Dec 2014 20:28:12 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> In-Reply-To: <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/E1yrl7a3qsMZ8tQA0XSCLK8NJDM Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 19:28:16 -0000 A copy of this email should be placed directly in the wikipedia definition of FUD.. Best regards Sergio On 03/12/2014 19:33, David Singer wrote: > As I understand it, the recent face to face meeting decided to draft the requirement that WebRTC browsers be required to implement both VP8 and H.264, and get feedback on this, on the list. > > This is some feedback. > > > > I’d like to point out that this could easily place companies in an impossible position. > > Consider: it is not uncommon for IPR owners to grant a license (often free) only to ‘conforming implementations’. (A common rationale is that they want to use their IPR to bring convergence and interoperability to the industry). Let’s hypothesize that this happens, now or in future, from Company X, for some IPR in the WebRTC specifications. > > Consider also: we have an “unwilling to license” statement from Nokia on VP8, on the formal record (and including a long list of patents). > > Consider finally: a small company for whom WebRTC is important. > > > > Let’s look at the choices: > > 1. Follow the mandate, implement VP8, and risk a ruinous lawsuit from Nokia. > > 2. Reject the mandate, do not implement VP8, and be formally therefore not conformant and therefore not in receipt of a license from company X; risk a ruinous lawsuit from X. > > 3. Do not implement WebRTC, and risk a ruinous loss of relevance. > > > I do not think that the IETF should be placing anyone into the position of having three extremely unpalatable choices. > > (Yes, I am aware that #2 is ‘unlikely’, but one day someone will decide that the “only to conformant implementations” clause needs to be real and enforced, and will do this; our hypothetical small company might prefer not to be the example case.) > > (I use a small company as the example, because for them the risk is bankruptcy, but of course no-one likes to step into the path of trouble even if they have the resources to weather it.) > > Dave Singer > > singer@mac.com > > David Singer > Manager, Software Standards, Apple Inc. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Dec 3 11:32:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82E91A6F27 for ; Wed, 3 Dec 2014 11:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrQN2uYivp4F for ; Wed, 3 Dec 2014 11:32:28 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2081A1EF6 for ; Wed, 3 Dec 2014 11:32:27 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so25567892wiv.13 for ; Wed, 03 Dec 2014 11:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=M4/Bo/4fww7g04y39llwGtP8T8Sx5MrPsfT40E28w/4=; b=ElDL5m7KXxa0zWdyyE8NaVNzAJHgD+wpk2dRwNFRbiNTFrTz2DSoXFUQnq8c5oUMbz tP3hPpYYFyOM5rgVTtaNN+kRSEOI511AlQAAleZXe3Q0KkWkGgUb1mAqmyBSfCg/NNat awjWPGyy6Fs+N4PZ8YgMKGw2eaJ/TJLAlf/PB0EZXF+gFRhg7wMRDsk8zcQmW4iLPWY3 XcjsBdGUZ/V2rrkLRq+Z6XjJ+WgbZp79BD6Qcww5ryIYePW+gUDqgxLRER8RS8bvLbBJ BIj920fPTEqNOTpRquSJXpIeylznUzBojMjQiB9qbgNTvOWUMthinl0zInirttQXTXNy 08fA== X-Received: by 10.180.206.47 with SMTP id ll15mr7739690wic.34.1417635146537; Wed, 03 Dec 2014 11:32:26 -0800 (PST) Received: from [192.168.0.193] ([95.61.111.78]) by mx.google.com with ESMTPSA id wx3sm37526653wjc.19.2014.12.03.11.32.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 11:32:25 -0800 (PST) Message-ID: <547F654B.8040608@gmail.com> Date: Wed, 03 Dec 2014 20:32:27 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <6bef1cce67d1c9da7c29d8e0804f2551@ranjitvoip.com> <554d17d3779404eed3868ae587510e2f@ranjitvoip.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080606050704040100010506" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JcaONonQSE6zZ0Jj7lWCR7R_Zhc Subject: Re: [rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 19:32:32 -0000 This is a multi-part message in MIME format. --------------080606050704040100010506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 On 03/12/2014 20:07, Roman Shpount wrote: > Ranjit, > > If you want to create yet another signaling protocol which uses > WebSockets as a transport, please do. No one is stopping you. Just > don't call it JSEP. Signaling is very different from JSEP, does a lot > more then JSEP and requires a lot of effort to design properly and > then map to JSEP API. If you create something compelling, other people > will implement it and standardize it. At this point, I do not think > this group is interested in creating yet another signaling protocol. I > do not think this is something which is covered by this group charter. > > _____________ > Roman Shpount > > On Wed, Dec 3, 2014 at 1:57 PM, > wrote: > > Hello all > > While I agree SIP over Websockets is default signaling protocol > for WebRTC while working with IMS, there could be scenarios where > WebRTC calls can get initiated from non SIP UAs like web browsers > which do not support SIP. Then in such cases, the following things > could happen > 1) the WebRTC client on the browser can use JSEP to send its > signaling information over WebSocket, > 2) the JSEP message would then land on the WebRTC GW over WS. > 3) This JSEP message would then be converted to a SIP message and > then sent to IMS core. > 4) within IMS core, its a regular SIP message > 5) Again in the reverse direction, WebRTC GW would convert SIP to JSEP > 6) JSEP message is sent over Websocket to UE. > > now we see JSEP messages getting exchanged over Websockets. so if > the websocket sub-protocol does not define the type as "jsep", > then the WebRTC GW would not know the incoming message type and > hence may discard it or its behavior may be uncertain. > > Also the JSEP message needs to be enhanced to add more message > types (along with current OFFER / ANSWER) to be able to map it > with standard signaling protocol like SIP as defined in > https://tools.ietf.org/html/draft-partha-rtcweb-jsep-sip-01 > > Regards > Ranjit > > On 2014-12-03 12:40 pm, Makaraju, Maridi Raju (Raju) wrote: > > + 1 for using SIP over WebSocket. > > FROM: rtcweb [mailto:rtcweb-bounces@ietf.org > ] ON BEHALF OF Roman > Shpount > SENT: Wednesday, December 03, 2014 12:38 PM > TO: ranjit@ranjitvoip.com > CC: rtcweb@ietf.org > SUBJECT: Re: [rtcweb] Interest and need for Websocket > subprotocol - > JSEP over websockets > > Is there any reason you cannot use SIP over WebSocket > (https://tools.ietf.org/html/rfc7118 [1])? > > Call signaling will require a lot more information then what is > provided in JSEP. JSEP mostly deals with offer and answer > processing. > Signaling will also need to deal with things like who is > calling, why > they are calling, transfers, other application specific > details. In > other words, I think this is a very bad idea. > > _____________ > Roman Shpount > > On Wed, Dec 3, 2014 at 1:31 PM, > wrote: > > Hi > With websockets as a de-facto transport protocol for WebRTC > signaling > and JSEP being the format of encoding information, there is a > need for > a defining a websocket sub-protocol : jsep. So I would like to > know if > there is any interest in the community and also the views from > experts > about the need for a websocket-sub protocol for JSEP. > > The main purpose of defining the sub protocol (jsep) is to > make sure > that the WebRTC client (WIC) and WebRTC server (E-CSCF) are > receiving > JSEP encoded messages. > > Thanks > Ranjit > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb [2] > > > > Links: > ------ > [1] https://tools.ietf.org/html/rfc7118 > [2] https://www.ietf.org/mailman/listinfo/rtcweb > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------080606050704040100010506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
+1

On 03/12/2014 20:07, Roman Shpount wrote:
Ranjit,

If you want to create yet another signaling protocol which uses WebSockets as a transport, please do. No one is stopping you. Just don't call it JSEP. Signaling is very different from JSEP, does a lot more then JSEP and requires a lot of effort to design properly and then map to JSEP API. If you create something compelling, other people will implement it and standardize it. At this point, I do not think this group is interested in creating yet another signaling protocol. I do not think this is something which is covered by this group charter.

_____________
Roman Shpount

On Wed, Dec 3, 2014 at 1:57 PM, <ranjit@ranjitvoip.com> wrote:
Hello all

While I agree SIP over Websockets is default signaling protocol for WebRTC while working with IMS, there could be scenarios where WebRTC calls can get initiated from non SIP UAs like web browsers which do not support SIP. Then in such cases, the following things could happen
1) the WebRTC client on the browser can use JSEP to send its signaling information over WebSocket,
2) the JSEP message would then land on the WebRTC GW over WS.
3) This JSEP message would then be converted to a SIP message and then sent to IMS core.
4) within IMS core, its a regular SIP message
5) Again in the reverse direction, WebRTC GW would convert SIP to JSEP
6) JSEP message is sent over Websocket to UE.

now we see JSEP messages getting exchanged over Websockets. so if the websocket sub-protocol does not define the type as "jsep", then the WebRTC GW would not know the incoming message type and hence may discard it or its behavior may be uncertain.

Also the JSEP message needs to be enhanced to add more message types (along with current OFFER / ANSWER) to be able to map it with standard signaling protocol like SIP as defined in https://tools.ietf.org/html/draft-partha-rtcweb-jsep-sip-01

Regards
Ranjit

On 2014-12-03 12:40 pm, Makaraju, Maridi Raju (Raju) wrote:
+ 1 for using SIP over WebSocket.

 FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF Roman
Shpount
 SENT: Wednesday, December 03, 2014 12:38 PM
 TO: ranjit@ranjitvoip.com
 CC: rtcweb@ietf.org
 SUBJECT: Re: [rtcweb] Interest and need for Websocket subprotocol -
JSEP over websockets

Is there any reason you cannot use SIP over WebSocket
 (https://tools.ietf.org/html/rfc7118 [1])?

Call signaling will require a lot more information then what is
provided in JSEP. JSEP mostly deals with offer and answer processing.
Signaling will also need to deal with things like who is calling, why
they are calling, transfers, other application specific details. In
other words, I think this is a very bad idea.

_____________
 Roman Shpount

On Wed, Dec 3, 2014 at 1:31 PM, <ranjit@ranjitvoip.com> wrote:

Hi
 With websockets as a de-facto transport protocol for WebRTC signaling
and JSEP being the format of encoding information, there is a need for
a defining a websocket sub-protocol : jsep. So I would like to know if
there is any interest in the community and also the views from experts
about the need for a websocket-sub protocol for JSEP.

 The main purpose of defining the sub protocol (jsep) is to make sure
that the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving
JSEP encoded messages.

 Thanks
 Ranjit

 _______________________________________________
 rtcweb mailing list
 rtcweb@ietf.org
  https://www.ietf.org/mailman/listinfo/rtcweb [2]



Links:
------
[1] https://tools.ietf.org/html/rfc7118
[2] https://www.ietf.org/mailman/listinfo/rtcweb



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------080606050704040100010506-- From nobody Wed Dec 3 12:54:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FD61AC3D0 for ; Wed, 3 Dec 2014 12:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwtD385r288n for ; Wed, 3 Dec 2014 12:54:32 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A611A89EB for ; Wed, 3 Dec 2014 12:54:32 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id y20so14605357ier.32 for ; Wed, 03 Dec 2014 12:54:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s770z3WqXAxwllRBf2CBJWVm7TL01QeBydvKE2Xtcbg=; b=HMGfxpqjOdN7u4CA6CDzD4rWZk5YkJv5PAMePOxovyXL1W2KrtNn8oyX4WADPUG8jg d4sSIir+5Xv6HtbCCM4j8MSOnt+E5JirIQLJ3UvGtWDw5iPhnkhTUeblgw3hcrk/6w6j cLrqmya0rQlzOKCDSdG0NSgElIhplq/SxI0U98PBFR1+um6ZGX6Zk0NOjS//0r9bzs3p GOPOQ0WBvGBxm5CtOYPQna+4rVeRuL/gT7rV3ggAsY3tP+esVZ6+NCxMvLKaOnhqFW96 PAHhYi+mjtKQ3KsANBkYXrqP1E2krN6Ini3L3bpdUxTGzWJVlzf1L2krE/qfD9+38asK SF4Q== MIME-Version: 1.0 X-Received: by 10.42.194.17 with SMTP id dw17mr8807934icb.4.1417640071403; Wed, 03 Dec 2014 12:54:31 -0800 (PST) Received: by 10.43.3.4 with HTTP; Wed, 3 Dec 2014 12:54:31 -0800 (PST) In-Reply-To: <6bef1cce67d1c9da7c29d8e0804f2551@ranjitvoip.com> References: <6bef1cce67d1c9da7c29d8e0804f2551@ranjitvoip.com> Date: Wed, 3 Dec 2014 12:54:31 -0800 Message-ID: From: Ted Hardie To: ranjit@ranjitvoip.com Content-Type: multipart/alternative; boundary=20cf30434a7ce01de90509560cf9 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OSWpNkMeN72wAGh-ZoMz1sCJN5Y Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 20:54:38 -0000 --20cf30434a7ce01de90509560cf9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ranjit, On Wed, Dec 3, 2014 at 10:31 AM, wrote: > Hi > With websockets as a de-facto transport protocol for WebRTC signaling and > JSEP being the format of encoding information, there is a need for a > defining a websocket sub-protocol : jsep. So I would like to know if ther= e > is any interest in the community and also the views from experts about th= e > need for a websocket-sub protocol for JSEP. > > The main purpose of defining the sub protocol (jsep) is to make sure that > the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving JSEP > encoded messages. > > Thanks > Ranjit > > =E2=80=8BIf I understand your proposal correctly, I believe it is currently= out of scope for the working group. If I understand the minimally necessary item, it is to define a websocket sub-protocol "jsep" so that gateways can use this token to indicate the appropriate handling. At least to my reading, this work is outside of our current charter. I'd suggest you start by approaching the area directors for pointers on where the work might take place. regards, Ted > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf30434a7ce01de90509560cf9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ranjit,
<= br>
On Wed, Dec 3, 2014 at 10:31 AM, <ran= jit@ranjitvoip.com> wrote:
Hi
With websockets as a de-facto transport protocol for WebRTC signaling and J= SEP being the format of encoding information, there is a need for a definin= g a websocket sub-protocol : jsep. So I would like to know if there is any = interest in the community and also the views from experts about the need fo= r a websocket-sub protocol for JSEP.

The main purpose of defining the sub protocol (jsep) is to make sure that t= he WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving JSEP encode= d messages.

Thanks
Ranjit


=E2=80=8BIf I understand your proposal = correctly, I believe it is currently out of scope for the working group.=C2= =A0 If I understand
the minimally necessary item, it is to define a webs= ocket sub-protocol "jsep" so that gateways can use this token to = indicate the appropriate handling.=C2=A0=C2=A0 At least to my reading, this= work is outside of our current charter.

I'd suggest you start b= y approaching the area directors for pointers on where the work might take = place.

regards,

Ted


=C2=A0
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--20cf30434a7ce01de90509560cf9-- From nobody Wed Dec 3 13:08:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B666C1A7028 for ; Wed, 3 Dec 2014 13:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxBUBauQg5VZ for ; Wed, 3 Dec 2014 13:07:52 -0800 (PST) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 593AF1A6FFE for ; Wed, 3 Dec 2014 13:07:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417640861; x=2281554461; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eKgHEeGCpNRdADfOvHpD3C7sWyYqxPfbHMGqI4B3Fjg=; b=y3IU/l4LsU4Xd24ZUiZgRjxeWLvcbgh7oQjNW/KsN2xCtmFE01O4l/oJrJ+GQnN+ n/G6aWirGQ85uCVLZwsyLvVSC2HBdhZDn4fOV3A2QR+CUTeSQ1DJhRL74b9IlLr2 /jiyvaC9K579e9jVlnSS950sOGlq9p9lneWqHaE691mlsCSlglvXdmt+ftqRDScR pEUayFtldci/8plB5hkcK5WJBUqMxW4IKrG8Vz64z81xyJ5MQiXz0y3RI0Wc99O/ DlBheGPJS/nt3IsEUBevJNFcDohB6hNuKa7pmUtFIVWIuqUvrFlXStGiA27yxl59 MN4oQ8P+Qzf4doCqj0dI9w==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 84.81.18976.D9B7F745; Wed, 3 Dec 2014 13:07:41 -0800 (PST) X-AuditID: 11973e11-f79a66d000004a20-bb-547f7b9d5959 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 71.47.06123.F9B7F745; Wed, 3 Dec 2014 13:07:43 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG000BXMYOTN410@marigold.apple.com> for rtcweb@ietf.org; Wed, 03 Dec 2014 13:07:41 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: David Singer In-reply-to: <547F644C.4020508@gmail.com> Date: Wed, 03 Dec 2014 13:07:41 -0800 Content-transfer-encoding: quoted-printable Message-id: <13DBCF15-90AB-40D0-9611-C77526560CEB@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F644C.4020508@gmail.com> To: Sergio Garcia Murillo X-Mailer: Apple Mail (2.1990.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FAYoTu3uj7EYG+vqcXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK2L53P1PBLqmKa1vfMTYwbhHtYuTkkBAwkZhx9ws7hC0mceHe ejYQW0hgL6PEkz5+mJqnpyYydjFyAcUnMUm0zP/PDOHMZ5J4O+0zUDcHB7OAusSUKbkgDbwC BhK3zsxgBLGFBSIkjnSeAVvAJqAq8WDOMbA4p4CmxOnv51hBbBag+JstZ5lAbGYBYYnvj++x QNjaEk/eXWCFmGkj0bwepB5k7w5GiYuXl4IlRASsJR79f8wCcam8xJwLJ9hAiiQEPrJKLGg7 zjaBUXgWwn2zkNw3C8mOBYzMqxiFchMzc3Qz84z0EgsKclL1kvNzNzGCwni6neAOxuOrrA4x CnAwKvHwPoiuCxFiTSwrrsw9xCjNwaIkzpuUXR8iJJCeWJKanZpakFoUX1Sak1p8iJGJg1Oq gTF9g0yDaBbTYu/Dkodrfp3wMX3unPHxeN9uw8aTCqukZ+iwmq+YHVV7gVHn25VfktkrL+ve 3W3Ad60geqWR+eTTyna1/EZMRUGP/5euDTJdUOz422jy19w/mc9PNs/+O23Kxf2vT6V/4spy 3FqTtKP7ftVSkS8Gzotu/q2QvtnK8IX93aMj8ZxKLMUZiYZazEXFiQBk/uH5RAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcoju/uj7E4OV3ZYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsX3vfqaCXVIV17a+Y2xg3CLaxcjJISFgIvH01ERGCFtM4sK9 9WxdjFwcQgKTmCRa5v9nhnDmM0m8nfaZvYuRg4NZQF1iypRckAZeAQOJW2dmgDULC0RIHOk8 ww5iswmoSjyYcwwszimgKXH6+zlWEJsFKP5my1kmEJtZQFji++N7LBC2tsSTdxdYIWbaSDSv B6kH2buDUeLi5aVgCREBa4lH/x+zQFwqLzHnwgm2CYwCsxBOmoXkpFlIxi5gZF7FKFCUmpNY aaqXWFCQk6qXnJ+7iREceIUROxj/L7M6xCjAwajEw/sgui5EiDWxrLgy9xCjBAezkgivdV59 iBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeqmyglEB6YklqdmpqQWoRTJaJg1OqgXGJ10R/47KZ uTPWHPr1afM5T6kfGl5c9xhkgrY8Wh5xqjYgavmSTXkrCvdn/VIU1sn+b3362kMmm5s319wx qOdZeZuVi/tP/OV7LzQ8/8a7tnLFC/ZtPjMxceOrgpeZOp7ZTds1CzatUXt+V6mofOXBhj7e r5LcwjxHZJqvfYv5cfFpFMO9vCVKLMUZiYZazEXFiQAk3lNqOAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7hqmQ_f7Z6nIvjI80JNQywZliMk Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 21:07:57 -0000 > On Dec 3, 2014, at 11:28 , Sergio Garcia Murillo = wrote: >=20 > A copy of this email should be placed directly in the wikipedia = definition of FUD.. There is plenty of F here. But there is little U and little D. The = Nokia statement exists and license grants of the type I cite are common. = Heck, the license given to MPEG-4 *reference software* says this: "ISO/IEC gives users of MPEG-4 free license to this software module or modifications thereof for use in hardware=20 or software products claiming conformance to MPEG-4.=E2=80=9D You want to put yourself at risk, go right ahead. Please don=E2=80=99t = ask that the IETF mandate that others put themselves at risk. >=20 > Best regards > Sergio > On 03/12/2014 19:33, David Singer wrote: >> As I understand it, the recent face to face meeting decided to draft = the requirement that WebRTC browsers be required to implement both VP8 = and H.264, and get feedback on this, on the list. >>=20 >> This is some feedback. >>=20 >>=20 >>=20 >> I=E2=80=99d like to point out that this could easily place companies = in an impossible position. >>=20 >> Consider: it is not uncommon for IPR owners to grant a license (often = free) only to =E2=80=98conforming implementations=E2=80=99. (A common = rationale is that they want to use their IPR to bring convergence and = interoperability to the industry). Let=E2=80=99s hypothesize that this = happens, now or in future, from Company X, for some IPR in the WebRTC = specifications. >>=20 >> Consider also: we have an =E2=80=9Cunwilling to license=E2=80=9D = statement from Nokia on VP8, on the formal record (and including a long = list of patents). >>=20 >> Consider finally: a small company for whom WebRTC is important. >>=20 >>=20 >>=20 >> Let=E2=80=99s look at the choices: >>=20 >> 1. Follow the mandate, implement VP8, and risk a ruinous lawsuit = from Nokia. >>=20 >> 2. Reject the mandate, do not implement VP8, and be formally = therefore not conformant and therefore not in receipt of a license from = company X; risk a ruinous lawsuit from X. >>=20 >> 3. Do not implement WebRTC, and risk a ruinous loss of relevance. >>=20 >>=20 >> I do not think that the IETF should be placing anyone into the = position of having three extremely unpalatable choices. >>=20 >> (Yes, I am aware that #2 is =E2=80=98unlikely=E2=80=99, but one day = someone will decide that the =E2=80=9Conly to conformant = implementations=E2=80=9D clause needs to be real and enforced, and will = do this; our hypothetical small company might prefer not to be the = example case.) >>=20 >> (I use a small company as the example, because for them the risk is = bankruptcy, but of course no-one likes to step into the path of trouble = even if they have the resources to weather it.) >>=20 >> Dave Singer >>=20 >> singer@mac.com >>=20 >> David Singer >> Manager, Software Standards, Apple Inc. >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb Dave Singer singer@mac.com David Singer Manager, Software Standards, Apple Inc. From nobody Wed Dec 3 13:08:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4369E1A7023 for ; Wed, 3 Dec 2014 13:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbmVgixvaB8r for ; Wed, 3 Dec 2014 13:07:58 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1401A700D for ; Wed, 3 Dec 2014 13:07:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417640875; x=2281554475; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=82OW76aWurPlIR6ZG+4EXi27lMHTK2IHBkPzV/1Dawc=; b=KDzbpK+7dEtf8Ud7+T46Km208Vz45L0fgEMkU18b/uU6vr6EB7liYFJ6kd1lMgVX a1yGkVAJGzahhFZxdqo4FNS9bDrfvlj14Wm7UGS0TOWE7P3qEVh/dWZYtNPQV6vl a3T6rXphjfoxBsDJywrACtndk/0xtAiDgkKDoziiExKKKRRWbS5Fi1J5PUINSCYZ Y+n/yvwAOyCF2zWwGS7CNbeT3CzcjzmQm241/9J4TIDjd0RTX1IsebxkTptUQnS1 mnCEp0pMuss/g4zDJz8rR4qjUGFgjZtsTQZ47hiwcKdRvHHRvZ7EPvyhY+LJ862H CZD5QNHmOdEWLRbmXaUDrw==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id A0.D0.05330.BAB7F745; Wed, 3 Dec 2014 13:07:55 -0800 (PST) X-AuditID: 11973e15-f791b6d0000014d2-ec-547f7bab2135 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 93.3D.05775.69B7F745; Wed, 3 Dec 2014 13:07:34 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG000BXMYOTN410@marigold.apple.com> for rtcweb@ietf.org; Wed, 03 Dec 2014 13:07:55 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: David Singer In-reply-to: <547F60A8.3080302@alvestrand.no> Date: Wed, 03 Dec 2014 13:07:54 -0800 Content-transfer-encoding: quoted-printable Message-id: <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F60A8.3080302@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1990.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FAYpbu6uj7EYPpvEYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMeflFaaCWzIVj2Z/Z29g/C3WxcjJISFgIvF06xd2CFtM4sK9 9WxdjFwcQgJ7GSXmXlzODFPUenQjK0RiEpPElbWHoJz5TBJP/18AquLgYBZQl5gyJRekgVfA QOLWmRmMILawQITEkc4zYBvYBFQlHsw5BhbnFNCVmLa4FyzOAhS/076PDcRmFhCW+P74HguE rS3x5N0FVoiZNhLfph2Fum4fo8SC7Q/BGkQEdCQe7m9ggrhUXmLOhRNgRRICb1kl9i15xTyB UXgWwn2zkNw3C8mOBYzMqxiFchMzc3Qz88z0EgsKclL1kvNzNzGCAnm6negOxjOrrA4xCnAw KvHwPoiuCxFiTSwrrsw9xCjNwaIkzpuUXR8iJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbHQ QSbI8u3bHSeCVVWC+GwKZvIt2KCl+Hjr+50/987St5xdVL41u0MyIOXzuv3dgRFfZW8fXF8S XPc5aLvlhqW81k81Zjxt3Z/OMPOdGPss/76Spi0XS5WSAvP+WL2Jn/v9+M+LHxk5FRU4FP27 WOJ66n57TLP89CDwk1Zahe+FS7WKLOvnvVRiKc5INNRiLipOBAAjJAtIRQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcojutuj7EYMcFA4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMeflFaaCWzIVj2Z/Z29g/C3WxcjJISFgItF6dCMrhC0mceHe erYuRi4OIYFJTBJX1h5ihXDmM0k8/X+BuYuRg4NZQF1iypRckAZeAQOJW2dmMILYwgIREkc6 z7CD2GwCqhIP5hwDi3MK6EpMW9wLFmcBit9p38cGYjMLCEt8f3yPBcLWlnjy7gIrxEwbiW/T jkIdsY9RYsH2h2ANIgI6Eg/3NzBBXCovMefCCbYJjAKzEE6aheSkWUjGLmBkXsUoUJSak1hp ppdYUJCTqpecn7uJERx4hVE7GBuWWx1iFOBgVOLhfRBdFyLEmlhWXJl7iFGCg1lJhNc6rz5E iDclsbIqtSg/vqg0J7X4EKM0B4uSOG9KNlBKID2xJDU7NbUgtQgmy8TBKdXAOOXt0vB5YYe5 5/t570wTXc6ceO1T0OoDcQvnPTj+QGWrfbrPvK77EY/0PzhMKXjQqejy6o1pEGvT6zvvXJav Fni/NcrOqLjV79YSqWahKd0H+zf1/EgTZZslv9JiY+Z31s8is0OOZXNKXfsl4v7u0iRT700p Fgs8O2/UPEycMN95Bl/f1iv3VZRYijMSDbWYi4oTAYrUNYk4AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2hYQEYFgoQdCDbQ7bjf-KpiTm0E Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 21:08:00 -0000 > On Dec 3, 2014, at 11:12 , Harald Alvestrand = wrote: >=20 > On 12/03/2014 07:33 PM, David Singer wrote: >> As I understand it, the recent face to face meeting decided to draft = the requirement that WebRTC browsers be required to implement both VP8 = and H.264, and get feedback on this, on the list. >>=20 >> This is some feedback. >>=20 >>=20 >>=20 >> I=E2=80=99d like to point out that this could easily place companies = in an impossible position. >>=20 >> Consider: it is not uncommon for IPR owners to grant a license (often = free) only to =E2=80=98conforming implementations=E2=80=99. (A common = rationale is that they want to use their IPR to bring convergence and = interoperability to the industry). Let=E2=80=99s hypothesize that this = happens, now or in future, from Company X, for some IPR in the WebRTC = specifications. >=20 > I'm having trouble following the logic here. What technology are you = imagining that Company X will put IPR claims on, and what conformance do = you imagine that it would require? I am imagining the common case that company X has IPR on some aspect of = the WebRTC spec. (some other aspect than the codec), and they offer the = fairly-common =E2=80=9Clicense is free to conforming implementations of = WebRTC=E2=80=9D. =20 >=20 > (We could also consider the case of someone, call it Company G, = claiming IPR on some non-codec part of WebRTC technology and refusing to = license it at all. We can discuss the relative chances of the two things = happening.) No, I am not interested in discussing trolls here. I am pursuing much = more normal circumstances. >=20 >>=20 >> Consider also: we have an =E2=80=9Cunwilling to license=E2=80=9D = statement from Nokia on VP8, on the formal record (and including a long = list of patents). >>=20 >> Consider finally: a small company for whom WebRTC is important. >>=20 >>=20 >>=20 >> Let=E2=80=99s look at the choices: >>=20 >> 1. Follow the mandate, implement VP8, and risk a ruinous lawsuit = from Nokia. >>=20 >> 2. Reject the mandate, do not implement VP8, and be formally = therefore not conformant and therefore not in receipt of a license from = company X; risk a ruinous lawsuit from X. >>=20 >> 3. Do not implement WebRTC, and risk a ruinous loss of relevance. >>=20 >>=20 >> I do not think that the IETF should be placing anyone into the = position of having three extremely unpalatable choices. > If Company G does its thing, both 1 and 2 risk a ruinous lawsuit from = Company G. >>=20 >> (Yes, I am aware that #2 is =E2=80=98unlikely=E2=80=99, but one day = someone will decide that the =E2=80=9Conly to conformant = implementations=E2=80=9D clause needs to be real and enforced, and will = do this; our hypothetical small company might prefer not to be the = example case.) >>=20 >> (I use a small company as the example, because for them the risk is = bankruptcy, but of course no-one likes to step into the path of trouble = even if they have the resources to weather it.) >=20 > My impression from the meeting was that the people speaking in favour = of the proposed solution had evaluated the risks, and were ready to make = a decision based on their evaluation. Well, this is exactly that: for the =E2=80=98vanilla=E2=80=99 company, = mandating VP8 means mandating a violation of Nokia=E2=80=99s statement, = which puts them at risk; or forcing people to abrogate a =E2=80=98must=E2= =80=99 clause, which also may put them at risk. Or not do WebRTC. Dave Singer singer@mac.com David Singer Manager, Software Standards, Apple Inc. From nobody Wed Dec 3 13:14:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664FD1A872E for ; Wed, 3 Dec 2014 13:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBFw_697Orsa for ; Wed, 3 Dec 2014 13:14:36 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FE01A86F9 for ; Wed, 3 Dec 2014 13:14:35 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id hn15so17608924igb.7 for ; Wed, 03 Dec 2014 13:14:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IeqLvG8vpgJYyRt8YeIefUv4qAhlVJKeHStIC/MZO+c=; b=LLsl9uBxztivJT59ha8O05Nzy7rftwgYNx7z9JK45MlD7reSuXiunkmDtkbmUmGQS7 ukkaR8dUAJsZ7in2rLvU/5BZDrIaBKJiLn5lTwTD+b2CE+3Vjvg6F9hrIZ8wVRXRqMoc wDK1PtYZLgCFUlyk78ZTCSBTdFchjN1RaOtZZYEgfW6/hw5b04lLZZxBhI0yNKO2FY6b 4/YiBqng0zCdQL0c8cXd+BX03XRWDmFL8szs4DiFwu1oqqF8kHXDpkoNFHJeiX4DBf9z mBWLNarAx1rCAJrQbCJtKlxjiNPnigdgOM+2V3VCI7yxfIvvuzHG6K/acr+Gjyhrwa0L Ue6w== MIME-Version: 1.0 X-Received: by 10.42.205.197 with SMTP id fr5mr4352136icb.5.1417641274767; Wed, 03 Dec 2014 13:14:34 -0800 (PST) Sender: elagerway@gmail.com Received: by 10.107.38.137 with HTTP; Wed, 3 Dec 2014 13:14:34 -0800 (PST) In-Reply-To: References: <6bef1cce67d1c9da7c29d8e0804f2551@ranjitvoip.com> <554d17d3779404eed3868ae587510e2f@ranjitvoip.com> Date: Wed, 3 Dec 2014 13:14:34 -0800 X-Google-Sender-Auth: TGC9gX1NVbr3VHHVyqB29vJKtow Message-ID: From: Erik Lagerway To: Roman Shpount Content-Type: multipart/alternative; boundary=20cf303ea2de99fdb80509565415 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/j4eNmWZ8DuLFFBTDtraKrnLB4xo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 21:14:38 -0000 --20cf303ea2de99fdb80509565415 Content-Type: text/plain; charset=UTF-8 +1 *Erik Lagerway | *Hookflash * | 1 (855) Hookflash ext. 2 | Twitter | WebRTC.is Blog * On Wed, Dec 3, 2014 at 11:07 AM, Roman Shpount wrote: > Ranjit, > > If you want to create yet another signaling protocol which uses WebSockets > as a transport, please do. No one is stopping you. Just don't call it JSEP. > Signaling is very different from JSEP, does a lot more then JSEP and > requires a lot of effort to design properly and then map to JSEP API. If > you create something compelling, other people will implement it > and standardize it. At this point, I do not think this group is interested > in creating yet another signaling protocol. I do not think this is > something which is covered by this group charter. > > _____________ > Roman Shpount > > On Wed, Dec 3, 2014 at 1:57 PM, wrote: > >> Hello all >> >> While I agree SIP over Websockets is default signaling protocol for >> WebRTC while working with IMS, there could be scenarios where WebRTC calls >> can get initiated from non SIP UAs like web browsers which do not support >> SIP. Then in such cases, the following things could happen >> 1) the WebRTC client on the browser can use JSEP to send its signaling >> information over WebSocket, >> 2) the JSEP message would then land on the WebRTC GW over WS. >> 3) This JSEP message would then be converted to a SIP message and then >> sent to IMS core. >> 4) within IMS core, its a regular SIP message >> 5) Again in the reverse direction, WebRTC GW would convert SIP to JSEP >> 6) JSEP message is sent over Websocket to UE. >> >> now we see JSEP messages getting exchanged over Websockets. so if the >> websocket sub-protocol does not define the type as "jsep", then the WebRTC >> GW would not know the incoming message type and hence may discard it or its >> behavior may be uncertain. >> >> Also the JSEP message needs to be enhanced to add more message types >> (along with current OFFER / ANSWER) to be able to map it with standard >> signaling protocol like SIP as defined in https://tools.ietf.org/html/ >> draft-partha-rtcweb-jsep-sip-01 >> >> Regards >> Ranjit >> >> On 2014-12-03 12:40 pm, Makaraju, Maridi Raju (Raju) wrote: >> >>> + 1 for using SIP over WebSocket. >>> >>> FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF Roman >>> Shpount >>> SENT: Wednesday, December 03, 2014 12:38 PM >>> TO: ranjit@ranjitvoip.com >>> CC: rtcweb@ietf.org >>> SUBJECT: Re: [rtcweb] Interest and need for Websocket subprotocol - >>> JSEP over websockets >>> >>> Is there any reason you cannot use SIP over WebSocket >>> (https://tools.ietf.org/html/rfc7118 [1])? >>> >>> Call signaling will require a lot more information then what is >>> provided in JSEP. JSEP mostly deals with offer and answer processing. >>> Signaling will also need to deal with things like who is calling, why >>> they are calling, transfers, other application specific details. In >>> other words, I think this is a very bad idea. >>> >>> _____________ >>> Roman Shpount >>> >>> On Wed, Dec 3, 2014 at 1:31 PM, wrote: >>> >>> Hi >>> With websockets as a de-facto transport protocol for WebRTC signaling >>> and JSEP being the format of encoding information, there is a need for >>> a defining a websocket sub-protocol : jsep. So I would like to know if >>> there is any interest in the community and also the views from experts >>> about the need for a websocket-sub protocol for JSEP. >>> >>> The main purpose of defining the sub protocol (jsep) is to make sure >>> that the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving >>> JSEP encoded messages. >>> >>> Thanks >>> Ranjit >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb [2] >>> >>> >>> >>> Links: >>> ------ >>> [1] https://tools.ietf.org/html/rfc7118 >>> [2] https://www.ietf.org/mailman/listinfo/rtcweb >>> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --20cf303ea2de99fdb80509565415 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

=
Erik Lagerway= =C2=A0|=C2=A0Hookflash<= span style=3D"color:rgb(0,0,0);font-size:13px">= =C2=A0| 1 (855)=C2=A0Hookfl= ash ext. 2 |=C2=A0Twitter=C2=A0|=C2=A0WebRTC.is Blog= =C2=A0

On Wed, Dec 3, 2014 at 11:07 AM, Roman Shpou= nt <roman@telurix.com> wrote:
Ranjit,

If you want to create yet ano= ther signaling protocol which uses WebSockets as a transport, please do. No= one is stopping you. Just don't call it JSEP. Signaling is very differ= ent from JSEP, does a lot more then JSEP and requires a lot of effort to=C2= =A0design=C2=A0properly and then map to JSEP API. If you create something= =C2=A0compelling, other people will implement it and=C2=A0standardize=C2=A0= it. At this point, I do not think this group is interested in creating yet = another signaling protocol. I do not think this is something which is cover= ed by this group charter.

_____________
Roman Shpount

On Wed, Dec 3, 2014 at 1:57 PM, <ran= jit@ranjitvoip.com> wrote:
= Hello all

While I agree SIP over Websockets is default signaling protocol for WebRTC = while working with IMS, there could be scenarios where WebRTC calls can get= initiated from non SIP UAs like web browsers which do not support SIP. The= n in such cases, the following things could happen
1) the WebRTC client on the browser can use JSEP to send its signaling info= rmation over WebSocket,
2) the JSEP message would then land on the WebRTC GW over WS.
3) This JSEP message would then be converted to a SIP message and then sent= to IMS core.
4) within IMS core, its a regular SIP message
5) Again in the reverse direction, WebRTC GW would convert SIP to JSEP
6) JSEP message is sent over Websocket to UE.

now we see JSEP messages getting exchanged over Websockets. so if the webso= cket sub-protocol does not define the type as "jsep", then the We= bRTC GW would not know the incoming message type and hence may discard it o= r its behavior may be uncertain.

Also the JSEP message needs to be enhanced to add more message types (along= with current OFFER / ANSWER) to be able to map it with standard signaling = protocol like SIP as defined in https://tools.ietf.org/html/= draft-partha-rtcweb-jsep-sip-01

Regards
Ranjit

On 2014-12-03 12:40 pm, Makaraju, Maridi Raju (Raju) wrote:
+ 1 for using SIP over WebSocket.

 FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF Roman
Shpount
=C2=A0SENT: Wednesday, December 03, 2014 12:38 PM
=C2=A0TO: ranjit= @ranjitvoip.com
=C2=A0CC: rtcweb@ietf.= org
=C2=A0SUBJECT: Re: [rtcweb] Interest and need for Websocket subprotocol -
JSEP over websockets

Is there any reason you cannot use SIP over WebSocket
(https://= tools.ietf.org/html/rfc7118 [1])?

Call signaling will require a lot more information then what is
provided in JSEP. JSEP mostly deals with offer and answer processing.
Signaling will also need to deal with things like who is calling, why
they are calling, transfers, other application specific details. In
other words, I think this is a very bad idea.

_____________
=C2=A0Roman Shpount

On Wed, Dec 3, 2014 at 1:31 PM, <ranjit@ranjitvoip.com> wrote:

Hi
=C2=A0With websockets as a de-facto transport protocol for WebRTC signaling=
and JSEP being the format of encoding information, there is a need for
a defining a websocket sub-protocol : jsep. So I would like to know if
there is any interest in the community and also the views from experts
about the need for a websocket-sub protocol for JSEP.

=C2=A0The main purpose of defining the sub protocol (jsep) is to make sure<= br> that the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving
JSEP encoded messages.

=C2=A0Thanks
=C2=A0Ranjit

=C2=A0_______________________________________________
=C2=A0rtcweb mailing list
=C2=A0rtcweb@ietf.org<= /a>
 =C2=A0https://www.ietf.org/mailman/listinfo/rtcweb [2]



Links:
------
[1] https= ://tools.ietf.org/html/rfc7118
[2] https://www.ietf.org/mailman/listinfo/rtcweb


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--20cf303ea2de99fdb80509565415-- From nobody Wed Dec 3 15:14:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44061A877C for ; Wed, 3 Dec 2014 15:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScERi-5CsTuI for ; Wed, 3 Dec 2014 15:14:37 -0800 (PST) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EAA81A8797 for ; Wed, 3 Dec 2014 15:14:37 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id x3so11773141qcv.22 for ; Wed, 03 Dec 2014 15:14:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=OwQ8ltpp5sjBsPR8yReUNIBW2kBsaOEx+/JRAQwKoMo=; b=kp0Ww3yzJUqa7q87KYejdG8QdbuNYz2mY6vcDyv0+3TDGSrxajyO7ORhlU0iMGLOjl xR62/ja1hVcfboSdNnSs5ZMJQdlRsDEK2nLEZknbbn81t23j47iRnSx6qD3klf/XpOCh WOq5Nijc11caT34y4iKgDT7+5kcX/6b+i3qcMVx6DqZh+Yi2k+0nQEyW8Jhi+HXu3EDr jlpt0cYzzACJDi61G/tX/uX+opBs/9RhC1fYzj1Nzn+HX7zPeMEmT/lfygtGKjj8vbMO YfvfJh/zHkt4YUHyAOtH8TWV6WyyTWFvifFr1/U19iklZHmWY5K1rIv3/HWN2rcbRPsa LJxg== X-Gm-Message-State: ALoCoQmP98Z+RN0Zlb5Hw+XaI0h1StFORIYP5c4v1yRDccAoPCNHDm1WGEsT6hZO2PWv3NphXPR0 X-Received: by 10.224.166.131 with SMTP id m3mr12029820qay.6.1417648476337; Wed, 03 Dec 2014 15:14:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Wed, 3 Dec 2014 15:14:15 -0800 (PST) In-Reply-To: <554d17d3779404eed3868ae587510e2f@ranjitvoip.com> References: <6bef1cce67d1c9da7c29d8e0804f2551@ranjitvoip.com> <554d17d3779404eed3868ae587510e2f@ranjitvoip.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 4 Dec 2014 00:14:15 +0100 Message-ID: To: ranjit@ranjitvoip.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/O8d8yrTgaiH_4Tm50jKN2u2nEw8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 23:14:39 -0000 2014-12-03 19:57 GMT+01:00 : > While I agree SIP over Websockets is default signaling protocol for WebRT= C > while working with IMS, there could be scenarios where WebRTC calls can g= et > initiated from non SIP UAs like web browsers which do not support SIP. There are not "browsers which do not support SIP" and there are not browsers supporting SIP. But fortunately browsers do support WebSocket and JavaScript, so we can implement&use SIP, XMPP, fooJSON or barJSON over WebSocket, or even CHICKEN over WebSocket. > Then > in such cases, the following things could happen > 1) the WebRTC client on the browser can use JSEP to send its signaling > information over WebSocket, OK, I know your SDP. Can you also tell me *who* you are? > now we see JSEP messages getting exchanged over Websockets. so if the > websocket sub-protocol does not define the type as "jsep", then the WebRT= C > GW would not know the incoming message type and hence may discard it or i= ts > behavior may be uncertain. You don't get the point. If you use SIP over WebSocket (within a WebRTC context) or XMPP over WebSocket or whatever other protocol, you are already using JSEP. Where? - When you use the W3C WebRTC API. - When you transmit the SDP offer from peerA to peerB (using SIP/XMPP/CHICKEN over WebSocket). - etc. > Also the JSEP message needs to be enhanced to add more message types (alo= ng > with current OFFER / ANSWER) to be able to map it with standard signaling > protocol like SIP as defined in > https://tools.ietf.org/html/draft-partha-rtcweb-jsep-sip-01 Fortunately it won't happen. But feel free to design your own wire protocol to transmit media related information among with your custom signaling information (who you are, who you are calling to, etc). Just don't request it to be a standard please. --=20 I=C3=B1aki Baz Castillo From nobody Wed Dec 3 15:32:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7E91A6F05 for ; Wed, 3 Dec 2014 15:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fMTnYrbNX5v for ; Wed, 3 Dec 2014 15:32:47 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5931A1ACE for ; Wed, 3 Dec 2014 15:32:46 -0800 (PST) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 03 Dec 2014 18:32:42 -0500 Received: from XCT112CNC.rim.net (10.65.161.212) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.210.2; Wed, 3 Dec 2014 18:32:41 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT112CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 18:32:40 -0500 From: Gaelle Martin-Cocher To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) Thread-Index: AQHQDyewEeqVo81nB0ShjNtLfXarlJx+j7gAgAAgMwD//7RIMA== Date: Wed, 3 Dec 2014 23:32:40 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F60A8.3080302@alvestrand.no> <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com> In-Reply-To: <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/d9Xe4coPw5Hr7lNuifBqY6mu1-0 Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2014 23:32:50 -0000 SGVsbG8sDQoNCkhlcmUgYXJlIHNvbWUgb3RoZXIgZmVlZGJhY2tzLg0KDQphKSBIb3cgY2FuIHRo ZSBncm91cCBjb21wb3NlZCBieSBhIHZhc3QgbWFqb3JpdHkgb2Ygbm9uLWJyb3dzZXIgdmVuZG9y cyBmb3JjZSBhIGRlY2lzaW9uIG9uIGJyb3dzZXIgdmVuZG9ycyBhZ2FpbnN0IHRoZWlyIHN0YXRl bWVudHM/IA0KLSBBcHBsZSBhbmQgTWljcm9zb2Z0IGhhdmUgc3RhdGVkIHRoYXQgdGhleSBoYXZl IG5vIHBsYW5zIHRvIGltcGxlbWVudCBWUDgNCi0gR29vZ2xlIGhhcyBzdGF0ZWQgdGhleSBpbnRl bmQgdG8gaW1wbGVtZW50IHRoZSBzcGVjIChhc3N1bWluZyB0aGUgdHdvIGNvZGVjcylidXQgdGhl eSBoYXZlIG5vdCBkZWNpZGVkIHlldCB3aGVuIGFuZCBob3cNCi0gTW96aWxsYSBpcyB0aGUgb25s eSBicm93c2VyIHZlbmRvciB0aGF0IGhhcyBhIGNsZWFyIGNvbW1pdG1lbnQuDQpIb3cgd2lsbCB0 aGUgc3BlY2lmaWNhdGlvbiBiZSByZWxldmFudCBpZiBNVEkgZnVuY3Rpb25zIGFyZSBzcGVjaWZp ZWQgd2hpbGUga25vd2luZyB0aGV5IHdpbGwgbGlrZWx5IG5vdCBiZSBpbXBsZW1lbnRlZD8NCkRv ZXMgdGhlIHByb3Bvc2VkIHRleHQgZ2l2ZSB1cyBpbnRlcm9wZXJhYmlsaXR5IG90aGVyIHRoYW4g b24gcGFwZXI/DQoNCmIpSSBkb24ndCB0aGluayB0aGVyZSB3YXMgZW5vdWdoIGRpc2N1c3Npb24g b24gIm5vbi1icm93c2VyIiBlbnRpdGllcy4gSSBiZWxpZXZlIHRoZSB0d28gdG9waWNzIChicm93 c2VyL25vbi1icm93c2VyKSBzaG91bGQgaGF2ZSBiZWVuIHNlcGFyYXRlZC4gVGhlcmUgd2FzIHF1 aXRlIGEgZmV3IG9iamVjdGlvbnMgb24gYSBub24tYnJvd3NlciBoYXZpbmcgdG8gaW1wbGVtZW50 IGJvdGggY29kZWNzLCBhdCB0aGUgbWVldGluZyBhbmQgb24gdGhlIGxpc3QgcHJpb3IgdG8gdGhl IG1lZXRpbmcuIFRoZXJlIHdhcyBzb21lIGNvbW1lbnRzIGFzIHdlbGwgYWJvdXQgdGhlIHN0YXRl IG9mIFdlYlJUQyBpbXBsZW1lbnRhdGlvbnMgcHJldmVudGluZyB0byBkZXBsb3kgYXBwbGljYXRp b25zLCB0aGUgY29kZWMgd2FzIG5vdCBhbiBpc3N1ZS4gTW9zdCBhcHBsaWNhdGlvbnMgbmVlZHMg dG8gaW50ZXJhY3Qgd2l0aCB0aGVtc2VsdmVzIG9uIG90aGVyIHBsYXRmb3JtcyBvciB2aWEgYnJv d3NlcnMuIEZvciB0aGF0IHB1cnBvc2UgdGhleSBjYW4gY2hvc2UgdGhlIGNvZGVjIHRoZXkgd2Fu dC4gQ2FuIHdlIGxlYXZlIHRoZSBub24tYnJvd3NlciBhbG9uZSAoYWthIG5vdCBtYW5kYXRpbmcg YSBjb2RlYykgb3IgYXNraW5nIHRoYXQgdGhleSBzdXBwb3J0IG9ubHkgb25lPw0KDQpDYW4gd2Ug c2VwYXJhdGUgdGhlIHR3byB0b3BpY3MgdG8gcmVhY2ggYWdyZWVtZW50IG9uIGVhY2ggb2YgdGhl bSBpbmRlcGVuZGVudGx5Pw0KDQpjKSBjb2RlYyB2ZXJzdXMgZGVjb2Rlcg0KSSBndWVzcyB0aGUg ZGlzY3Vzc2lvbiB3YXMgdmVyeSBsaW1pdGVkIGRlc3BpdGUgbXVsdGlwbGUgY29tbWVudHMgdGhh dCBkZWNvZGVyKHMpIG9ubHkgc2hvdWxkIGJlIG1hbmRhdGVkLiBJIGRpZCBub3QgZmluZCBhbnkg cmVhc29uaW5nIGZvciBtYW5kYXRpbmcgdGhlIHR3byBlbmNvZGVycyBpbiB0aGUgYXVkaW8gYXJj aGl2ZSBmZWVkLCBub3IgaW4gdGhlIHNsaWRlcy4gV2FzIHRoYXQgYSBsYWNrIG9mIHRpbWU/IENh biB3ZSBkaXNjdXNzIHRoYXQgcG9pbnQ/DQoNCg0KZClDb3N0IGluY3JlYXNlDQpDb3N0IGRvZXMg bm90IG9ubHkgZXF1YWwgdG8gcGF0ZW50IGxpY2Vuc2UuDQpDb3N0IGFsc28gaW5jbHVkZSBpbXBs ZW1lbnRhdGlvbiwgdGVzdGluZywgbWFpbnRlbmFuY2UsIHByb3ZpZGluZyBBUElzLiBCeSBtdWx0 aXBseWluZyBjb2RlY3MsIHRoZSBjb3N0IGlzIG1lY2hhbmljYWxseSBpbmNyZWFzZWQuIENhbiB0 aGlzIGJlIHRha2VuIGluIGFjY291bnQgaW4gdGhlIHJldmlzaXRpbmcgbm90ZT8NCg0KbGljZW5z aW5nIGFuZCBSRiBzdGF0ZW1lbnQuDQpJdCBzZWVtcyB0aGVyZSB3aWxsIGJlIGZ1cnRoZXIgZGlz Y3Vzc2lvbiBvbiB0aGUgcHJvcG9zZWQgcmV2aXNpdGluZyBub3RlLiBXaGVuPyBIb3c/IA0KTm9r aWEncyB0eXBlIDMgZGVjbGFyYXRpb24gaGFzIGJlZW4gcG9pbnRlZCBvdXQgbWFueSB0aW1lcyBh cyBhIHNlcmlvdXMgY29uY2Vybi4gDQpBbm90aGVyIGNvbmNlcm4gaXMgdGhlIGZvbGxvd2luZzog SXQgd2FzIHN0YXRlZCB0aGF0IEdvb2dsZSBpcyAid29ya2luZyBmcm9tIHRoZSBhc3N1bXB0aW9u IHRoYXQgVlA4IGlzIFJGIGFuZCB0aGF0IGFueW9uZSB0aGF0IGNoYWxsZW5nZXMgdGhhdCBhc3N1 bXB0aW9uIHdpbGwgYmUgcHJvdmVuIHdyb25nLiB0aGF0IHByb29mIG1heSB0YWtlIHRpbWUgYW5k IGxhd3llcnMgYnV0IHdlIGFyZSB3b3JraW5nIGZyb20gdGhhdCBhc3N1bXB0aW9uLiINCk1pY3Jv c29mdCwgRG9sYnkgYW5kIEVyaWNzc29uIGhhdmUgbWFkZSBhIHR5cGUgMiBkZWNsYXJhdGlvbiBh bmQgcG9zc2libHkgcXVpdGUgYSBmZXcgbW9yZSBjYW4gYmUgZXhwZWN0ZWQuDQpJdCBzZWVtcyB0 aGF0IG5vIG9uZSBrbm93cywgYXMgb2YgdG9kYXksIHRoZSBhY3R1YWwgbGljZW5zaW5nIHByaWNl IG9mIFZQODsgbm9yIGhvdyBsb25nIGl0IHdpbGwgdGFrZSB0byByZXNvbHZlIHRoYXQgcXVlc3Rp b24uDQoNCldoeSBkb2VzIGl0IHNvdW5kIHJlYXNvbmFibGUgdG8gdGhlIGdyb3VwIHRvIGltcG9z ZSB1bmtub3duIGZlZXMgdG8gV2ViUlRDIGVuZHBvaW50cyBhbmQgYWN0b3JzPyANCklzIHRoZSBn b2FsIHRvIGFsbGV2aWF0ZSB0aGUgY29kZWMgZmVlcyB0byBvbmx5IHBhcnQgb2YgdGhlIFdlYlJU QyBlY29zeXN0ZW0gKGFrYSBnYXRld2F5cz8gQXBwIGRldmVsb3BlcnMpPyANCkNhbiB0aGlzIGJl IGNsYXJpZmllZD8NCg0KDQoNCnRoYW5rcw0KR2HDq2xsZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBEYXZpZCBTaW5nZXINClNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMDMsIDIw MTQgNDowOCBQTQ0KVG86IEhhcmFsZCBBbHZlc3RyYW5kDQpDYzogcnRjd2ViQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW3J0Y3dlYl0gRmluaXNoaW5nIHVwIHRoZSBWaWRlbyBDb2RlYyBkb2N1bWVu dCwgTVRJIChhZ2Fpbiwgc3RpbGwsIHNvcnJ5KQ0KDQoNCj4gT24gRGVjIDMsIDIwMTQsIGF0IDEx OjEyICwgSGFyYWxkIEFsdmVzdHJhbmQgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPiB3cm90ZToNCj4g DQo+IE9uIDEyLzAzLzIwMTQgMDc6MzMgUE0sIERhdmlkIFNpbmdlciB3cm90ZToNCj4+IEFzIEkg dW5kZXJzdGFuZCBpdCwgdGhlIHJlY2VudCBmYWNlIHRvIGZhY2UgbWVldGluZyBkZWNpZGVkIHRv IGRyYWZ0IHRoZSByZXF1aXJlbWVudCB0aGF0IFdlYlJUQyBicm93c2VycyBiZSByZXF1aXJlZCB0 byBpbXBsZW1lbnQgYm90aCBWUDggYW5kIEguMjY0LCBhbmQgZ2V0IGZlZWRiYWNrIG9uIHRoaXMs IG9uIHRoZSBsaXN0Lg0KPj4gDQo+PiBUaGlzIGlzIHNvbWUgZmVlZGJhY2suDQo+PiANCj4+IA0K Pj4gDQo+PiBJ4oCZZCBsaWtlIHRvIHBvaW50IG91dCB0aGF0IHRoaXMgY291bGQgZWFzaWx5IHBs YWNlIGNvbXBhbmllcyBpbiBhbiBpbXBvc3NpYmxlIHBvc2l0aW9uLg0KPj4gDQo+PiBDb25zaWRl cjogaXQgaXMgbm90IHVuY29tbW9uIGZvciBJUFIgb3duZXJzIHRvIGdyYW50IGEgbGljZW5zZSAo b2Z0ZW4gZnJlZSkgb25seSB0byDigJhjb25mb3JtaW5nIGltcGxlbWVudGF0aW9uc+KAmS4gKEEg Y29tbW9uIHJhdGlvbmFsZSBpcyB0aGF0IHRoZXkgd2FudCB0byB1c2UgdGhlaXIgSVBSIHRvIGJy aW5nIGNvbnZlcmdlbmNlIGFuZCBpbnRlcm9wZXJhYmlsaXR5IHRvIHRoZSBpbmR1c3RyeSkuICBM ZXTigJlzIGh5cG90aGVzaXplIHRoYXQgdGhpcyBoYXBwZW5zLCBub3cgb3IgaW4gZnV0dXJlLCBm cm9tIENvbXBhbnkgWCwgZm9yIHNvbWUgSVBSIGluIHRoZSBXZWJSVEMgc3BlY2lmaWNhdGlvbnMu DQo+IA0KPiBJJ20gaGF2aW5nIHRyb3VibGUgZm9sbG93aW5nIHRoZSBsb2dpYyBoZXJlLiBXaGF0 IHRlY2hub2xvZ3kgYXJlIHlvdSBpbWFnaW5pbmcgdGhhdCBDb21wYW55IFggd2lsbCBwdXQgSVBS IGNsYWltcyBvbiwgYW5kIHdoYXQgY29uZm9ybWFuY2UgZG8geW91IGltYWdpbmUgdGhhdCBpdCB3 b3VsZCByZXF1aXJlPw0KDQpJIGFtIGltYWdpbmluZyB0aGUgY29tbW9uIGNhc2UgdGhhdCBjb21w YW55IFggaGFzIElQUiBvbiBzb21lIGFzcGVjdCBvZiB0aGUgV2ViUlRDIHNwZWMuIChzb21lIG90 aGVyIGFzcGVjdCB0aGFuIHRoZSBjb2RlYyksIGFuZCB0aGV5IG9mZmVyIHRoZSBmYWlybHktY29t bW9uIOKAnGxpY2Vuc2UgaXMgZnJlZSB0byBjb25mb3JtaW5nIGltcGxlbWVudGF0aW9ucyBvZiBX ZWJSVEPigJ0uICANCg0KPiANCj4gKFdlIGNvdWxkIGFsc28gY29uc2lkZXIgdGhlIGNhc2Ugb2Yg c29tZW9uZSwgY2FsbCBpdCBDb21wYW55IEcsIGNsYWltaW5nIElQUiBvbiBzb21lIG5vbi1jb2Rl YyBwYXJ0IG9mIFdlYlJUQyB0ZWNobm9sb2d5IGFuZCByZWZ1c2luZyB0byBsaWNlbnNlIGl0IGF0 IGFsbC4gV2UgY2FuIGRpc2N1c3MgdGhlIHJlbGF0aXZlIGNoYW5jZXMgb2YgdGhlIHR3byB0aGlu Z3MgaGFwcGVuaW5nLikNCg0KTm8sIEkgYW0gbm90IGludGVyZXN0ZWQgaW4gZGlzY3Vzc2luZyB0 cm9sbHMgaGVyZS4gIEkgYW0gcHVyc3VpbmcgbXVjaCBtb3JlIG5vcm1hbCBjaXJjdW1zdGFuY2Vz Lg0KDQo+IA0KPj4gDQo+PiBDb25zaWRlciBhbHNvOiB3ZSBoYXZlIGFuIOKAnHVud2lsbGluZyB0 byBsaWNlbnNl4oCdIHN0YXRlbWVudCBmcm9tIE5va2lhIG9uIFZQOCwgb24gdGhlIGZvcm1hbCBy ZWNvcmQgKGFuZCBpbmNsdWRpbmcgYSBsb25nIGxpc3Qgb2YgcGF0ZW50cykuDQo+PiANCj4+IENv bnNpZGVyIGZpbmFsbHk6IGEgc21hbGwgY29tcGFueSBmb3Igd2hvbSBXZWJSVEMgaXMgaW1wb3J0 YW50Lg0KPj4gDQo+PiANCj4+IA0KPj4gTGV04oCZcyBsb29rIGF0IHRoZSBjaG9pY2VzOg0KPj4g DQo+PiAxLiAgRm9sbG93IHRoZSBtYW5kYXRlLCBpbXBsZW1lbnQgVlA4LCBhbmQgcmlzayBhIHJ1 aW5vdXMgbGF3c3VpdCBmcm9tIE5va2lhLg0KPj4gDQo+PiAyLiAgUmVqZWN0IHRoZSBtYW5kYXRl LCBkbyBub3QgaW1wbGVtZW50IFZQOCwgYW5kIGJlIGZvcm1hbGx5IHRoZXJlZm9yZSBub3QgY29u Zm9ybWFudCBhbmQgdGhlcmVmb3JlIG5vdCBpbiByZWNlaXB0IG9mIGEgbGljZW5zZSBmcm9tIGNv bXBhbnkgWDsgcmlzayBhIHJ1aW5vdXMgbGF3c3VpdCBmcm9tIFguDQo+PiANCj4+IDMuICBEbyBu b3QgaW1wbGVtZW50IFdlYlJUQywgYW5kIHJpc2sgYSBydWlub3VzIGxvc3Mgb2YgcmVsZXZhbmNl Lg0KPj4gDQo+PiANCj4+IEkgZG8gbm90IHRoaW5rIHRoYXQgdGhlIElFVEYgc2hvdWxkIGJlIHBs YWNpbmcgYW55b25lIGludG8gdGhlIHBvc2l0aW9uIG9mIGhhdmluZyB0aHJlZSBleHRyZW1lbHkg dW5wYWxhdGFibGUgY2hvaWNlcy4NCj4gSWYgQ29tcGFueSBHIGRvZXMgaXRzIHRoaW5nLCBib3Ro IDEgYW5kIDIgcmlzayBhIHJ1aW5vdXMgbGF3c3VpdCBmcm9tIENvbXBhbnkgRy4NCj4+IA0KPj4g KFllcywgSSBhbSBhd2FyZSB0aGF0ICMyIGlzIOKAmHVubGlrZWx54oCZLCBidXQgb25lIGRheSBz b21lb25lIHdpbGwgZGVjaWRlIHRoYXQgdGhlIOKAnG9ubHkgdG8gY29uZm9ybWFudCBpbXBsZW1l bnRhdGlvbnPigJ0gY2xhdXNlIG5lZWRzIHRvIGJlIHJlYWwgYW5kIGVuZm9yY2VkLCBhbmQgd2ls bCBkbyB0aGlzOyBvdXIgaHlwb3RoZXRpY2FsIHNtYWxsIGNvbXBhbnkgbWlnaHQgcHJlZmVyIG5v dCB0byBiZSB0aGUgZXhhbXBsZSBjYXNlLikNCj4+IA0KPj4gKEkgdXNlIGEgc21hbGwgY29tcGFu eSBhcyB0aGUgZXhhbXBsZSwgYmVjYXVzZSBmb3IgdGhlbSB0aGUgcmlzayBpcyBiYW5rcnVwdGN5 LCBidXQgb2YgY291cnNlIG5vLW9uZSBsaWtlcyB0byBzdGVwIGludG8gdGhlIHBhdGggb2YgdHJv dWJsZSBldmVuIGlmIHRoZXkgaGF2ZSB0aGUgcmVzb3VyY2VzIHRvIHdlYXRoZXIgaXQuKQ0KPiAN Cj4gTXkgaW1wcmVzc2lvbiBmcm9tIHRoZSBtZWV0aW5nIHdhcyB0aGF0IHRoZSBwZW9wbGUgc3Bl YWtpbmcgaW4gZmF2b3VyIG9mIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBoYWQgZXZhbHVhdGVkIHRo ZSByaXNrcywgYW5kIHdlcmUgcmVhZHkgdG8gbWFrZSBhIGRlY2lzaW9uIGJhc2VkIG9uIHRoZWly IGV2YWx1YXRpb24uDQoNCldlbGwsIHRoaXMgaXMgZXhhY3RseSB0aGF0OiAgZm9yIHRoZSDigJh2 YW5pbGxh4oCZIGNvbXBhbnksIG1hbmRhdGluZyBWUDggbWVhbnMgbWFuZGF0aW5nIGEgdmlvbGF0 aW9uIG9mIE5va2lh4oCZcyBzdGF0ZW1lbnQsIHdoaWNoIHB1dHMgdGhlbSBhdCByaXNrOyAgb3Ig Zm9yY2luZyBwZW9wbGUgdG8gYWJyb2dhdGUgYSDigJhtdXN04oCZIGNsYXVzZSwgd2hpY2ggYWxz byBtYXkgcHV0IHRoZW0gYXQgcmlzay4gIE9yIG5vdCBkbyBXZWJSVEMuDQoNCg0KDQpEYXZlIFNp bmdlcg0KDQpzaW5nZXJAbWFjLmNvbQ0KDQpEYXZpZCBTaW5nZXINCk1hbmFnZXIsIFNvZnR3YXJl IFN0YW5kYXJkcywgQXBwbGUgSW5jLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K From nobody Wed Dec 3 16:22:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F26D1ACEF6 for ; Wed, 3 Dec 2014 16:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KotsKQPqxwIr for ; Wed, 3 Dec 2014 16:21:58 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1881A6FC8 for ; Wed, 3 Dec 2014 16:21:58 -0800 (PST) Received: from [192.168.5.151] (173-164-120-204-Oregon.hfc.comcastbusiness.net [173.164.120.204]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id AAE2AF22D7 for ; Wed, 3 Dec 2014 16:21:57 -0800 (PST) Message-ID: <547FA924.3000504@mozilla.com> Date: Wed, 03 Dec 2014 16:21:56 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F60A8.3080302@alvestrand.no> <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com> <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net> In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TL2UuFrapm7dh2u-xp2Fn3kO3E0 Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 00:22:00 -0000 Gaelle Martin-Cocher wrote: > a) How can the group composed by a vast majority of non-browser vendors force a decision on browser vendors against their statements? > > b)I don't think there was enough discussion on "non-browser" entities. I believe the two topics (browser/non-browser) should have been separated. There was quite a few objections on a non-browser having to implement both codecs, at the meeting and on the list prior to the meeting. Let me see if I can follow the logic here. There was a "vast majority of non-browser vendors" making this decision, but the overwhelming consensus achieved in the hum in Honolulu does not demonstrate that objections from non-browser vendors are "in the rough". From nobody Wed Dec 3 17:13:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C36C1A1A3C for ; Wed, 3 Dec 2014 17:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hf5Ke-W4J3pk for ; Wed, 3 Dec 2014 17:11:03 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id A49BC1A1BF2 for ; Wed, 3 Dec 2014 17:11:02 -0800 (PST) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 03 Dec 2014 20:10:57 -0500 Received: from XCT104CNC.rim.net (10.65.161.204) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.210.2; Wed, 3 Dec 2014 20:10:57 -0500 Received: from XMB121CNC.rim.net ([fe80::49cb:316:205b:d7d9]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 20:10:56 -0500 From: Andrew Allen To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) Thread-Index: AQHQDyew2za5sQikUES+QP80tOoCX5x+j7gAgAAQSIw= Date: Thu, 4 Dec 2014 01:10:56 +0000 Message-ID: <20141204011055.5955730.93184.3148@blackberry.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com>, <547F60A8.3080302@alvestrand.no> In-Reply-To: <547F60A8.3080302@alvestrand.no> Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_201412040110555955730931843148blackberrycom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/n4fqtfe-Xa8aw9QyylTgZToqmEU Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 01:11:06 -0000 --_000_201412040110555955730931843148blackberrycom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Harald I think it could be also characterized less of. Those in favor of the solut= ion had evaluates the risks and were reedy to make the decision based on th= at evaluation to instead. Many of those now in favor had defined a way for= ward where their implementations didn't need to expose them to the risks th= us minimizing the voice of those that would have to take the risk! Andrew H Sent from my BlackBerry 10 smartphone. From: Harald Alvestrand Sent: Wednesday, December 3, 2014 13:13 To: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, st= ill, sorry) On 12/03/2014 07:33 PM, David Singer wrote: > As I understand it, the recent face to face meeting decided to draft the = requirement that WebRTC browsers be required to implement both VP8 and H.26= 4, and get feedback on this, on the list. > > This is some feedback. > > > > I=92d like to point out that this could easily place companies in an impo= ssible position. > > Consider: it is not uncommon for IPR owners to grant a license (often fre= e) only to =91conforming implementations=92. (A common rationale is that th= ey want to use their IPR to bring convergence and interoperability to the i= ndustry). Let=92s hypothesize that this happens, now or in future, from Co= mpany X, for some IPR in the WebRTC specifications. I'm having trouble following the logic here. What technology are you imagining that Company X will put IPR claims on, and what conformance do you imagine that it would require? (We could also consider the case of someone, call it Company G, claiming IPR on some non-codec part of WebRTC technology and refusing to license it at all. We can discuss the relative chances of the two things happening.= ) > > Consider also: we have an =93unwilling to license=94 statement from Nokia= on VP8, on the formal record (and including a long list of patents). > > Consider finally: a small company for whom WebRTC is important. > > > > Let=92s look at the choices: > > 1. Follow the mandate, implement VP8, and risk a ruinous lawsuit from No= kia. > > 2. Reject the mandate, do not implement VP8, and be formally therefore n= ot conformant and therefore not in receipt of a license from company X; ris= k a ruinous lawsuit from X. > > 3. Do not implement WebRTC, and risk a ruinous loss of relevance. > > > I do not think that the IETF should be placing anyone into the position o= f having three extremely unpalatable choices. If Company G does its thing, both 1 and 2 risk a ruinous lawsuit from Company G. > > (Yes, I am aware that #2 is =91unlikely=92, but one day someone will deci= de that the =93only to conformant implementations=94 clause needs to be rea= l and enforced, and will do this; our hypothetical small company might pref= er not to be the example case.) > > (I use a small company as the example, because for them the risk is bankr= uptcy, but of course no-one likes to step into the path of trouble even if = they have the resources to weather it.) My impression from the meeting was that the people speaking in favour of the proposed solution had evaluated the risks, and were ready to make a decision based on their evaluation. YMMV. > > Dave Singer > > singer@mac.com > > David Singer > Manager, Software Standards, Apple Inc. > > _______________________________________________ > 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 --_000_201412040110555955730931843148blackberrycom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Harald
Sent from my BlackBerry 10 smartphone.
From: Harald Alvestrand
Sent: Wednesday, December 3, 2014 13:13
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Finishing up the Video Codec document, MT= I (again, still, sorry)

On 12/03/2014 07:33 PM, David Singer wrote:
> As I understand it, the recent face to face meeting decided to draft t= he requirement that WebRTC browsers be required to implement both VP8 and H= .264, and get feedback on this, on the list.
>
> This is some feedback.
>
>
>
> I=92d like to point out that this could easily place companies in an i= mpossible position.
>
> Consider: it is not uncommon for IPR owners to grant a license (often = free) only to =91conforming implementations=92. (A common rationale is that= they want to use their IPR to bring convergence and interoperability to th= e industry).  Let=92s hypothesize that this happens, now or in future, from Company X, for some IPR in the WebRTC spec= ifications.

I'm having trouble following the logic here. What technology are you
imagining that Company X will put IPR claims on, and what conformance do you imagine that it would require?

(We could also consider the case of someone, call it Company G, claiming IPR on some non-codec part of WebRTC technology and refusing to license it at all. We can discuss the relative chances of the two things happening.= )

>
> Consider also: we have an =93unwilling to license=94 statement from No= kia on VP8, on the formal record (and including a long list of patents). >
> Consider finally: a small company for whom WebRTC is important.
>
>
>
> Let=92s look at the choices:
>
> 1.  Follow the mandate, implement VP8, and risk a ruinous lawsuit= from Nokia.
>
> 2.  Reject the mandate, do not implement VP8, and be formally the= refore not conformant and therefore not in receipt of a license from compan= y X; risk a ruinous lawsuit from X.
>
> 3.  Do not implement WebRTC, and risk a ruinous loss of relevance= .
>
>
> I do not think that the IETF should be placing anyone into the positio= n of having three extremely unpalatable choices.
If Company G does its thing, both 1 and 2 risk a ruinous lawsuit from
Company G.
>
> (Yes, I am aware that #2 is =91unlikely=92, but one day someone will d= ecide that the =93only to conformant implementations=94 clause needs to be = real and enforced, and will do this; our hypothetical small company might p= refer not to be the example case.)
>
> (I use a small company as the example, because for them the risk is ba= nkruptcy, but of course no-one likes to step into the path of trouble even = if they have the resources to weather it.)

My impression from the meeting was that the people speaking in favour of the proposed solution had evaluated the risks, and were ready to make a decision based on their evaluation.

YMMV.

>
> Dave Singer
>
> singer@mac.com
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb
 --_000_201412040110555955730931843148blackberrycom_-- From nobody Wed Dec 3 17:28:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF291A6F32 for ; Wed, 3 Dec 2014 17:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.75 X-Spam-Level: X-Spam-Status: No, score=-0.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FSWYKfeFgyh for ; Wed, 3 Dec 2014 17:26:08 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B3E1A6F30 for ; Wed, 3 Dec 2014 17:26:08 -0800 (PST) Received: by mail-yk0-f174.google.com with SMTP id 10so7478053ykt.33 for ; Wed, 03 Dec 2014 17:26:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=rI1cPdW/iHUEp0D9rT5GpmznfHDp2kNT36+ES3y0JOI=; b=P8ty8vI1Z6DZ6Hn6Ay8Qu51xcAsGeyyNx1j6wrXG62bhoH9fJLEsZNHZLslHimOZnY 9MxWjASUsD31bcvKLOQvNkOkT0qK0APVUH5ZmMvVUq2HhPBNekWwU3BZZ6tqY5cq+mTm O2nLYNinX3Uub1xuMIs/cT0nWfEIEle8vIYPKFAeJSLMnlW7QVvKI3hAGs+LtyvpMZBA kCDDj8K4Y3fnNQWyp4qM/Uiv1Tz8D6IPpk78bL99JH1rYFYhzUE0setupa1EcSbtYCtf MWQm/qFmm/YTqyqZBCpwiy5LICR9SCU73wv6cCheAj7rKaYulug7RLCxLbOo+bAOZegl OxIw== X-Received: by 10.236.1.70 with SMTP id 46mr10290846yhc.78.1417656367446; Wed, 03 Dec 2014 17:26:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.170.135.193 with HTTP; Wed, 3 Dec 2014 17:25:47 -0800 (PST) In-Reply-To: <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> From: Silvia Pfeiffer Date: Thu, 4 Dec 2014 12:25:47 +1100 Message-ID: To: David Singer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cY1iWaoQcehfyYpNLu1H_ntJCVM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 01:26:10 -0000 On Thu, Dec 4, 2014 at 5:33 AM, David Singer wrote: > As I understand it, the recent face to face meeting decided to draft the = requirement that WebRTC browsers be required to implement both VP8 and H.26= 4, and get feedback on this, on the list. > > This is some feedback. > > > > I=E2=80=99d like to point out that this could easily place companies in a= n impossible position. > > Consider: it is not uncommon for IPR owners to grant a license (often fre= e) only to =E2=80=98conforming implementations=E2=80=99. (A common rational= e is that they want to use their IPR to bring convergence and interoperabil= ity to the industry). Let=E2=80=99s hypothesize that this happens, now or = in future, from Company X, for some IPR in the WebRTC specifications. > > Consider also: we have an =E2=80=9Cunwilling to license=E2=80=9D statemen= t from Nokia on VP8, on the formal record (and including a long list of pat= ents). > > Consider finally: a small company for whom WebRTC is important. > > > > Let=E2=80=99s look at the choices: > > 1. Follow the mandate, implement VP8, and risk a ruinous lawsuit from No= kia. > > 2. Reject the mandate, do not implement VP8, and be formally therefore n= ot conformant and therefore not in receipt of a license from company X; ris= k a ruinous lawsuit from X. > > 3. Do not implement WebRTC, and risk a ruinous loss of relevance. I don't see the risk of 1. having changed because of the IETF's statement. Plenty of small companies are already doing 1. and have had to risk getting sued by Nokia at this point in time already. In fact, it's a risk that small companies always have to deal with since there is so much patented technology around that you invariable will step on something. I doubt very much that the IETF's decision has any impact on small business' risk in that space at all. > I do not think that the IETF should be placing anyone into the position o= f having three extremely unpalatable choices. For a small company in the WebRTC space, 3. is a non-choice. 2. Is more of a business decision than an IP decision - which market are you trying to address? Are you trying to be interoperable with (current) browsers - then implement VP8. Are you trying to be interoperable with legacy devices - then implement H.264 (and probably even H.263). If you are trying to argue for a large company, the situation changes. However, as a large company, you tend to have an existing portfolio of patents. You're already playing the game of patents. As long as your hypothetical "IPR owners to grant a license only to =E2=80=98conforming implementations=E2=80=99" doesn't happen, you are free to choose 2. and avo= id Nokia. As for the threat in your option 2. - I can only see Google with IPR around VP8. Now, Google's IPR statement on WebM codecs, which includes VP8 and VP9 currently states: "Google hereby grants to you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license" http://www.webmproject.org/license/additional/ The word "perpetual" implies (to my non-lawyer eyes) that they can't suddenly change this to mean "only if you are conformant to the standard". So you can't be referring to such a risk associated with VP8 being created by Google. I don't know which other company you would want to be afraid of for your hypothetical threat in 2. Could you clarify? Best Regards, Silvia. > (Yes, I am aware that #2 is =E2=80=98unlikely=E2=80=99, but one day someo= ne will decide that the =E2=80=9Conly to conformant implementations=E2=80= =9D clause needs to be real and enforced, and will do this; our hypothetica= l small company might prefer not to be the example case.) > > (I use a small company as the example, because for them the risk is bankr= uptcy, but of course no-one likes to step into the path of trouble even if = they have the resources to weather it.) > > Dave Singer > > singer@mac.com > > David Singer > Manager, Software Standards, Apple Inc. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Dec 3 17:44:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54011A6F58 for ; Wed, 3 Dec 2014 17:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZT4A7S7IG_L for ; Wed, 3 Dec 2014 17:42:31 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id CF2201A00D8 for ; Wed, 3 Dec 2014 17:42:30 -0800 (PST) Received: from xct107cnc.rim.net ([10.65.161.207]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 03 Dec 2014 20:42:20 -0500 Received: from XCT112CNC.rim.net (10.65.161.212) by XCT107CNC.rim.net (10.65.161.207) with Microsoft SMTP Server (TLS) id 14.3.210.2; Wed, 3 Dec 2014 20:42:20 -0500 Received: from XMB121CNC.rim.net ([fe80::49cb:316:205b:d7d9]) by XCT112CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 20:42:19 -0500 From: Andrew Allen To: Silvia Pfeiffer , David Singer Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) Thread-Index: AQHQDyew2za5sQikUES+QP80tOoCX5x+9/iA//+wzeo= Date: Thu, 4 Dec 2014 01:42:19 +0000 Message-ID: <20141204014218.5955730.38619.3157@blackberry.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com>, In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_201412040142185955730386193157blackberrycom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-BeBuTjV39-yWeyRqkYB5Cw-_-0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 01:42:34 -0000 --_000_201412040142185955730386193157blackberrycom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Silvia It is not usually the small companies that get sued in patent cases. Its c= ompanies with assets and significant revenues that get the lawsuits. Nobody sues the penniless! - thats like suing the homeless! Andrew Sent from my BlackBerry 10 smartphone. From: Silvia Pfeiffer Sent: Wednesday, December 3, 2014 19:28 To: David Singer Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, st= ill, sorry) On Thu, Dec 4, 2014 at 5:33 AM, David Singer wrote: > As I understand it, the recent face to face meeting decided to draft the = requirement that WebRTC browsers be required to implement both VP8 and H.26= 4, and get feedback on this, on the list. > > This is some feedback. > > > > I=92d like to point out that this could easily place companies in an impo= ssible position. > > Consider: it is not uncommon for IPR owners to grant a license (often fre= e) only to =91conforming implementations=92. (A common rationale is that th= ey want to use their IPR to bring convergence and interoperability to the i= ndustry). Let=92s hypothesize that this happens, now or in future, from Co= mpany X, for some IPR in the WebRTC specifications. > > Consider also: we have an =93unwilling to license=94 statement from Nokia= on VP8, on the formal record (and including a long list of patents). > > Consider finally: a small company for whom WebRTC is important. > > > > Let=92s look at the choices: > > 1. Follow the mandate, implement VP8, and risk a ruinous lawsuit from No= kia. > > 2. Reject the mandate, do not implement VP8, and be formally therefore n= ot conformant and therefore not in receipt of a license from company X; ris= k a ruinous lawsuit from X. > > 3. Do not implement WebRTC, and risk a ruinous loss of relevance. I don't see the risk of 1. having changed because of the IETF's statement. Plenty of small companies are already doing 1. and have had to risk getting sued by Nokia at this point in time already. In fact, it's a risk that small companies always have to deal with since there is so much patented technology around that you invariable will step on something. I doubt very much that the IETF's decision has any impact on small business' risk in that space at all. > I do not think that the IETF should be placing anyone into the position o= f having three extremely unpalatable choices. For a small company in the WebRTC space, 3. is a non-choice. 2. Is more of a business decision than an IP decision - which market are you trying to address? Are you trying to be interoperable with (current) browsers - then implement VP8. Are you trying to be interoperable with legacy devices - then implement H.264 (and probably even H.263). If you are trying to argue for a large company, the situation changes. However, as a large company, you tend to have an existing portfolio of patents. You're already playing the game of patents. As long as your hypothetical "IPR owners to grant a license only to =91conforming implementations=92" doesn't happen, you are free to choose 2. and avoid Nokia. As for the threat in your option 2. - I can only see Google with IPR around VP8. Now, Google's IPR statement on WebM codecs, which includes VP8 and VP9 currently states: "Google hereby grants to you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license" http://www.webmproject.org/license/additional/ The word "perpetual" implies (to my non-lawyer eyes) that they can't suddenly change this to mean "only if you are conformant to the standard". So you can't be referring to such a risk associated with VP8 being created by Google. I don't know which other company you would want to be afraid of for your hypothetical threat in 2. Could you clarify? Best Regards, Silvia. > (Yes, I am aware that #2 is =91unlikely=92, but one day someone will deci= de that the =93only to conformant implementations=94 clause needs to be rea= l and enforced, and will do this; our hypothetical small company might pref= er not to be the example case.) > > (I use a small company as the example, because for them the risk is bankr= uptcy, but of course no-one likes to step into the path of trouble even if = they have the resources to weather it.) > > Dave Singer > > singer@mac.com > > David Singer > Manager, Software Standards, Apple Inc. > > _______________________________________________ > 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 --_000_201412040142185955730386193157blackberrycom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Silvia

Sent from my BlackBerry 10 smartphone.
From: Silvia Pfeiffer
Sent: Wednesday, December 3, 2014 19:28
To: David Singer
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Finishing up the Video Codec document, MT= I (again, still, sorry)

On Thu, Dec 4, 2014 at 5:33 AM, David Singer <s= inger@apple.com> wrote:
> As I understand it, the recent face to face meeting decided to draft t= he requirement that WebRTC browsers be required to implement both VP8 and H= .264, and get feedback on this, on the list.
>
> This is some feedback.
>
>
>
> I=92d like to point out that this could easily place companies in an i= mpossible position.
>
> Consider: it is not uncommon for IPR owners to grant a license (often = free) only to =91conforming implementations=92. (A common rationale is that= they want to use their IPR to bring convergence and interoperability to th= e industry).  Let=92s hypothesize that this happens, now or in future, from Company X, for some IPR in the WebRTC spec= ifications.
>
> Consider also: we have an =93unwilling to license=94 statement from No= kia on VP8, on the formal record (and including a long list of patents). >
> Consider finally: a small company for whom WebRTC is important.
>
>
>
> Let=92s look at the choices:
>
> 1.  Follow the mandate, implement VP8, and risk a ruinous lawsuit= from Nokia.
>
> 2.  Reject the mandate, do not implement VP8, and be formally the= refore not conformant and therefore not in receipt of a license from compan= y X; risk a ruinous lawsuit from X.
>
> 3.  Do not implement WebRTC, and risk a ruinous loss of relevance= .


I don't see the risk of 1. having changed because of the IETF's
statement. Plenty of small companies are already doing 1. and have had
to risk getting sued by Nokia at this point in time already. In fact,
it's a risk that small companies always have to deal with since there
is so much patented technology around that you invariable will step on
something. I doubt very much that the IETF's decision has any impact
on small business' risk in that space at all.


> I do not think that the IETF should be placing anyone into the positio= n of having three extremely unpalatable choices.

For a small company in the WebRTC space, 3. is a non-choice. 2. Is
more of a business decision than an IP decision - which market are you
trying to address? Are you trying to be interoperable with (current)
browsers - then implement VP8. Are you trying to be interoperable with
legacy devices - then implement H.264 (and probably even H.263).

If you are trying to argue for a large company, the situation changes.
However, as a large company, you tend to have an existing portfolio of
patents. You're already playing the game of patents. As long as your
hypothetical "IPR owners to grant a license only to =91conforming
implementations=92" doesn't happen, you are free to choose 2. and avoi= d
Nokia.

As for the threat in your option 2. - I can only see Google with IPR
around VP8. Now, Google's IPR statement on WebM codecs, which includes
VP8 and VP9 currently states: "Google hereby grants to you a
perpetual, worldwide, non-exclusive, no-charge, royalty-free,
irrevocable (except as stated in this section) patent license"
http://www.webmp= roject.org/license/additional/
The word "perpetual" implies (to my non-lawyer eyes) that they ca= n't
suddenly change this to mean "only if you are conformant to the
standard". So you can't be referring to such a risk associated with VP8 being created by Google. I don't know which other company you
would want to be afraid of for your hypothetical threat in 2. Could
you clarify?


Best Regards,
Silvia.


> (Yes, I am aware that #2 is =91unlikely=92, but one day someone will d= ecide that the =93only to conformant implementations=94 clause needs to be = real and enforced, and will do this; our hypothetical small company might p= refer not to be the example case.)
>
> (I use a small company as the example, because for them the risk is ba= nkruptcy, but of course no-one likes to step into the path of trouble even = if they have the resources to weather it.)
>
> Dave Singer
>
> singer@mac.com
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb
 --_000_201412040142185955730386193157blackberrycom_-- From nobody Wed Dec 3 18:11:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D941A87E7 for ; Wed, 3 Dec 2014 18:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93cEvubdfV-r for ; Wed, 3 Dec 2014 18:08:24 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6039B1A87EB for ; Wed, 3 Dec 2014 18:08:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417658892; x=2281572492; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Kt3Nmcieh6zes7O7Oct7EvFcklcGL38lstxChKauEsk=; b=ixQWqEAxTIn0kar8vXsdKCAXUP6594fDXkbJhfC/MYy83qr/MlHyw3tQ/mhKohlK YR3fyYgvV8mMakUHOlAuCeOCXwmU6tGlBgblWa98dMkb4KiO+C7suTKvvcfz2jnD r9+hglufyA4WW6gW0Yi8sf2qK+7SqjCx8EDGNXpuFgk8d0OYrF7+FfmHPrzPmVTf 87Voce7DieBe8uD1EuIEyLqhcJu+gSKVyjI5c7tiw7/kSbk7w3P5TR5NBx39j8wk UX5fBeh+0QKMqMVbpwE2oSisgwRvGue7f6B/olln4sHizD5yv8+wstq3JSo516iz lj2MXa49TJy30dU5CM+tDA==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 8B.C7.05330.C02CF745; Wed, 3 Dec 2014 18:08:12 -0800 (PST) X-AuditID: 11973e15-f791b6d0000014d2-8d-547fc20cea69 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 68.E6.05858.602CF745; Wed, 3 Dec 2014 18:08:06 -0800 (PST) Received: from [10.132.54.69] (server.frittshanna.com [76.74.153.41]) by koseret.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG1001M7CLMDL00@koseret.apple.com> for rtcweb@ietf.org; Wed, 03 Dec 2014 18:08:12 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (1.0) From: David Singer X-Mailer: iPad Mail (12B435) In-reply-to: Date: Wed, 03 Dec 2014 18:08:11 -0800 Content-transfer-encoding: quoted-printable Message-id: <57A07A1B-DB2B-429E-BBFC-24500F91EE60@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> To: Silvia Pfeiffer X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FDorMtzqD7EYPUjVYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8XHJZqaCzWoVz368Zm9g/C7XxcjJISFgIvHzViszhC0mceHe erYuRi4OIYG9jBJb17xnhCn6s2AbM0SihUni0+x2JghnAZPEppnzWboYOTiYBdQlpkzJBWng FRCXeH10ClizsECExJHOM+wgNpuAqsSDOceghspINN1cyApicwoES3z4vw3sChagmuWbjrOB 2CAjl05ugLK1JZ68u8AKMd9G4s7byVA3PGKUWHz6JlhCREBfovnYFhaQhITAS1aJi7uvs09g FJ6FcN8sJPfNQjJ3ASPzKkah3MTMHN3MPDO9xIKCnFS95PzcTYygQJ5uJ7qD8cwqq0OMAhyM Sjy8hbvrQ4RYE8uKK3MPMUpzsCiJ8yZlA4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwar6f ei+A+WKuwq194cX7N6yavWsCl8oSve1JxqdCeJte8TevPS02/W3+/3svli9hWf3566IfZ12a bnzo+rZmS+f9qv8THF+mpk/lWG+48fDPaokLvOYyc/qubTf8mLCnkdN1U/q2Lw05x3+sveLl dU8gr62TT0pKaVaeptKBi24z3f+sfr1m2kQlluKMREMt5qLiRACEQevjRQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUiON1OXZftUH2IwakfKhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4+OSzUwFm9Uqnv14zd7A+F2ui5GTQ0LAROLPgm3MELaYxIV7 69m6GLk4hARamCQ+zW5ngnAWMElsmjmfpYuRg4NZQF1iypRckAZeAXGJ10enMILYwgIREkc6 z7CD2GwCqhIP5hxjhBgqI9F0cyEriM0pECzx4T/EMhagmuWbjrOB2CAjl05ugLK1JZ68u8AK Md9G4s7byVA3PGKUWHz6JlhCREBfovnYFpYJjAKzEE6aheSkWUhGLWBkXsUoUJSak1hppJdY UJCTqpecn7uJERR4DYXOOxiPLbM6xCjAwajEw1uwuz5EiDWxrLgy9xCjBAezkghvTi9QiDcl sbIqtSg/vqg0J7X4EKM0B4uSOG9xNlBKID2xJDU7NbUgtQgmy8TBKdXAGNShHHuVzyp0Q/Wh Cg/pSx9ffU/a5SDif2Zr70yJ/RfEpK9V6901uOAzQ2FT1yM5hyyNvM+dnV/l9x2trq7zdVON UOsp/yiWG7TViPFJc9/CjMOv+a0TWr99mXHtrIC59NYX/Bby4r8epz9OOugjcdIoQH+Rn+66 6z/PCLzNnbCtxFRbu6ZIiaU4I9FQi7moOBEAAOw3LDgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sV1DPuzt9rnMj1IXa05kcrOlzIE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 02:08:32 -0000 You're missing something. I am considering a company that has ipr in *other*= aspects of webrtc, that gives a license to that only to conformant implemen= tations. Not the codec. What do you do? Defy the Nokia declaration, defy the 'must' and not do vp8 a= nd be non-conformant, or not do webrtc at all? None are good choices. Sent from my iPad > On Dec 3, 2014, at 5:25 PM, Silvia Pfeiffer wr= ote: >=20 >> On Thu, Dec 4, 2014 at 5:33 AM, David Singer wrote: >> As I understand it, the recent face to face meeting decided to draft the r= equirement that WebRTC browsers be required to implement both VP8 and H.264,= and get feedback on this, on the list. >>=20 >> This is some feedback. >>=20 >>=20 >>=20 >> I=E2=80=99d like to point out that this could easily place companies in a= n impossible position. >>=20 >> Consider: it is not uncommon for IPR owners to grant a license (often fre= e) only to =E2=80=98conforming implementations=E2=80=99. (A common rationale= is that they want to use their IPR to bring convergence and interoperabilit= y to the industry). Let=E2=80=99s hypothesize that this happens, now or in f= uture, from Company X, for some IPR in the WebRTC specifications. >>=20 >> Consider also: we have an =E2=80=9Cunwilling to license=E2=80=9D statemen= t from Nokia on VP8, on the formal record (and including a long list of pate= nts). >>=20 >> Consider finally: a small company for whom WebRTC is important. >>=20 >>=20 >>=20 >> Let=E2=80=99s look at the choices: >>=20 >> 1. Follow the mandate, implement VP8, and risk a ruinous lawsuit from No= kia. >>=20 >> 2. Reject the mandate, do not implement VP8, and be formally therefore n= ot conformant and therefore not in receipt of a license from company X; risk= a ruinous lawsuit from X. >>=20 >> 3. Do not implement WebRTC, and risk a ruinous loss of relevance. >=20 >=20 > I don't see the risk of 1. having changed because of the IETF's > statement. Plenty of small companies are already doing 1. and have had > to risk getting sued by Nokia at this point in time already. In fact, > it's a risk that small companies always have to deal with since there > is so much patented technology around that you invariable will step on > something. I doubt very much that the IETF's decision has any impact > on small business' risk in that space at all. >=20 >=20 >> I do not think that the IETF should be placing anyone into the position o= f having three extremely unpalatable choices. >=20 > For a small company in the WebRTC space, 3. is a non-choice. 2. Is > more of a business decision than an IP decision - which market are you > trying to address? Are you trying to be interoperable with (current) > browsers - then implement VP8. Are you trying to be interoperable with > legacy devices - then implement H.264 (and probably even H.263). >=20 > If you are trying to argue for a large company, the situation changes. > However, as a large company, you tend to have an existing portfolio of > patents. You're already playing the game of patents. As long as your > hypothetical "IPR owners to grant a license only to =E2=80=98conforming > implementations=E2=80=99" doesn't happen, you are free to choose 2. and av= oid > Nokia. >=20 > As for the threat in your option 2. - I can only see Google with IPR > around VP8. Now, Google's IPR statement on WebM codecs, which includes > VP8 and VP9 currently states: "Google hereby grants to you a > perpetual, worldwide, non-exclusive, no-charge, royalty-free, > irrevocable (except as stated in this section) patent license" > http://www.webmproject.org/license/additional/ > The word "perpetual" implies (to my non-lawyer eyes) that they can't > suddenly change this to mean "only if you are conformant to the > standard". So you can't be referring to such a risk associated with > VP8 being created by Google. I don't know which other company you > would want to be afraid of for your hypothetical threat in 2. Could > you clarify? >=20 >=20 > Best Regards, > Silvia. >=20 >=20 >> (Yes, I am aware that #2 is =E2=80=98unlikely=E2=80=99, but one day someo= ne will decide that the =E2=80=9Conly to conformant implementations=E2=80=9D= clause needs to be real and enforced, and will do this; our hypothetical sm= all company might prefer not to be the example case.) >>=20 >> (I use a small company as the example, because for them the risk is bankr= uptcy, but of course no-one likes to step into the path of trouble even if t= hey have the resources to weather it.) >>=20 >> Dave Singer >>=20 >> singer@mac.com >>=20 >> David Singer >> Manager, Software Standards, Apple Inc. >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Dec 3 18:13:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6FB1A87BB for ; Wed, 3 Dec 2014 18:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UokhMIeWZtEL for ; Wed, 3 Dec 2014 18:10:49 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7993F1A1A3C for ; Wed, 3 Dec 2014 18:10:49 -0800 (PST) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 03 Dec 2014 21:10:49 -0500 Received: from XCT111CNC.rim.net (10.65.161.211) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.210.2; Wed, 3 Dec 2014 21:10:48 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT111CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 21:10:48 -0500 From: Gaelle Martin-Cocher To: "Timothy B. Terriberry" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) Thread-Index: AQHQDyewEeqVo81nB0ShjNtLfXarlJx+j7gAgAAgMwD//7RIMIAAge4A///FiXA= Date: Thu, 4 Dec 2014 02:10:47 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF35455C@XMB111CNC.rim.net> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F60A8.3080302@alvestrand.no> <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com> <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net> <547FA924.3000504@mozilla.com> In-Reply-To: <547FA924.3000504@mozilla.com> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tWmKNjI0RX0Rz0YWu18xb-eTX9k Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 02:10:52 -0000 There was a single hum for the three categories (browser, non-browser, comp= atible endpoints), right? That makes a lot of sense for non-browser entities that are in fact WebRTC-= compatible enpoints (apps, or gateways or else) to push the burden on the b= rowser vendors as those entities will need to interact with browsers. Henc= e "hum"... I think it would make a lot of sense to have different "hums" or questions = for the two different categories. That will bring clarity on what the "non-browser" yet WebRTC endpoint is, v= ersus what the WebRTC-compatible endpoint is (let aside gateways). It is not clear to me that we would have had the same results for each cate= gory if there was two (or three) different questions. Ga=EBlle -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Timothy B. Terri= berry Sent: Wednesday, December 03, 2014 7:22 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, st= ill, sorry) Gaelle Martin-Cocher wrote: > a) How can the group composed by a vast majority of non-browser vendors f= orce a decision on browser vendors against their statements? > > b)I don't think there was enough discussion on "non-browser" entities. I = believe the two topics (browser/non-browser) should have been separated. Th= ere was quite a few objections on a non-browser having to implement both co= decs, at the meeting and on the list prior to the meeting. Let me see if I can follow the logic here. There was a "vast majority of no= n-browser vendors" making this decision, but the overwhelming consensus ach= ieved in the hum in Honolulu does not demonstrate that objections from non-= browser vendors are "in the rough". _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Dec 3 18:23:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6DB1A7032 for ; Wed, 3 Dec 2014 18:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHKHj8gZBlrH for ; Wed, 3 Dec 2014 18:20:48 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B631A1AEB for ; Wed, 3 Dec 2014 18:20:48 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id rl12so15041050iec.19 for ; Wed, 03 Dec 2014 18:20:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jj7cofB4Ml4DmkUfoCMMLtNP4tJUBGugfnfruFseDzQ=; b=N71CfYqPImeDz7ltn3SENwSJOQyLyyiFGVj4gQXFkciCoQYjUS0KWg2QS1PhbMlQbZ kGf+TzVkUJvBrLYmxcjOQWlO693cj5tHLaFZDiAyKwsvAGnzozRslk/TlA7xT+nG2Otg Okd3AjYIkJkWS1Rv7DVn62vf+E3pkWHhKGgrZq1UA+ppEhPSKPTCcAfeqxy5dds2Qpes zUugykR8CBmaFG0zKCyHf6zgbOqWZ92AuO0qPpriMZPBM/aLJkHEck5HHebUaIGGYLxh 10IgpoxGSKDHIxnxCdXs0C7lGxXflBIQVDWruwlr1mGTpbICshRkA8PKIcwKfDYy/aN/ qYxw== X-Gm-Message-State: ALoCoQklvfawMpo/sJ8wIlVFqnUYx0qdNWiM2B/+04rwMQa0h/OKify1owOV9tjf5quiUjaOQ8ln X-Received: by 10.50.98.101 with SMTP id eh5mr60846082igb.31.1417659647878; Wed, 03 Dec 2014 18:20:47 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id l14sm13695331ioi.31.2014.12.03.18.20.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 18:20:47 -0800 (PST) Message-ID: <547FC4FD.2050300@andyet.net> Date: Wed, 03 Dec 2014 19:20:45 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adam Roach , "rtcweb@ietf.org" References: <547511DB.5050100@nostrum.com> In-Reply-To: <547511DB.5050100@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JX1GwCNTMQvtYZjhnsZK-zWZnFg Cc: Harald Alvestrand Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 02:20:52 -0000 On 11/25/14, 4:33 PM, Adam Roach wrote: > I've updated the draft-ietf-rtcweb-video based on the minutes from > Hawaii. Now that we have a clear path to success, I'd like to get the > document finalized and published as quickly as possible. This means I > need your feedback on the remaining open issues (1, 4, and 5, below). If > you are CCed on this mail, it's because you took an action item in > Hawaii, and I'm waiting to hear back from you. > > New version: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ > Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-video-03.txt I have concerns about the future-oriented text: To promote the use of non-royalty bearing video codecs, participants in the RTCWEB working group, and any successor working groups in the IETF, intend to monitor the evolving licensing landscape as it pertains to the two mandatory-to- implement codecs. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, the working group plans to revisit the question of which codecs are required for Non-Browsers, with the intention being that the royalty-free codec will remain mandatory to implement, and the other will become optional. The if-clause in the last sentence establishes a trigger for revisiting the combination of VP8 and H.264 as MTI video codecs. But is that the only possible trigger? If so, I think the document is misguided. The ideal solution to the video codec problem would be for the IETF community to create a truly unencumbered video codec, as it has already done for audio with the Opus codec. If the IETF (or some other standards development organization) were to develop such a codec, then I think that would be a sufficient trigger for revisiting the recommendations in this document, no matter what happens with the royalty-free status of VP8 and H.264. I would strongly prefer that the document contain text recognizing that possibility. Furthermore, this text about WebRTC Browsers sends the wrong message, I think: These provisions apply to WebRTC Non-Browsers only. There is no plan to revisit the codecs required for WebRTC Browsers. Certainly there is no active plan at this time to revisit the MTI codec issue (after all, we're still *visiting* the issue for the first time), but that's immaterial to the question of when it might be appropriate to do so. The current text reads as if there are no conditions under which the MTI codec issue would ever be revisited, and that's just wrong. (A smaller but not insignificant issue is that the document talks about "the RTCWEB working group", "any successor working groups in the IETF", and "the working group" interchangeably. Yet can this document establish plans for successor working groups, or even future incarnations of the RTCWEB working group? Any plans related to future efforts will be set by WG consensus or IETF consensus, not for all time by this document.) IMHO we need to either pull out the future-oriented text entirely (which has its own problems) or significantly improve it. I would be happy to propose text for the latter. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Dec 3 18:29:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139BE1A701B for ; Wed, 3 Dec 2014 18:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vo6yM-Aqx8Mc for ; Wed, 3 Dec 2014 18:25:22 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17F81A1AEB for ; Wed, 3 Dec 2014 18:25:21 -0800 (PST) Received: by mail-oi0-f42.google.com with SMTP id v63so11785848oia.29 for ; Wed, 03 Dec 2014 18:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pQ/vtfDYdRi7sSjZKywMoCsTE9DLXDYit1xVCYLPTWo=; b=mU9bIXIAntBuQj7T2vVjeD/89sq9fBEkpSQMKP4WkjFoWUlcnVb2ADBnaXCxU24xKA gw7HzOF62XoBwOInNt2Ss2R29qQam6FEUdSuHCU1OkaSqAqswBkJ2C2SfXc1dgIHtP0f Q2WbBThsI35avl/EOXCc/SK0aGk4L1dJxPl8MJ7wrEBdpoI+9gGTGaub9UJO2IB6L2wW aa3eCtQ8EU0kLxG8i5ag2U7mWjNCJyTLLGzz88ZsebsbrJOjVsAqZfFY2NhukOK3ytlV 0Hxguz3J30iMmRz8lX7PeIr1uinXPeJjfM7Yc9+JXmOflPoLxqNFDYumWoORm0cM+++X O78Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pQ/vtfDYdRi7sSjZKywMoCsTE9DLXDYit1xVCYLPTWo=; b=doifsSG9g4W1rzDIIb0Ifw+FtTZp8xNfSrEcnN6227D0hJDtEDNO4KtA/M5PpeTIZf wl4hejSbTIcQQ5Fgs/xDmD77iM8S8WM5AqeJLgbQfWYIOR1zcfQwps0Bo803A5ARr9GQ BfGIzh/wkluFCJiwwYVPHemwuQvZXWfhiYFS7FSp41kcF0+/DhUecbOa4CoUoKn0Oz/1 3FtTs64yatMEeAigeH21YxhORbEbzhytT6p0wv6KgtaKxIAFPNBzfC8bQB5n5eR9ADQs cTqHO8CbUuClL172tkfQL4VpdX8c2HdIfZeQROZijOjTFw6Rt8OHUbHQwcCXCElFsPS1 uAvw== X-Gm-Message-State: ALoCoQnmClCBT6R76TItblHH1LjUDXXoYuLO6KnwRPFxf1nmzyjekqsT7ssmr37rlABpsaOk3Qwj X-Received: by 10.60.35.132 with SMTP id h4mr5254992oej.12.1417659921032; Wed, 03 Dec 2014 18:25:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.81.40 with HTTP; Wed, 3 Dec 2014 18:25:00 -0800 (PST) In-Reply-To: <57A07A1B-DB2B-429E-BBFC-24500F91EE60@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <57A07A1B-DB2B-429E-BBFC-24500F91EE60@apple.com> From: Justin Uberti Date: Wed, 3 Dec 2014 18:25:00 -0800 Message-ID: To: David Singer Content-Type: multipart/alternative; boundary=089e011847b0018b2505095aac3c Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pWwlRwQrv53TC8FanMLapH-_oMk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 02:25:27 -0000 --089e011847b0018b2505095aac3c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Many companies, of various market capitalizations, are shipping VP8 today, indicating the amount of concern they have for the Nokia declaration. But as I said during the meeting, if you really are concerned about this, we would be happy to give you a VP8 binary of some sort. On Wed, Dec 3, 2014 at 6:08 PM, David Singer wrote: > You're missing something. I am considering a company that has ipr in > *other* aspects of webrtc, that gives a license to that only to conforman= t > implementations. Not the codec. > > What do you do? Defy the Nokia declaration, defy the 'must' and not do vp= 8 > and be non-conformant, or not do webrtc at all? None are good choices. > > Sent from my iPad > > > On Dec 3, 2014, at 5:25 PM, Silvia Pfeiffer > wrote: > > > >> On Thu, Dec 4, 2014 at 5:33 AM, David Singer wrote: > >> As I understand it, the recent face to face meeting decided to draft > the requirement that WebRTC browsers be required to implement both VP8 an= d > H.264, and get feedback on this, on the list. > >> > >> This is some feedback. > >> > >> > >> > >> I=E2=80=99d like to point out that this could easily place companies i= n an > impossible position. > >> > >> Consider: it is not uncommon for IPR owners to grant a license (often > free) only to =E2=80=98conforming implementations=E2=80=99. (A common rat= ionale is that > they want to use their IPR to bring convergence and interoperability to t= he > industry). Let=E2=80=99s hypothesize that this happens, now or in future= , from > Company X, for some IPR in the WebRTC specifications. > >> > >> Consider also: we have an =E2=80=9Cunwilling to license=E2=80=9D state= ment from Nokia > on VP8, on the formal record (and including a long list of patents). > >> > >> Consider finally: a small company for whom WebRTC is important. > >> > >> > >> > >> Let=E2=80=99s look at the choices: > >> > >> 1. Follow the mandate, implement VP8, and risk a ruinous lawsuit from > Nokia. > >> > >> 2. Reject the mandate, do not implement VP8, and be formally therefor= e > not conformant and therefore not in receipt of a license from company X; > risk a ruinous lawsuit from X. > >> > >> 3. Do not implement WebRTC, and risk a ruinous loss of relevance. > > > > > > I don't see the risk of 1. having changed because of the IETF's > > statement. Plenty of small companies are already doing 1. and have had > > to risk getting sued by Nokia at this point in time already. In fact, > > it's a risk that small companies always have to deal with since there > > is so much patented technology around that you invariable will step on > > something. I doubt very much that the IETF's decision has any impact > > on small business' risk in that space at all. > > > > > >> I do not think that the IETF should be placing anyone into the positio= n > of having three extremely unpalatable choices. > > > > For a small company in the WebRTC space, 3. is a non-choice. 2. Is > > more of a business decision than an IP decision - which market are you > > trying to address? Are you trying to be interoperable with (current) > > browsers - then implement VP8. Are you trying to be interoperable with > > legacy devices - then implement H.264 (and probably even H.263). > > > > If you are trying to argue for a large company, the situation changes. > > However, as a large company, you tend to have an existing portfolio of > > patents. You're already playing the game of patents. As long as your > > hypothetical "IPR owners to grant a license only to =E2=80=98conforming > > implementations=E2=80=99" doesn't happen, you are free to choose 2. and= avoid > > Nokia. > > > > As for the threat in your option 2. - I can only see Google with IPR > > around VP8. Now, Google's IPR statement on WebM codecs, which includes > > VP8 and VP9 currently states: "Google hereby grants to you a > > perpetual, worldwide, non-exclusive, no-charge, royalty-free, > > irrevocable (except as stated in this section) patent license" > > http://www.webmproject.org/license/additional/ > > The word "perpetual" implies (to my non-lawyer eyes) that they can't > > suddenly change this to mean "only if you are conformant to the > > standard". So you can't be referring to such a risk associated with > > VP8 being created by Google. I don't know which other company you > > would want to be afraid of for your hypothetical threat in 2. Could > > you clarify? > > > > > > Best Regards, > > Silvia. > > > > > >> (Yes, I am aware that #2 is =E2=80=98unlikely=E2=80=99, but one day so= meone will decide > that the =E2=80=9Conly to conformant implementations=E2=80=9D clause need= s to be real and > enforced, and will do this; our hypothetical small company might prefer n= ot > to be the example case.) > >> > >> (I use a small company as the example, because for them the risk is > bankruptcy, but of course no-one likes to step into the path of trouble > even if they have the resources to weather it.) > >> > >> Dave Singer > >> > >> singer@mac.com > >> > >> David Singer > >> Manager, Software Standards, Apple Inc. > >> > >> _______________________________________________ > >> 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 > --089e011847b0018b2505095aac3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Many companies, of various market capitalizations, ar= e shipping VP8 today, indicating the amount of concern they have for the No= kia declaration.

But as I said during the meet= ing, if you really are concerned about this, we would be happy to give you = a VP8 binary of some sort.

On Wed, Dec 3, 2014 at 6:08 PM, David Singer <singer@apple= .com> wrote:
You're mis= sing something. I am considering a company that has ipr in *other* aspects = of webrtc, that gives a license to that only to conformant implementations.= Not the codec.

What do you do? Defy the Nokia declaration, defy the 'must' and not= do vp8 and be non-conformant, or not do webrtc at all? None are good choic= es.

Sent from my iPad

> On Dec 3, 2014, at 5:25 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> = wrote:
>
>> On Thu, Dec 4, 2014 at 5:33 AM, David Singer <singer@apple.com> wrote:
>> As I understand it, the recent face to face meeting decided to dra= ft the requirement that WebRTC browsers be required to implement both VP8 a= nd H.264, and get feedback on this, on the list.
>>
>> This is some feedback.
>>
>>
>>
>> I=E2=80=99d like to point out that this could easily place compani= es in an impossible position.
>>
>> Consider: it is not uncommon for IPR owners to grant a license (of= ten free) only to =E2=80=98conforming implementations=E2=80=99. (A common r= ationale is that they want to use their IPR to bring convergence and intero= perability to the industry).=C2=A0 Let=E2=80=99s hypothesize that this happ= ens, now or in future, from Company X, for some IPR in the WebRTC specifica= tions.
>>
>> Consider also: we have an =E2=80=9Cunwilling to license=E2=80=9D s= tatement from Nokia on VP8, on the formal record (and including a long list= of patents).
>>
>> Consider finally: a small company for whom WebRTC is important. >>
>>
>>
>> Let=E2=80=99s look at the choices:
>>
>> 1.=C2=A0 Follow the mandate, implement VP8, and risk a ruinous law= suit from Nokia.
>>
>> 2.=C2=A0 Reject the mandate, do not implement VP8, and be formally= therefore not conformant and therefore not in receipt of a license from co= mpany X; risk a ruinous lawsuit from X.
>>
>> 3.=C2=A0 Do not implement WebRTC, and risk a ruinous loss of relev= ance.
>
>
> I don't see the risk of 1. having changed because of the IETF'= s
> statement. Plenty of small companies are already doing 1. and have had=
> to risk getting sued by Nokia at this point in time already. In fact,<= br> > it's a risk that small companies always have to deal with since th= ere
> is so much patented technology around that you invariable will step on=
> something. I doubt very much that the IETF's decision has any impa= ct
> on small business' risk in that space at all.
>
>
>> I do not think that the IETF should be placing anyone into the pos= ition of having three extremely unpalatable choices.
>
> For a small company in the WebRTC space, 3. is a non-choice. 2. Is
> more of a business decision than an IP decision - which market are you=
> trying to address? Are you trying to be interoperable with (current) > browsers - then implement VP8. Are you trying to be interoperable with=
> legacy devices - then implement H.264 (and probably even H.263).
>
> If you are trying to argue for a large company, the situation changes.=
> However, as a large company, you tend to have an existing portfolio of=
> patents. You're already playing the game of patents. As long as yo= ur
> hypothetical "IPR owners to grant a license only to =E2=80=98conf= orming
> implementations=E2=80=99" doesn't happen, you are free to cho= ose 2. and avoid
> Nokia.
>
> As for the threat in your option 2. - I can only see Google with IPR > around VP8. Now, Google's IPR statement on WebM codecs, which incl= udes
> VP8 and VP9 currently states: "Google hereby grants to you a
> perpetual, worldwide, non-exclusive, no-charge, royalty-free,
> irrevocable (except as stated in this section) patent license" > http://www.webmproject.org/license/additional/
> The word "perpetual" implies (to my non-lawyer eyes) that th= ey can't
> suddenly change this to mean "only if you are conformant to the > standard". So you can't be referring to such a risk associate= d with
> VP8 being created by Google. I don't know which other company you<= br> > would want to be afraid of for your hypothetical threat in 2. Could > you clarify?
>
>
> Best Regards,
> Silvia.
>
>
>> (Yes, I am aware that #2 is =E2=80=98unlikely=E2=80=99, but one da= y someone will decide that the =E2=80=9Conly to conformant implementations= =E2=80=9D clause needs to be real and enforced, and will do this; our hypot= hetical small company might prefer not to be the example case.)
>>
>> (I use a small company as the example, because for them the risk i= s bankruptcy, but of course no-one likes to step into the path of trouble e= ven if they have the resources to weather it.)
>>
>> Dave Singer
>>
>> singer@mac.com=
>>
>> David Singer
>> Manager, Software Standards, Apple Inc.
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--089e011847b0018b2505095aac3c-- From nobody Wed Dec 3 19:25:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A571E1A002F for ; Wed, 3 Dec 2014 19:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxOpolo3pJcg for ; Wed, 3 Dec 2014 19:22:41 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8C81A000D for ; Wed, 3 Dec 2014 19:22:41 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id y10so16707110pdj.6 for ; Wed, 03 Dec 2014 19:22:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z5/Of2iW1K7NMO4sVdf9LDwRSDBGp5jQOrFaaCSvDU0=; b=JOnMv8Z3uJE3Femcaixfc8EjPRSXDmX5DtFTbR7fDGsjfNIKPP4oFgzu1Jr4Vfl4y4 okvtaaW7yKKpm8YJOnfvKdNbv1vCtlYFy5yagkvnXS34yf+AhuH+I8z4VtaQfBvmc5de Lzh3zRaTtV3y5JfczxkTRu4s1l+xGFi8WlbwiX5KfHycOVmjIzYya/v94FY9xmUVk6CC vpD2TN38Hb6SiNzT1CY6Qk9IIngzq3RnNaQfSGDFnx4cvGlaY2s80ecJRqV29u+VtMU/ acRpWQ8OmHXZA/W9oNF4b8B1/NtBHkHOVwdlBqhNTkGZOf/cAo7xNaQ79JB6KD8qLnDz jHNw== X-Received: by 10.68.190.229 with SMTP id gt5mr21294342pbc.119.1417663360894; Wed, 03 Dec 2014 19:22:40 -0800 (PST) Received: from [10.239.43.196] ([216.133.128.238]) by mx.google.com with ESMTPSA id ny9sm24537382pab.25.2014.12.03.19.22.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 19:22:39 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12B435) In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net> Date: Wed, 3 Dec 2014 19:22:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <70F7E827-EA9F-427D-8EDE-2FB9ADC93752@gmail.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F60A8.3080302@alvestrand.no> <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com> <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net> To: Gaelle Martin-Cocher Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gkP1GHqGPymTJqPx_MUg_3aOZRc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 03:22:43 -0000 On Dec 3, 2014, at 3:32 PM, Gaelle Martin-Cocher wrote: >=20 > a) How can the group composed by a vast majority of non-browser vendors fo= rce a decision on browser vendors against their statements?=20 [BA] The basic gist is "don't dual MTI him, don't dual MTI me, dual MTI the= fellow behind the tree". No mobile application or device maker will pay at= tention to the dual MTI requirement, nor should they - it adds overhead and p= otential liability/fees with little benefit. For codec implementers, the ti= ming couldn't be worse - with next generation codecs now appearing in produc= ts (e.g. H.265 and VP9), making an argument for diverting resources away int= o work on previous generation codecs is difficult at best. There is a difference between suggesting a compromise that many people disli= ke but can live with versus one that is only palatable if it applies to some= one else.=20 From nobody Wed Dec 3 20:38:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549081A0053 for ; Wed, 3 Dec 2014 20:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJdLB2RFe9Ap for ; Wed, 3 Dec 2014 20:34:29 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828CF1A0047 for ; Wed, 3 Dec 2014 20:34:28 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-87-547fe452aa49 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 84.12.04231.254EF745; Thu, 4 Dec 2014 05:34:26 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 05:34:26 +0100 From: Christer Holmberg To: =?utf-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= , Justin Uberti Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAHfyaaU Date: Thu, 4 Dec 2014 04:34:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D577322@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> , <1447FA0C20ED5147A1AA0EF02890A64B1D0EE2BC@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0EE2BC@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D577322ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGfG3RjfoSX2Iwc45qhZbpwpZNGy8wmox 48JUZou1/9rZHVg8Wp/tZfVYsKnUY8mSn0wet6YUBLBEcdmkpOZklqUW6dslcGVc7P7DUvDt ImPFlA8zWBsYN5xh7GLk5JAQMJHYt7aRDcIWk7hwbz2QzcUhJHCEUeL541lQzmJGiZlLWpm7 GDk42AQsJLr/aYM0iAiUShxY9IkVxGYWmMgo8XCGB4gtLGAq8X7uEWaIGjOJhScnMELYRhKL /v4DG8MioCJx/H4WSJhXwFfizPctLBCrLnNKTJl5CWwmp4CfRN/BXnYQmxHouO+n1jBB7BKX aPqykhXiaAGJJXvOM0PYohIvH/+Duidf4sDL64wQCwQlTs58wjKBUWQWkvZZSMpmISmbBXQe s4CmxPpd+hAlihJTuh+yQ9gaEq1z5rIjiy9gZF/FKFqcWlycm25krJdalJlcXJyfp5eXWrKJ ERh7B7f81t3BuPq14yFGAQ5GJR5eg3P1IUKsiWXFlbmHGKU5WJTEeRedmxcsJJCeWJKanZpa kFoUX1Sak1p8iJGJg1OqgdEhIjorhFE0pqnv3QqXlAtnY9sics6a/n1qr/yhXbGv9d3xg9Uz nNbsrjkzK21b17tDKRni/9xmLo6ItlmRGaDwTWKydK3nDqvlMhP55tndLlmaVTNtXRPv2Q83 DL9mP2P5XZjL82+/1f/dBWX1mWv3t/YWTElinqN539mF1WYyZwC37KL4VCWW4oxEQy3mouJE ADiEUVmeAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Zfm1MJJaLasgctshxni_jk722So Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 04:34:33 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D577322ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCklzc3VlICM3MiB0YWxrcyBhYm91dCBtYWludGFpbmluZyB0aGUgcHJldmlvdXNseSBu ZWdvdGlhdGVkIHJvbGUgd2hlbiBhY3RwYXNzIGlzIHJlY2VpdmVkLiBJIHRoaW5rIHRoYXQgaXMg YSBnb29kIGFwcHJvYWNoLCBhbmQgY291bGQgYmUgdXNlZCBpbiBPZmZlci9BbnN3ZXIgdG9vLg0K DQpCVVQsIHdoYXQgZG9lcyB0aGUgYnJvd3NlciBkbyBpZiBlLmcuIHRoZSBwcmV2aW91cyByb2xl IGlzIHBhc3NpdmUgYW5kIGFjdGl2ZSBpcyByZWNlaXZlZD8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmUNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpGcm9tOiBTdGVmYW4gSMOla2Fuc3NvbiBMSzxtYWlsdG86c3RlZmFuLmxrLmhh a2Fuc3NvbkBlcmljc3Nvbi5jb20+DQpTZW50OiDigI4wMy/igI4xMi/igI4yMDE0IDE3OjQ4DQpU bzogSnVzdGluIFViZXJ0aTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPg0KQ2M6IE1ha2FyYWp1 LCBNYXJpZGkgUmFqdSAoUmFqdSk8bWFpbHRvOlJhanUuTWFrYXJhanVAYWxjYXRlbC1sdWNlbnQu Y29tPjsgQ2hyaXN0ZXIgSG9sbWJlcmc8bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbT47IFJvbWFuIFNocG91bnQ8bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPjsgcnRjd2ViQGll dGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gSlNF UDogV2h5IGFsd2F5cyBvZmZlciBhY3RwYXNzPw0KDQpPbiAwMS8xMi8xNCAxODoyNiwgSnVzdGlu IFViZXJ0aSB3cm90ZToNCj4NCj4NCj4gT24gU3VuLCBOb3YgMzAsIDIwMTQgYXQgNzoyNiBBTSwg U3RlZmFuIEjDpWthbnNzb24gTEsNCj4gPHN0ZWZhbi5say5oYWthbnNzb25AZXJpY3Nzb24uY29t DQo+IDxtYWlsdG86c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5jb20+PiB3cm90ZToNCj4N Cj4gICAgIE9uIDMwLzExLzE0IDE2OjA2LCBNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUpIHdy b3RlOg0KPiAgICAgID4+IE9uIDMwLzExLzE0IDE0OjUxLCBNYWthcmFqdSwgTWFyaWRpIFJhanUg KFJhanUpIHdyb3RlOg0KPiAgICAgID4+Pj4gSGksDQo+ICAgICAgPj4+Pg0KPiAgICAgID4+Pj4+ PiBSRkMgNzM0NSAoVURQVEwtRFRMUykgc2F5cyB0aGUgZm9sbG93aW5nOg0KPiAgICAgID4+Pj4+ Pg0KPiAgICAgID4+Pj4+PiAiT25jZSBhbiBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UgaGFzIGJlZW4g Y29tcGxldGVkLCBlaXRoZXINCj4gICAgICA+Pj4+Pj4gZW5kcG9pbnQNCj4gICAgICA+Pj4+IE1B WQ0KPiAgICAgID4+Pj4+PiBzZW5kIGEgbmV3IG9mZmVyIGluIG9yZGVyIHRvIG1vZGlmeSB0aGUg c2Vzc2lvbi4gIFRoZQ0KPiAgICAgID4+Pj4+PiBlbmRwb2ludHMNCj4gICAgICA+Pj4+IGNhbg0K PiAgICAgID4+Pj4+PiByZXVzZSB0aGUgZXhpc3RpbmcgRFRMUyBhc3NvY2lhdGlvbiBpZiB0aGUg a2V5IGZpbmdlcnByaW50DQo+ICAgICAgPj4+Pj4+IHZhbHVlcw0KPiAgICAgID4+Pj4gYW5kDQo+ ICAgICAgPj4+Pj4+IHRyYW5zcG9ydCBwYXJhbWV0ZXJzIGluZGljYXRlZCBieSBlYWNoIGVuZHBv aW50IGFyZSB1bmNoYW5nZWQuDQo+ICAgICAgPj4+Pj4+IE90aGVyd2lzZSwgZm9sbG93aW5nIHRo ZSBydWxlcyBmb3IgdGhlIGluaXRpYWwgb2ZmZXIvYW5zd2VyDQo+ICAgICAgPj4+PiBleGNoYW5n ZSwNCj4gICAgICA+Pj4+Pj4gdGhlIGVuZHBvaW50cyBjYW4gbmVnb3RpYXRlIGFuZCBjcmVhdGUg YSBuZXcgRFRMUyBhc3NvY2lhdGlvbg0KPiAgICAgID4+Pj4+PiBhbmQsIG9uY2UgY3JlYXRlZCwg ZGVsZXRlIHRoZSBwcmV2aW91cyBEVExTIGFzc29jaWF0aW9uLA0KPiAgICAgID4+Pj4+PiBmb2xs b3dpbmcgdGhlIHNhbWUgcnVsZXMgZm9yIHRoZSBpbml0aWFsIG9mZmVyL2Fuc3dlciBleGNoYW5n ZS4NCj4gICAgICA+Pj4+Pj4gRWFjaCBlbmRwb2ludCBuZWVkcyB0byBiZSBwcmVwYXJlZCB0byBy ZWNlaXZlIGRhdGEgb24gYm90aCB0aGUNCj4gICAgICA+Pj4+Pj4gbmV3IGFuZCBvbGQgRFRMUyBh c3NvY2lhdGlvbnMgYXMgbG9uZyBhcyBib3RoIGFyZSBhbGl2ZS4iDQo+ICAgICAgPj4+Pj4+DQo+ ICAgICAgPj4+Pj4+IFNvLCBJIGd1ZXNzIHRoYXQgY2FuIGJlIHJlYWQgaW4gYSB3YXkgdGhhdCB0 aGUgc2V0dXAgYXR0cmlidXRlDQo+ICAgICAgPj4+Pj4+IGFzIHN1Y2gNCj4gICAgICA+Pj4+IGRv ZXMgbm90IGltcGFjdCBwcmV2aW91c2x5DQo+ICAgICAgPj4+Pj4+IG5lZ290aWF0ZWQgVExTIHJv bGVzIC0gdW5sZXNzIHRoZSBrZXkgZmluZ2VycHJpbnQgdmFsdWVzIGFuZC9vcg0KPiAgICAgID4+ Pj4+PiB0cmFuc3BvcnQNCj4gICAgICA+Pj4+IHBhcmFtZXRlcnMgYXJlIG1vZGlmaWVkLg0KPiAg ICAgID4+Pj4+Pg0KPiAgICAgID4+Pj4+PiBUaGUgU0NUUC1TRFAgZHJhZnQgY3VycmVudGx5IHNh eXMgdGhhdCBhIHN1YnNlcXVlbnQgb2ZmZXIgbXVzdA0KPiAgICAgID4+Pj4+PiBub3QgY2hhbmdl DQo+ICAgICAgPj4+PiB0aGUgcHJldmlvdXNseSBuZWdvdGlhdGVkIHJvbGVzLiBCdXQsIEkgZ3Vl c3MNCj4gICAgICA+Pj4+Pj4gd2UgY291bGQgc2F5IHNvbWV0aGluZyBzaW1pbGFyIGFzIGluIFJG QyA3MzQ1Lg0KPiAgICAgID4+Pj4+DQo+ICAgICAgPj4+Pj4gSSBoYXZlIHN0cnVnZ2xlZCB3aXRo IHRoaXMgbGFuZ3VhZ2UgcXVpdGUgYSBiaXQgZnJvbSB0aGUNCj4gICAgICA+Pj4+PiBpbXBsZW1l bnRhdGlvbg0KPiAgICAgID4+Pj4gcGVyc3BlY3RpdmUuIEkgdGhpbmsgd2UgbmVlZCB0byBleHBs aWNpdGx5IHN0YXRlDQo+ICAgICAgPj4+Pj4gdGhhdCBlbmRwb2ludHMgTVVTVCByZXVzZSB0aGUg ZXhpc3RpbmcgYXNzb2NpYXRpb24gaWYgdGhlIGtleQ0KPiAgICAgID4+Pj4+IGZpbmdlcnByaW50 DQo+ICAgICAgPj4+PiB2YWx1ZXMgYW5kIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIGluZGljYXRlZA0K PiAgICAgID4+Pj4+IGJ5IGVhY2ggZW5kcG9pbnQgYXJlIHVuY2hhbmdlZC4NCj4gICAgICA+Pj4+ DQo+ICAgICAgPj4+PiBXZSBjb3VsZCB0YWtlIHN1Y2ggZ2VuZXJhbCBhcHByb2FjaC4NCj4gICAg ICA+Pj4+DQo+ICAgICAgPj4+PiBIb3dldmVyLCBmb3IgJ1NDVFAvRFRMUycgKERUTFMgb3ZlciBT Q1RQKSwgSSBhc3N1bWUgdGhhdCB0aGUgRFRMUw0KPiAgICAgID4+Pj4gY29ubmVjdGlvbiB3aWxs IGFsc28gYmUgcmUtZXN0YWJsaXNoZWQgaWYgdGhlIHVuZGVybHlpbmcgU0NUUA0KPiAgICAgID4+ Pj4gYXNzb2NpYXRpb24gaXMgcmUtIGVzdGFibGlzaGVkIC0gZXZlbiBpZiBubyB0cmFuc3BvcnQg cGFyYW1ldGVycw0KPiAgICAgID4+Pj4gZXRjIGFyZSBjaGFuZ2VkLg0KPiAgICAgID4+Pj4NCj4g ICAgICA+Pj4+IEFsc28sIFJGQyA2MDgzIHNheXM6DQo+ICAgICAgPj4+Pg0KPiAgICAgID4+Pj4g IkVhY2ggRFRMUyBjb25uZWN0aW9uIE1VU1QgYmUgZXN0YWJsaXNoZWQgYW5kIHRlcm1pbmF0ZWQN Cj4gICAgIHdpdGhpbiB0aGUNCj4gICAgICA+Pj4+IHNhbWUgU0NUUCBhc3NvY2lhdGlvbi4iDQo+ ICAgICAgPj4+Pg0KPiAgICAgID4+Pj4NCj4gICAgICA+Pj4+PiBUaGUgd2F5IHRoaXMgbGFuZ3Vh Z2UgcmVhZHMgdG8gbWUgaXMgdGhhdCBlbmRwb2ludHMgY2FuIHJldXNlIHRoZQ0KPiAgICAgID4+ Pj4+IGV4aXN0aW5nDQo+ICAgICAgPj4+PiBhc3NvY2lhdGlvbiBpZiB0aGV5IHdhbnQgdG8sIGJ1 dCB0aGV5IGNhbiBjcmVhdGUgYSBuZXcgb25lIGlmIHRoZXkNCj4gICAgICA+Pj4+IGRvbid0LiBB bHNvLCB3aGVuIHRoaXMgbmV3DQo+ICAgICAgPj4+Pj4gYXNzb2NpYXRpb24gaXMgY3JlYXRlZCwg aXQgaXMgdW5jbGVhciBpZiBvbGQgc2V0dXAgcm9sZXMgTVVTVCBiZQ0KPiAgICAgID4+Pj4+IHBy ZXNlcnZlZA0KPiAgICAgID4+Pj4gb3IgaWYgdGhleSBNVVNUIGJlIHNlbGVjdGVkIGJhc2VkIG9u IHRoZSBjdXJyZW50IG9mZmVyL2Fuc3dlcg0KPiAgICAgID4+Pj4gZXhjaGFuZ2UuIEl0IHNlZW1z IHRoZSBjdXJyZW50DQo+ICAgICAgPj4+Pj4gc3BlY2lmaWNhdGlvbiBsYW5ndWFnZSBpcyBub3Qg c3Ryb25nIG9yIGNsZWFyIGVub3VnaCBvbiB0aGlzDQo+ICAgICAgPj4+Pj4gdG9waWMuDQo+ICAg ICAgPj4+Pg0KPiAgICAgID4+Pj4gSW4gbXkgb3BpbmlvbiwgSUYgYSBuZXcgRFRMUyBjb25uZWN0 aW9uIG5lZWRzIHRvIGJlIGVzdGFibGlzaGVkDQo+ICAgICAgPj4+PiAoZm9yIHdoYXRldmVyIHJl YXNvbnMpLCB0aGUgY3VycmVudCByb2xlcyBzaG91bGQgYmUgdXNlZC4NCj4gICAgICA+Pj4NCj4g ICAgICA+Pj4gPFJhanU+IFdoZW4gSUNFIGlzIE5PVCB1c2VkLCBob3cgZG9lcyB0aGUgb2ZmZXJl ciBrbm93IHRoYXQgdGhlDQo+ICAgICAgPj4+IGFuc3dlcmVyIGRvZXMgbm90IGNoYW5nZSB0aGUg ZmluZ2VycHJpbnQgYW5kL29yIHRyYW5zcG9ydA0KPiAgICAgcGFyYW1ldGVycz8NCj4gICAgICA+ Pj4gSSBndWVzcyBpdCBkb2VzIG5vdCBrbm93LiBTbywgb2ZmZXJlciBoYXMgdG8gYmUgcHJlcGFy ZWQgZm9yDQo+ICAgICBuZXcgRFRMUw0KPiAgICAgID4+PiBhc3NvY2lhdGlvbiBieSBvZmZlcmlu ZyBhY3RwYXNzLiBXaGVuIElDRSBpcyB1c2VkLCB0aGUgYW5zd2VyZXINCj4gICAgIGNhbid0DQo+ ICAgICAgPj4+IGNoYW5nZSB0cmFuc3BvcnQgcGFyYW1ldGVyIHVubGVzcyBvZmZlcmVyIGRvZXMg SUNFIHJlc3RhcnQgKHdoaWNoDQo+ICAgICAgPj4+IGNoYW5nZXMgb2ZmZXJlciB0cmFuc3BvcnQg cGFyYW1ldGVycyk7IFJlZiBbMV0gaXMgdmVyeSBjbGVhciBvbg0KPiAgICAgdGhpcw0KPiAgICAg ID4+PiBpbmRpY2F0aW5nICJEVExTIGhhbmRzaGFrZSBwcm9jZWR1cmUgaXMgcmVwZWF0ZWQiLiBI b3dldmVyLA0KPiAgICAgZXZlbiB3aGVuDQo+ICAgICAgPj4+IElDRSBpcyB1c2VkLCBJIGRvIG5v dCBmaW5kIGFueSByZXN0cmljdGlvbiBhYm91dCBhbnN3ZXJlciBub3QNCj4gICAgICA+Pj4gY2hh bmdpbmcgZmluZ2VycHJpbnQuIFNvLCBldmVuIHdpdGhvdXQgSUNFIHJlc3RhcnQgYW5zd2VyZXIg Y2FuDQo+ICAgICAgPj4+IHRyaWdnZXIgYSBEVExTIHJlbmVnb3RpYXRpb24gYnkgY2hhbmdpbmcg aXRzIGZpbmdlcnByaW50Lg0KPiAgICAgID4+Pg0KPiAgICAgID4+PiBUbyBjb25jbHVkZSBhbGwg dGhpcywgSU1PIHdoZXRoZXIgSUNFIGlzIHVzZWQgb3Igbm90LCBzZW5kaW5nDQo+ICAgICBhY3Rw YXNzDQo+ICAgICAgPj4+IGZvciBhbGwgbmV3IG9mZmVycyBtYXkgYmUgY292ZXIgYWxsIHBvc3Np YmxlIHNjZW5hcmlvcy4NCj4gICAgICA+Pg0KPiAgICAgID4+IFRoYXQgaXMgYWxzbyBteSBjb25j bHVzaW9uIGJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uIHNvIGZhci4NCj4gICAgICA+Pg0KPiAgICAg ID4+IEkgYWxzbyB0aGluayB0aGUgSlNFUCBkcmFmdCBhcyBmYXIgYXMgZGV0YWlsZWQgb3V0IGlz IGNvcnJlY3QsDQo+ICAgICBidXQgaW5mbw0KPiAgICAgID4+IGFib3V0IGhvdyB0aGUgaW1wbGVt ZW50YXRpb24gc2hvdWxkIGJlaGF2ZSBmb3IgU3Vic2VxdWVudCBhbnN3ZXJzIGlzDQo+ICAgICAg Pj4gbWlzc2luZy4gVGV4dCBzYXlpbmcgdGhhdCB0aGUgcm9sZSBtdXN0IGJlIG1haW50YWluZWQg KHVubGVzcw0KPiAgICAgdGhlcmUgaXMNCj4gICAgICA+PiBhbiBJQ0UgcmVzdGFydCkgc2hvdWxk IGJlIHB1dCBpbiB0aGVyZS4NCj4gICAgICA+DQo+ICAgICAgPiA8UmFqdT4NCj4gICAgICA+IEhp IFN0ZWZhbiwNCj4gICAgICA+IExvb2tzIGxpa2UsIHRoZXJlIGlzIHNvbWUgbWlzdW5kZXJzdGFu ZGluZyBoZXJlLg0KPg0KPiAgICAgUHJvYmFibHkgbXkgZmF1bHQgaW4gdGhhdCBjYXNlIDopDQo+ DQo+ICAgICA+IE15IGNvbmNsdXNpb24gaXMgdG8gaW5jbHVkZQ0KPiAgICAgPiBhY3RwYXNzLCBi dXQgbm90IHRoZSBwcmV2aW91c2x5IG5lZ290aWF0ZWQgcm9sZSwgaW4gYWxsIHN1YnNlcXVlbnQg b2ZmZXJzLA0KPiAgICAgPiBub3QganVzdCBkdXJpbmcgSUNFLXJlc3RhcnRzLg0KPg0KPiAgICAg SSB0aGluayB0aGF0IGlzIHdoYXQgdGhlIEpTRVAgZHJhZnQgc2F5cyAtIGFuZCBteSBjb25jbHVz aW9uIGlzIHRoYXQgaXQNCj4gICAgIF9pc18gY29ycmVjdC4NCj4NCj4gICAgIE15IHBvaW50IHdh cyB0aGF0IHRoZSBfYW5zd2VyXyBzaG91bGQgKHdoZW4gaXQgaXMgYSBzdWJzZXF1ZW50IGFuc3dl cikNCj4gICAgIHNob3VsZCBzYXkgdGhlIHNhbWUgcm9sZSBhcyBpbiBwcmV2aW91cyBhbnN3ZXJz ICh1bmxlc3MgdGhlcmUgaXMgYW4gSUNFDQo+ICAgICByZXN0YXJ0KS4NCj4NCj4gSSBhZ3JlZSB0 aGUgSlNFUCB0ZXh0IHNob3VsZCBpbmRpY2F0ZSB0aGF0IHJvbGVzIHNob3VsZCBzdGF5IHRoZSBz YW1lLg0KPiBXZSBoYXZlIGhhZCB0aGlzIGFzIGEgVE9ETyBmb3IgYSB3aGlsZToNCj4gaHR0cHM6 Ly9naXRodWIuY29tL3J0Y3dlYi13Zy9qc2VwL2lzc3Vlcy83Mg0KDQpHcmVhdC4gSSBzaG91bGQg aGF2ZSBjaGVja2VkIHRoYXQgb3V0IGJlZm9yZS4NCg0K --_000_7594FB04B1934943A5C02806D1A2204B1D577322ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+SGksPGJyPg0KPGJyPg0KSXNzdWUgIzcy IHRhbGtzIGFib3V0IG1haW50YWluaW5nIHRoZSBwcmV2aW91c2x5IG5lZ290aWF0ZWQgcm9sZSB3 aGVuIGFjdHBhc3MgaXMgcmVjZWl2ZWQuIEkgdGhpbmsgdGhhdCBpcyBhIGdvb2QgYXBwcm9hY2gs IGFuZCBjb3VsZCBiZSB1c2VkIGluIE9mZmVyL0Fuc3dlciB0b28uPGJyPg0KPGJyPg0KQlVULCB3 aGF0IGRvZXMgdGhlIGJyb3dzZXIgZG8gaWYgZS5nLiB0aGUgcHJldmlvdXMgcm9sZSBpcyBwYXNz aXZlIGFuZCBhY3RpdmUgaXMgcmVjZWl2ZWQ/PGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+ DQpDaHJpc3Rlcjxicj4NCjxicj4NClNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lPC9kaXY+DQo8 L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGhyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPkZyb206 DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9u dC1zaXplOjExcHQiPjxhIGhyZWY9Im1haWx0bzpzdGVmYW4ubGsuaGFrYW5zc29uQGVyaWNzc29u LmNvbSI+U3RlZmFuIEjDpWthbnNzb24gTEs8L2E+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdo dDpib2xkIj5TZW50Og0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNh bnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij7igI4wMy/igI4xMi/igI4yMDE0IDE3OjQ4PC9zcGFu Pjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQt c2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5UbzoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFp bHRvOmp1YmVydGlAZ29vZ2xlLmNvbSI+SnVzdGluIFViZXJ0aTwvYT48L3NwYW4+PGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7 IGZvbnQtd2VpZ2h0OmJvbGQiPkNjOg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD YWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij48YSBocmVmPSJtYWlsdG86UmFqdS5N YWthcmFqdUBhbGNhdGVsLWx1Y2VudC5jb20iPk1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSk8 L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Q2hy aXN0ZXIgSG9sbWJlcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iPg0K Um9tYW4gU2hwb3VudDwvYT47IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dl YkBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6 DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9u dC1zaXplOjExcHQiPlJlOiBbcnRjd2ViXSBKU0VQOiBXaHkgYWx3YXlzIG9mZmVyIGFjdHBhc3M/ PC9zcGFuPjxicj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8Zm9udCBzaXplPSIyIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwcHQ7Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+T24gMDEvMTIv MTQgMTg6MjYsIEp1c3RpbiBVYmVydGkgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7IE9uIFN1biwgTm92IDMwLCAyMDE0IGF0IDc6MjYgQU0sIFN0ZWZhbiBIw6VrYW5zc29uIExL PGJyPg0KJmd0OyAmbHQ7c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5jb208YnI+DQomZ3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5jb20iPm1h aWx0bzpzdGVmYW4ubGsuaGFrYW5zc29uQGVyaWNzc29uLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8 YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPbiAzMC8xMS8xNCAx NjowNiwgTWFrYXJhanUsIE1hcmlkaSBSYWp1IChSYWp1KSB3cm90ZTo8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IE9uIDMwLzExLzE0IDE0OjUxLCBNYWth cmFqdSwgTWFyaWRpIFJhanUgKFJhanUpIHdyb3RlOjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBIaSw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSRkMgNzM0NSAoVURQ VEwtRFRMUykgc2F5cyB0aGUgZm9sbG93aW5nOjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7T25jZSBh biBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UgaGFzIGJlZW4gY29tcGxldGVkLCBlaXRoZXI8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBlbmRwb2ludDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyBNQVk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZW5kIGEgbmV3IG9mZmVyIGluIG9yZGVyIHRvIG1vZGlm eSB0aGUgc2Vzc2lvbi4mbmJzcDsgVGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZW5kcG9pbnRzPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IGNhbjxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJl dXNlIHRoZSBleGlzdGluZyBEVExTIGFzc29jaWF0aW9uIGlmIHRoZSBrZXkgZmluZ2VycHJpbnQ8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyB2YWx1ZXM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsgYW5kPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHJhbnNwb3J0IHBhcmFtZXRlcnMgaW5kaWNhdGVk IGJ5IGVhY2ggZW5kcG9pbnQgYXJlIHVuY2hhbmdlZC48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPdGhlcndpc2UsIGZvbGxv d2luZyB0aGUgcnVsZXMgZm9yIHRoZSBpbml0aWFsIG9mZmVyL2Fuc3dlcjxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBleGNoYW5nZSw8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyB0aGUgZW5kcG9pbnRzIGNhbiBuZWdvdGlhdGUgYW5kIGNyZWF0ZSBhIG5ldyBEVExTIGFz c29jaWF0aW9uPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgYW5kLCBvbmNlIGNyZWF0ZWQsIGRlbGV0ZSB0aGUgcHJldmlvdXMg RFRMUyBhc3NvY2lhdGlvbiw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb2xsb3dpbmcgdGhlIHNhbWUgcnVsZXMgZm9yIHRo ZSBpbml0aWFsIG9mZmVyL2Fuc3dlciBleGNoYW5nZS48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBFYWNoIGVuZHBvaW50IG5l ZWRzIHRvIGJlIHByZXBhcmVkIHRvIHJlY2VpdmUgZGF0YSBvbiBib3RoIHRoZTxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5l dyBhbmQgb2xkIERUTFMgYXNzb2NpYXRpb25zIGFzIGxvbmcgYXMgYm90aCBhcmUgYWxpdmUuJnF1 b3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTbywgSSBndWVzcyB0aGF0IGNhbiBiZSByZWFkIGluIGEgd2F5 IHRoYXQgdGhlIHNldHVwIGF0dHJpYnV0ZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFzIHN1Y2g8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgZG9lcyBub3QgaW1wYWN0 IHByZXZpb3VzbHk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZWdvdGlhdGVkIFRMUyByb2xlcyAtIHVubGVzcyB0aGUga2V5 IGZpbmdlcnByaW50IHZhbHVlcyBhbmQvb3I8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0cmFuc3BvcnQ8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgcGFyYW1ldGVycyBh cmUgbW9kaWZpZWQuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgU0NUUC1TRFAgZHJhZnQgY3VycmVudGx5 IHNheXMgdGhhdCBhIHN1YnNlcXVlbnQgb2ZmZXIgbXVzdDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5vdCBjaGFuZ2U8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgdGhl IHByZXZpb3VzbHkgbmVnb3RpYXRlZCByb2xlcy4gQnV0LCBJIGd1ZXNzPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2UgY291 bGQgc2F5IHNvbWV0aGluZyBzaW1pbGFyIGFzIGluIFJGQyA3MzQ1Ljxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgaGF2ZSBz dHJ1Z2dsZWQgd2l0aCB0aGlzIGxhbmd1YWdlIHF1aXRlIGEgYml0IGZyb20gdGhlPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbXBs ZW1lbnRhdGlvbjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyBwZXJzcGVjdGl2ZS4gSSB0aGluayB3ZSBuZWVkIHRvIGV4cGxpY2l0bHkgc3Rh dGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHRoYXQgZW5kcG9pbnRzIE1VU1QgcmV1c2UgdGhlIGV4aXN0aW5nIGFzc29jaWF0aW9u IGlmIHRoZSBrZXk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGZpbmdlcnByaW50PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IHZhbHVlcyBhbmQgdHJhbnNwb3J0IHBhcmFtZXRl cnMgaW5kaWNhdGVkPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBieSBlYWNoIGVuZHBvaW50IGFyZSB1bmNoYW5nZWQuPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IFdlIGNvdWxk IHRha2Ugc3VjaCBnZW5lcmFsIGFwcHJvYWNoLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBIb3dldmVyLCBmb3IgJ1NDVFAvRFRMUycgKERU TFMgb3ZlciBTQ1RQKSwgSSBhc3N1bWUgdGhhdCB0aGUgRFRMUzxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBjb25uZWN0aW9uIHdpbGwgYWxz byBiZSByZS1lc3RhYmxpc2hlZCBpZiB0aGUgdW5kZXJseWluZyBTQ1RQPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFzc29jaWF0aW9uIGlz IHJlLSBlc3RhYmxpc2hlZCAtIGV2ZW4gaWYgbm8gdHJhbnNwb3J0IHBhcmFtZXRlcnM8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgZXRjIGFy ZSBjaGFuZ2VkLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyBBbHNvLCBSRkMgNjA4MyBzYXlzOjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyAmcXVvdDtFYWNoIERUTFMgY29ubmVjdGlv biBNVVNUIGJlIGVzdGFibGlzaGVkIGFuZCB0ZXJtaW5hdGVkPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB3aXRoaW4gdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IHNhbWUgU0NUUCBhc3NvY2lhdGlvbi4mcXVvdDs8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFRoZSB3YXkgdGhpcyBsYW5ndWFnZSByZWFkcyB0byBtZSBpcyB0aGF0IGVuZHBvaW50cyBjYW4g cmV1c2UgdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBleGlzdGluZzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBhc3NvY2lhdGlvbiBpZiB0aGV5IHdhbnQgdG8sIGJ1dCB0 aGV5IGNhbiBjcmVhdGUgYSBuZXcgb25lIGlmIHRoZXk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgZG9uJ3QuIEFsc28sIHdoZW4gdGhpcyBu ZXc8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGFzc29jaWF0aW9uIGlzIGNyZWF0ZWQsIGl0IGlzIHVuY2xlYXIgaWYgb2xkIHNldHVw IHJvbGVzIE1VU1QgYmU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHByZXNlcnZlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBvciBpZiB0aGV5IE1VU1QgYmUgc2VsZWN0ZWQg YmFzZWQgb24gdGhlIGN1cnJlbnQgb2ZmZXIvYW5zd2VyPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IGV4Y2hhbmdlLiBJdCBzZWVtcyB0aGUg Y3VycmVudDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgc3BlY2lmaWNhdGlvbiBsYW5ndWFnZSBpcyBub3Qgc3Ryb25nIG9yIGNsZWFy IGVub3VnaCBvbiB0aGlzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0b3BpYy48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgSW4gbXkgb3BpbmlvbiwgSUYgYSBuZXcgRFRMUyBj b25uZWN0aW9uIG5lZWRzIHRvIGJlIGVzdGFibGlzaGVkPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IChmb3Igd2hhdGV2ZXIgcmVhc29ucyks IHRoZSBjdXJyZW50IHJvbGVzIHNob3VsZCBiZSB1c2VkLjxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgJmx0O1JhanUmZ3Q7IFdoZW4gSUNFIGlzIE5PVCB1 c2VkLCBob3cgZG9lcyB0aGUgb2ZmZXJlciBrbm93IHRoYXQgdGhlPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgYW5zd2VyZXIgZG9lcyBub3QgY2hh bmdlIHRoZSBmaW5nZXJwcmludCBhbmQvb3IgdHJhbnNwb3J0PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBwYXJhbWV0ZXJzPzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyZndDsmZ3Q7IEkgZ3Vlc3MgaXQgZG9lcyBub3Qga25vdy4gU28sIG9mZmVy ZXIgaGFzIHRvIGJlIHByZXBhcmVkIGZvcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgbmV3IERUTFM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyBhc3NvY2lhdGlvbiBieSBvZmZlcmluZyBhY3RwYXNzLiBXaGVuIElDRSBpcyB1c2Vk LCB0aGUgYW5zd2VyZXI8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNhbid0PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgY2hhbmdl IHRyYW5zcG9ydCBwYXJhbWV0ZXIgdW5sZXNzIG9mZmVyZXIgZG9lcyBJQ0UgcmVzdGFydCAod2hp Y2g8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBj aGFuZ2VzIG9mZmVyZXIgdHJhbnNwb3J0IHBhcmFtZXRlcnMpOyBSZWYgWzFdIGlzIHZlcnkgY2xl YXIgb248YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoaXM8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBpbmRpY2F0aW5nICZxdW90 O0RUTFMgaGFuZHNoYWtlIHByb2NlZHVyZSBpcyByZXBlYXRlZCZxdW90Oy4gSG93ZXZlciw8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGV2ZW4gd2hlbjxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IElDRSBpcyB1c2VkLCBJIGRvIG5v dCBmaW5kIGFueSByZXN0cmljdGlvbiBhYm91dCBhbnN3ZXJlciBub3Q8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBjaGFuZ2luZyBmaW5nZXJwcmlu dC4gU28sIGV2ZW4gd2l0aG91dCBJQ0UgcmVzdGFydCBhbnN3ZXJlciBjYW48YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyB0cmlnZ2VyIGEgRFRMUyBy ZW5lZ290aWF0aW9uIGJ5IGNoYW5naW5nIGl0cyBmaW5nZXJwcmludC48YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IFRvIGNvbmNsdWRlIGFsbCB0aGlzLCBJ TU8gd2hldGhlciBJQ0UgaXMgdXNlZCBvciBub3QsIHNlbmRpbmc8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGFjdHBhc3M8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBmb3IgYWxsIG5ldyBvZmZlcnMgbWF5IGJlIGNvdmVyIGFsbCBw b3NzaWJsZSBzY2VuYXJpb3MuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsgVGhhdCBpcyBhbHNvIG15IGNvbmNsdXNpb24gYmFzZWQgb24gdGhlIGRpc2N1c3Npb24gc28g ZmFyLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDs8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IEkgYWxzbyB0aGlu ayB0aGUgSlNFUCBkcmFmdCBhcyBmYXIgYXMgZGV0YWlsZWQgb3V0IGlzIGNvcnJlY3QsPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBidXQgaW5mbzxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgYWJvdXQgaG93IHRoZSBpbXBsZW1lbnRhdGlv biBzaG91bGQgYmVoYXZlIGZvciBTdWJzZXF1ZW50IGFuc3dlcnMgaXM8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IG1pc3NpbmcuIFRleHQgc2F5aW5nIHRo YXQgdGhlIHJvbGUgbXVzdCBiZSBtYWludGFpbmVkICh1bmxlc3M8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHRoZXJlIGlzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyBhbiBJQ0UgcmVzdGFydCkgc2hvdWxkIGJlIHB1dCBpbiB0aGVyZS48 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgJmx0O1JhanUmZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IEhpIFN0ZWZhbiw8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgTG9va3MgbGlrZSwgdGhlcmUgaXMgc29t ZSBtaXN1bmRlcnN0YW5kaW5nIGhlcmUuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgUHJvYmFibHkgbXkgZmF1bHQgaW4gdGhhdCBjYXNlIDopPGJyPg0KJmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBNeSBjb25jbHVzaW9uIGlzIHRv IGluY2x1ZGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgYWN0cGFzcywg YnV0IG5vdCB0aGUgcHJldmlvdXNseSBuZWdvdGlhdGVkIHJvbGUsIGluIGFsbCBzdWJzZXF1ZW50 IG9mZmVycyw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgbm90IGp1c3Qg ZHVyaW5nIElDRS1yZXN0YXJ0cy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBJIHRoaW5rIHRoYXQgaXMgd2hhdCB0aGUgSlNFUCBkcmFmdCBzYXlzIC0gYW5kIG15 IGNvbmNsdXNpb24gaXMgdGhhdCBpdDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg X2lzXyBjb3JyZWN0Ljxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IE15IHBvaW50IHdhcyB0aGF0IHRoZSBfYW5zd2VyXyBzaG91bGQgKHdoZW4gaXQgaXMgYSBzdWJz ZXF1ZW50IGFuc3dlcik8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNob3VsZCBz YXkgdGhlIHNhbWUgcm9sZSBhcyBpbiBwcmV2aW91cyBhbnN3ZXJzICh1bmxlc3MgdGhlcmUgaXMg YW4gSUNFPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXN0YXJ0KS48YnI+DQom Z3Q7PGJyPg0KJmd0OyBJIGFncmVlIHRoZSBKU0VQIHRleHQgc2hvdWxkIGluZGljYXRlIHRoYXQg cm9sZXMgc2hvdWxkIHN0YXkgdGhlIHNhbWUuPGJyPg0KJmd0OyBXZSBoYXZlIGhhZCB0aGlzIGFz IGEgVE9ETyBmb3IgYSB3aGlsZTo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNv bS9ydGN3ZWItd2cvanNlcC9pc3N1ZXMvNzIiPmh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cv anNlcC9pc3N1ZXMvNzI8L2E+PGJyPg0KPGJyPg0KR3JlYXQuIEkgc2hvdWxkIGhhdmUgY2hlY2tl ZCB0aGF0IG91dCBiZWZvcmUuPGJyPg0KPGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D577322ESESSMB209erics_-- From nobody Wed Dec 3 20:45:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504061A0039 for ; Wed, 3 Dec 2014 20:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GB5qy8f6LIxH for ; Wed, 3 Dec 2014 20:41:30 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 347A41A0047 for ; Wed, 3 Dec 2014 20:41:30 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-5b-547fe5f8607e Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B5.DC.24955.8F5EF745; Thu, 4 Dec 2014 05:41:28 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 05:41:27 +0100 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Roman Shpount Thread-Topic: [rtcweb] Unsolicited DTLS Handshake Thread-Index: AQHQDbgwjr0wkzj8TUKVKwdS4+MXBJx9xuEggAAb0wCAAAUYAIAA9eU6 Date: Thu, 4 Dec 2014 04:41:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5773BD@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D56EA42@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EDF50@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D573154@ESESSMB209.ericsson.se> , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D5773BDESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM+Jvje6Pp/UhBh0rpC2m77OxmHFhKrPF 2n/t7A7MHuca3rN7LFnyk8nj1pSCAOYoLpuU1JzMstQifbsEroyH63qZC/7oVLyYspu1gfGK dhcjJ4eEgIlE98utTBC2mMSFe+vZuhi5OIQEjjBK9N9axArhLGaUWH96N0sXIwcHm4CFRPc/ sGYRgUSJJTNns4PYzALqEncWnwOzhQUMJKZPms4MUWMo0Xz6LAuE7SbxpHU3WA2LgIrEg7Zn YHFeAV+Jdy3ToXZdYpOY1T8bLMEpECix4/NVMJsR6Lrvp9YwQSwTl2j6spIV4moBiSV7zjND 2KISLx//YwW5k1kgX2LnhHiI+YISJ2c+YZnAKDILSfcshKpZSKogwpoS63fpQ1QrSkzpfsgO YWtItM6Zy44svoCRfRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYIwd3PJbdQfj5TeOhxgF OBiVeHgNztWHCLEmlhVX5h5ilOZgURLnXXhuXrCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkG xnrr5bqzBPcuFPN8PXdO5gbb1Q+t71xQEY05svx7Ygu7Rn/k0QRZ59rGhedPZb0QKZXnYbly L3pd2/+r33bNWrnzk1bY9J+Ne9mmrPa9lTiFn8mrkdXUX8wpjm9NkOh6zV6bHbdXnbhl+uYR 81Wuh1HiOfUFQjYHNnGV3lvjmX3+uMXKF+8u9SixFGckGmoxFxUnAgAt3S9rkgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nshXXZIvh-8IlpIsgo8aROP8wfs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 04:41:33 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D5773BDESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSW5ha2ksDQoNCk15IGludGVudGlvbiBpcyBub3QgdG8gYmUgYWJsZSB0byBkbyBldmVyeXRo aW5nIHdpdGggTy9BLg0KDQpJIGFtIHRyeWluZyB0byBmaWd1cmUgb3V0IHdoYXQgY2FuIGJlIGRv bmUgd2l0aCBPL0EsIGFuZCBob3cvaWYgTy9BIGFmZmVjdHMgZXhpc3RpbmcgRFRMUyBjb25uZWN0 aW9ucy4NCg0KSWYgc29tZXRoaW5nIGNhbiBOT1QgYmUgZG9uZSwgSSB0aGluayBpdCB3b3VsZCBi ZSBnb29kIHRvIGRvY3VtZW50IHNvbWV3aGVyZS4NCg0KSSBhbSB3aWxsaW5nIHRvIHN0YXJ0IGRy YWZ0aW5nIGEgIlRMUyB3aXRoIFNEUCBPL0EiIGRyYWZ0LCBpZiBwZW9wbGUgdGhpbmsgc3VjaCB3 b3VsZCBiZSB1c2VmdWwuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNClNlbnQgZnJvbSBteSBX aW5kb3dzIFBob25lDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogScOx YWtpIEJheiBDYXN0aWxsbzxtYWlsdG86aWJjQGFsaWF4Lm5ldD4NClNlbnQ6IOKAjjAzL+KAjjEy L+KAjjIwMTQgMTc6MDENClRvOiBSb21hbiBTaHBvdW50PG1haWx0bzpyb21hbkB0ZWx1cml4LmNv bT4NCkNjOiBDaHJpc3RlciBIb2xtYmVyZzxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPjsgcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW3J0Y3dlYl0gVW5zb2xpY2l0ZWQgRFRMUyBIYW5kc2hha2UNCg0KMjAxNC0xMi0wMyAx NTo0MyBHTVQrMDE6MDAgUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb20+Og0KPiBJZiB0 aGUgdHJhbnNwb3J0IHBhcmFtZXRlciBoYXZlIE5PVCBjaGFuZ2VkLCBjYW4gdGhlIGZpbmdlcnBy aW50IGJlIGNoYW5nZWQ/DQoNCg0KQ29ycmVjdCBtZSBpZiBJJ20gd3JvbmcsIGJ1dCBkdXJpbmcg YSBEVExTL1RMUyBzZXNzaW9uIGNlcnRpZmljYXRlcw0KYXJlIHNlbnQganVzdCBvbmNlLCBhdCB0 aGUgYmVnaW5uaW5nLiBDaGFuZ2luZyB0aGUgYT1maW5nZXJwcmludA0KYXR0cmlidXRlIGluIGEg bmV3IFNEUCBPL0Egcm91bmQtdHJpcCB3aXRob3V0IGZvcmNpbmcgYSBuZXcgRFRMUw0Kc2Vzc2lv biBzaG91bGQganVzdCBiZSBjb25zaWRlcmVkIGFuIGVycm9yLg0KDQpBZ2Fpbjogd2UgYXJlIHRy eWluZyB0byBzaWduYWwgdG9vIG11Y2ggaW4gdGhlIFNEUC4NCg0KLS0NCknDsWFraSBCYXogQ2Fz dGlsbG8NCjxpYmNAYWxpYXgubmV0Pg0K --_000_7594FB04B1934943A5C02806D1A2204B1D5773BDESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+SGkgSW5ha2ksPGJyPg0KPGJyPg0KTXkg aW50ZW50aW9uIGlzIG5vdCB0byBiZSBhYmxlIHRvIGRvIGV2ZXJ5dGhpbmcgd2l0aCBPL0EuPGJy Pg0KPGJyPg0KSSBhbSB0cnlpbmcgdG8gZmlndXJlIG91dCB3aGF0IGNhbiBiZSBkb25lIHdpdGgg Ty9BLCBhbmQgaG93L2lmIE8vQSBhZmZlY3RzIGV4aXN0aW5nIERUTFMgY29ubmVjdGlvbnMuPGJy Pg0KPGJyPg0KSWYgc29tZXRoaW5nIGNhbiBOT1QgYmUgZG9uZSwgSSB0aGluayBpdCB3b3VsZCBi ZSBnb29kIHRvIGRvY3VtZW50IHNvbWV3aGVyZS48YnI+DQo8YnI+DQpJIGFtIHdpbGxpbmcgdG8g c3RhcnQgZHJhZnRpbmcgYSAmcXVvdDtUTFMgd2l0aCBTRFAgTy9BJnF1b3Q7IGRyYWZ0LCBpZiBw ZW9wbGUgdGhpbmsgc3VjaCB3b3VsZCBiZSB1c2VmdWwuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+ DQo8YnI+DQpDaHJpc3Rlcjxicj4NCjxicj4NClNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lPC9k aXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGhyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQi PkZyb206DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJp ZjsgZm9udC1zaXplOjExcHQiPjxhIGhyZWY9Im1haWx0bzppYmNAYWxpYXgubmV0Ij5Jw7Fha2kg QmF6IENhc3RpbGxvPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDoN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250 LXNpemU6MTFwdCI+4oCOMDMv4oCOMTIv4oCOMjAxNCAxNzowMTwvc3Bhbj48YnI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9u dC13ZWlnaHQ6Ym9sZCI+VG86DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPjxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1 cml4LmNvbSI+Um9tYW4gU2hwb3VudDwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJv bGQiPkNjOg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZToxMXB0Ij48YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tIj5DaHJpc3RlciBIb2xtYmVyZzwvYT47DQo8YSBocmVmPSJtYWlsdG86cnRjd2Vi QGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdo dDpib2xkIj5TdWJqZWN0Og0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp LHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij5SZTogW3J0Y3dlYl0gVW5zb2xpY2l0ZWQgRFRM UyBIYW5kc2hha2U8L3NwYW4+PGJyPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxmb250IHNpemU9 IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDsiPg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0 Ij4yMDE0LTEyLTAzIDE1OjQzIEdNVCYjNDM7MDE6MDAgUm9tYW4gU2hwb3VudCAmbHQ7cm9tYW5A dGVsdXJpeC5jb20mZ3Q7Ojxicj4NCiZndDsgSWYgdGhlIHRyYW5zcG9ydCBwYXJhbWV0ZXIgaGF2 ZSBOT1QgY2hhbmdlZCwgY2FuIHRoZSBmaW5nZXJwcmludCBiZSBjaGFuZ2VkPzxicj4NCjxicj4N Cjxicj4NCkNvcnJlY3QgbWUgaWYgSSdtIHdyb25nLCBidXQgZHVyaW5nIGEgRFRMUy9UTFMgc2Vz c2lvbiBjZXJ0aWZpY2F0ZXM8YnI+DQphcmUgc2VudCBqdXN0IG9uY2UsIGF0IHRoZSBiZWdpbm5p bmcuIENoYW5naW5nIHRoZSBhPWZpbmdlcnByaW50PGJyPg0KYXR0cmlidXRlIGluIGEgbmV3IFNE UCBPL0Egcm91bmQtdHJpcCB3aXRob3V0IGZvcmNpbmcgYSBuZXcgRFRMUzxicj4NCnNlc3Npb24g c2hvdWxkIGp1c3QgYmUgY29uc2lkZXJlZCBhbiBlcnJvci48YnI+DQo8YnI+DQpBZ2Fpbjogd2Ug YXJlIHRyeWluZyB0byBzaWduYWwgdG9vIG11Y2ggaW4gdGhlIFNEUC48YnI+DQo8YnI+DQotLSA8 YnI+DQpJw7Fha2kgQmF6IENhc3RpbGxvPGJyPg0KJmx0O2liY0BhbGlheC5uZXQmZ3Q7PGJyPg0K PC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D5773BDESESSMB209erics_-- From nobody Wed Dec 3 20:52:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD89D1A0047 for ; Wed, 3 Dec 2014 20:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K1zgJ4fFjoc for ; Wed, 3 Dec 2014 20:46:43 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DCCB1A0039 for ; Wed, 3 Dec 2014 20:46:42 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-ad-547fe7307ab1 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 50.1B.29772.037EF745; Thu, 4 Dec 2014 05:46:40 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 05:46:40 +0100 From: Christer Holmberg To: "ranjit@ranjitvoip.com" , "Makaraju, Maridi Raju (Raju)" Thread-Topic: [rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets Thread-Index: AQHQDyhJsWChRutFjkOILDb7zwIvO5x+IkQAgAAF7QCAALQUmg== Date: Thu, 4 Dec 2014 04:46:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D57743A@ESESSMB209.ericsson.se> References: <6bef1cce67d1c9da7c29d8e0804f2551@ranjitvoip.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D57743AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3RtfgeX2IQctLHYuGjVdYLWb+fshm sfZfO7sDs0frs72sHkuW/GTy2LfEPIA5issmJTUnsyy1SN8ugSvj/NX77AUrgioOH25kb2A8 6trFyMkhIWAiMf3Ia2YIW0ziwr31bCC2kMARRon+SSZdjFxA9mJGiW2bVjB1MXJwsAlYSHT/ 0wapERGokDj66TcLiM0soC5xZ/E5dhBbWCBKomnKOWaImmiJHbOfQNlOEh/2TwarZxFQkTjz 5DtYnFfAV+LvzQ+sELs6mSRmb9jICJLgFLCTWPVrLyuIzQh03PdTa5gglolLNH1ZyQpxtIDE kj3noR4QlXj5+B8ryJ3MAvkS+3aEQswXlDg58wnLBEaRWUi6ZyFUzUJSBVFiIPHl/W0oW1ti 2cLXzBC2vkT3+9NMyOILGNlXMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgRG2cEtvw12ML58 7niIUYCDUYmH1/BcfYgQa2JZcWXuIUZpDhYlcd6F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk 4uCUamAU6Vh/wvXdjt+6/8Sayk5ckC6U6c9Je3Pgy6f2j5GGsw5W7WXI3PWd48pfddXSwAgW XYNTdxZ4iL4tbMz+fSmrXff6tsjctpqNz785bDXLOxCQqf30Z4TNg3VL5RZKRrokHXY/wJT1 yPF6nVdCnoqPdLL2oU2rd6xrZnPS2PZL+r+nvao2528lluKMREMt5qLiRABBLqVlkwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Vh-vJ4BN63DP_dNuAJHEu9ViMyI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 04:46:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D57743AESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Ranjit, For WebRTC access to IMS, there is no such thing as a "default protocol". It is true that, inside IMS, SIP is used, but you can use whatever protocol= you want to access IMS, as long as the eP-CSCF (acting as a WebRTC Gatew= ay) can map it into SIP. Regards, Christer Sent from my Windows Phone ________________________________ From: ranjit@ranjitvoip.com Sent: =FD03/=FD12/=FD2014 21:02 To: Makaraju, Maridi Raju (Raju) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Interest and need for Websocket subprotocol - JSEP ov= er websockets Hello all While I agree SIP over Websockets is default signaling protocol for WebRTC while working with IMS, there could be scenarios where WebRTC calls can get initiated from non SIP UAs like web browsers which do not support SIP. Then in such cases, the following things could happen 1) the WebRTC client on the browser can use JSEP to send its signaling information over WebSocket, 2) the JSEP message would then land on the WebRTC GW over WS. 3) This JSEP message would then be converted to a SIP message and then sent to IMS core. 4) within IMS core, its a regular SIP message 5) Again in the reverse direction, WebRTC GW would convert SIP to JSEP 6) JSEP message is sent over Websocket to UE. now we see JSEP messages getting exchanged over Websockets. so if the websocket sub-protocol does not define the type as "jsep", then the WebRTC GW would not know the incoming message type and hence may discard it or its behavior may be uncertain. Also the JSEP message needs to be enhanced to add more message types (along with current OFFER / ANSWER) to be able to map it with standard signaling protocol like SIP as defined in https://tools.ietf.org/html/draft-partha-rtcweb-jsep-sip-01 Regards Ranjit On 2014-12-03 12:40 pm, Makaraju, Maridi Raju (Raju) wrote: > + 1 for using SIP over WebSocket. > > FROM: rtcweb [mailto:rtcweb-bounces@ietf.org] ON BEHALF OF Roman > Shpount > SENT: Wednesday, December 03, 2014 12:38 PM > TO: ranjit@ranjitvoip.com > CC: rtcweb@ietf.org > SUBJECT: Re: [rtcweb] Interest and need for Websocket subprotocol - > JSEP over websockets > > Is there any reason you cannot use SIP over WebSocket > (https://tools.ietf.org/html/rfc7118 [1])? > > Call signaling will require a lot more information then what is > provided in JSEP. JSEP mostly deals with offer and answer processing. > Signaling will also need to deal with things like who is calling, why > they are calling, transfers, other application specific details. In > other words, I think this is a very bad idea. > > _____________ > Roman Shpount > > On Wed, Dec 3, 2014 at 1:31 PM, wrote: > > Hi > With websockets as a de-facto transport protocol for WebRTC signaling > and JSEP being the format of encoding information, there is a need for > a defining a websocket sub-protocol : jsep. So I would like to know if > there is any interest in the community and also the views from experts > about the need for a websocket-sub protocol for JSEP. > > The main purpose of defining the sub protocol (jsep) is to make sure > that the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving > JSEP encoded messages. > > Thanks > Ranjit > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb [2] > > > > Links: > ------ > [1] https://tools.ietf.org/html/rfc7118 > [2] https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7594FB04B1934943A5C02806D1A2204B1D57743AESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Ranjit,
For WebRTC access to IMS, there is no such thing as a "default protoco= l".

It is true that, inside IMS, SIP is used, but you can use whatever protocol= you want to access   IMS, as long as the eP-CSCF (acting as a We= bRTC Gateway) can map it into SIP.

Regards,

Christer


Sent from my Windows Phone
From: ranjit@ranjitvoip.com
Sent: =FD03= /=FD12/=FD2014 21:02
To: Makaraju, Maridi Raju (Raju)=
Cc: rtcweb@ietf.org
Subject: Re: [= rtcweb] Interest and need for Websocket subprotocol - JSEP over websockets<= /span>

Hello all

While I agree SIP over Websockets is default signaling protocol for
WebRTC while working with IMS, there could be scenarios where WebRTC
calls can get initiated from non SIP UAs like web browsers which do not support SIP. Then in such cases, the following things could happen
1) the WebRTC client on the browser can use JSEP to send its signaling
information over WebSocket,
2) the JSEP message would then land on the WebRTC GW over WS.
3) This JSEP message would then be converted to a SIP message and then
sent to IMS core.
4) within IMS core, its a regular SIP message
5) Again in the reverse direction, WebRTC GW would convert SIP to JSEP
6) JSEP message is sent over Websocket to UE.

now we see JSEP messages getting exchanged over Websockets. so if the
websocket sub-protocol does not define the type as "jsep", then t= he
WebRTC GW would not know the incoming message type and hence may discard it or its behavior may be uncertain.

Also the JSEP message needs to be enhanced to add more message types
(along with current OFFER / ANSWER) to be able to map it with standard
signaling protocol like SIP as defined in
htt= ps://tools.ietf.org/html/draft-partha-rtcweb-jsep-sip-01

Regards
Ranjit

On 2014-12-03 12:40 pm, Makaraju, Maridi Raju (Raju) wrote:
> + 1 for using SIP over WebSocket.
>
> FROM: rtcweb [mailto:rtcweb= -bounces@ietf.org] ON BEHALF OF Roman
> Shpount
>  SENT: Wednesday, December 03, 2014 12:38 PM
>  TO: ranjit@ranjitvoip.com
>  CC: rtcweb@ietf.org
>  SUBJECT: Re: [rtcweb] Interest and need for Websocket subprotoco= l -
> JSEP over websockets
>
> Is there any reason you cannot use SIP over WebSocket
> (https://tools.ietf.org/html/rfc7118 [1])?
>
> Call signaling will require a lot more information then what is
> provided in JSEP. JSEP mostly deals with offer and answer processing.<= br> > Signaling will also need to deal with things like who is calling, why<= br> > they are calling, transfers, other application specific details. In > other words, I think this is a very bad idea.
>
> _____________
>  Roman Shpount
>
> On Wed, Dec 3, 2014 at 1:31 PM, <ranjit@ranjitvoip.com> wrote: >
> Hi
>  With websockets as a de-facto transport protocol for WebRTC sign= aling
> and JSEP being the format of encoding information, there is a need for=
> a defining a websocket sub-protocol : jsep. So I would like to know if=
> there is any interest in the community and also the views from experts=
> about the need for a websocket-sub protocol for JSEP.
>
>  The main purpose of defining the sub protocol (jsep) is to make = sure
> that the WebRTC client (WIC) and WebRTC server (E-CSCF) are receiving<= br> > JSEP encoded messages.
>
>  Thanks
>  Ranjit
>
>  _______________________________________________
>  rtcweb mailing list
>  rtcweb@ietf.org
>  https:/= /www.ietf.org/mailman/listinfo/rtcweb [2]
>
>
>
> Links:
> ------
> [1] https://tools.ietf= .org/html/rfc7118
> [2] https://w= ww.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb
 --_000_7594FB04B1934943A5C02806D1A2204B1D57743AESESSMB209erics_-- From nobody Wed Dec 3 21:17:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7F91A0073 for ; Wed, 3 Dec 2014 21:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQ4yzOpa8ed0 for ; Wed, 3 Dec 2014 21:17:04 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD691A002F for ; Wed, 3 Dec 2014 21:17:04 -0800 (PST) Received: by mail-yk0-f169.google.com with SMTP id 79so7638919ykr.14 for ; Wed, 03 Dec 2014 21:17:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KzucOGQUDB/xvO33zFtVYj/Nap2K4jhw7JXqZ+QfZ/M=; b=a8EZUVE+cEUJ/oKraUHxBoyI+RNeJg3K8Rlq0d377E+XlWVV653XiLlM6omdC6Zix2 TV/Vkr30eVZp/Nlv9UiY43rlshfYDZF89ZQ4yMi/zPAcd9oqYptJWHDlLWbOkB0ZkZTM EYC512hDDY2xx/Cb25ytqFe9D7bkv4xHePkYgSYWdMx0QP1aEQRjWoo+pF0DMjcNAl9j Fan/GH+1xjHB+Nk49tcybaYMKEudzj0E6Cc5TlClOK7X3xDstvzqKC8Pr35bZ8rDZkFd PsQCSVf5lfS/AKMokvSW8W2X5KXpcC7U+5JrQZfdjMIxf+PFMPWKSgB7l1qe9TYH5Hkc HnQg== X-Received: by 10.170.212.10 with SMTP id d10mr608000ykf.49.1417670223190; Wed, 03 Dec 2014 21:17:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.170.135.193 with HTTP; Wed, 3 Dec 2014 21:16:43 -0800 (PST) In-Reply-To: <20141204014218.5955730.38619.3157@blackberry.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> From: Silvia Pfeiffer Date: Thu, 4 Dec 2014 16:16:43 +1100 Message-ID: To: Andrew Allen Content-Type: multipart/alternative; boundary=001a11c10b340fe24805095d1241 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/I-WNH8JKmptCNQ2J3-tAWEE59EA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 05:17:06 -0000 --001a11c10b340fe24805095d1241 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Indeed, that's why I said point 1. in David's list doesn't make sense, since he's talking about a small company getting sued by Nokia. S. On Thu, Dec 4, 2014 at 12:42 PM, Andrew Allen wrote= : > Silvia > > It is not usually the small companies that get sued in patent cases. > Its companies with assets and significant revenues that get the lawsuits. > > Nobody sues the penniless! - thats like suing the homeless! > > Andrew > > Sent from my BlackBerry 10 smartphone. > *From: *Silvia Pfeiffer > *Sent: *Wednesday, December 3, 2014 19:28 > *To: *David Singer > *Cc: *rtcweb@ietf.org > *Subject: *Re: [rtcweb] Finishing up the Video Codec document, MTI > (again, still, sorry) > > On Thu, Dec 4, 2014 at 5:33 AM, David Singer wrote: > > As I understand it, the recent face to face meeting decided to draft th= e > requirement that WebRTC browsers be required to implement both VP8 and > H.264, and get feedback on this, on the list. > > > > This is some feedback. > > > > > > > > I=E2=80=99d like to point out that this could easily place companies in= an > impossible position. > > > > Consider: it is not uncommon for IPR owners to grant a license (often > free) only to =E2=80=98conforming implementations=E2=80=99. (A common rat= ionale is that > they want to use their IPR to bring convergence and interoperability to t= he > industry). Let=E2=80=99s hypothesize that this happens, now or in future= , from > Company X, for some IPR in the WebRTC specifications. > > > > Consider also: we have an =E2=80=9Cunwilling to license=E2=80=9D statem= ent from Nokia on > VP8, on the formal record (and including a long list of patents). > > > > Consider finally: a small company for whom WebRTC is important. > > > > > > > > Let=E2=80=99s look at the choices: > > > > 1. Follow the mandate, implement VP8, and risk a ruinous lawsuit from > Nokia. > > > > 2. Reject the mandate, do not implement VP8, and be formally therefore > not conformant and therefore not in receipt of a license from company X; > risk a ruinous lawsuit from X. > > > > 3. Do not implement WebRTC, and risk a ruinous loss of relevance. > > > I don't see the risk of 1. having changed because of the IETF's > statement. Plenty of small companies are already doing 1. and have had > to risk getting sued by Nokia at this point in time already. In fact, > it's a risk that small companies always have to deal with since there > is so much patented technology around that you invariable will step on > something. I doubt very much that the IETF's decision has any impact > on small business' risk in that space at all. > > > > I do not think that the IETF should be placing anyone into the position > of having three extremely unpalatable choices. > > For a small company in the WebRTC space, 3. is a non-choice. 2. Is > more of a business decision than an IP decision - which market are you > trying to address? Are you trying to be interoperable with (current) > browsers - then implement VP8. Are you trying to be interoperable with > legacy devices - then implement H.264 (and probably even H.263). > > If you are trying to argue for a large company, the situation changes. > However, as a large company, you tend to have an existing portfolio of > patents. You're already playing the game of patents. As long as your > hypothetical "IPR owners to grant a license only to =E2=80=98conforming > implementations=E2=80=99" doesn't happen, you are free to choose 2. and a= void > Nokia. > > As for the threat in your option 2. - I can only see Google with IPR > around VP8. Now, Google's IPR statement on WebM codecs, which includes > VP8 and VP9 currently states: "Google hereby grants to you a > perpetual, worldwide, non-exclusive, no-charge, royalty-free, > irrevocable (except as stated in this section) patent license" > http://www.webmproject.org/license/additional/ > The word "perpetual" implies (to my non-lawyer eyes) that they can't > suddenly change this to mean "only if you are conformant to the > standard". So you can't be referring to such a risk associated with > VP8 being created by Google. I don't know which other company you > would want to be afraid of for your hypothetical threat in 2. Could > you clarify? > > > Best Regards, > Silvia. > > > > (Yes, I am aware that #2 is =E2=80=98unlikely=E2=80=99, but one day som= eone will decide > that the =E2=80=9Conly to conformant implementations=E2=80=9D clause need= s to be real and > enforced, and will do this; our hypothetical small company might prefer n= ot > to be the example case.) > > > > (I use a small company as the example, because for them the risk is > bankruptcy, but of course no-one likes to step into the path of trouble > even if they have the resources to weather it.) > > > > Dave Singer > > > > singer@mac.com > > > > David Singer > > Manager, Software Standards, Apple Inc. > > > > _______________________________________________ > > 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 > --001a11c10b340fe24805095d1241 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Indeed, that's why I said point 1. in David's= list doesn't make sense, since he's talking about a small company = getting sued by Nokia.
S.

=
On Thu, Dec 4, 2014 at 12:42 PM, Andrew Allen <aallen@blackberry.com> wrote:
Silvia

It =C2=A0is not usually the small companies that get sued in patent cases. = Its companies with assets and significant revenues that get the lawsuits.

Nobody sues the=C2=A0=C2=A0penniless! - thats like suing the homeless!=
An= drew

Sent from my BlackBerry 10 smartphone.
From: Silvia Pfeiffer
Sent: Wednesday, December 3, 2014 19:28
To: David Singer
Subject: Re: [rtcweb] Finishing up the Video Codec document, MT= I (again, still, sorry)

On Thu, Dec 4, 2014 at 5:33 AM, David Singer <singer@apple.com> wrote:
> As I understand it, the recent face to face meeting decided to draft t= he requirement that WebRTC browsers be required to implement both VP8 and H= .264, and get feedback on this, on the list.
>
> This is some feedback.
>
>
>
> I=E2=80=99d like to point out that this could easily place companies i= n an impossible position.
>
> Consider: it is not uncommon for IPR owners to grant a license (often = free) only to =E2=80=98conforming implementations=E2=80=99. (A common ratio= nale is that they want to use their IPR to bring convergence and interopera= bility to the industry).=C2=A0 Let=E2=80=99s hypothesize that this happens, now or in future, from Company X, for some IPR in the WebRTC spec= ifications.
>
> Consider also: we have an =E2=80=9Cunwilling to license=E2=80=9D state= ment from Nokia on VP8, on the formal record (and including a long list of = patents).
>
> Consider finally: a small company for whom WebRTC is important.
>
>
>
> Let=E2=80=99s look at the choices:
>
> 1.=C2=A0 Follow the mandate, implement VP8, and risk a ruinous lawsuit= from Nokia.
>
> 2.=C2=A0 Reject the mandate, do not implement VP8, and be formally the= refore not conformant and therefore not in receipt of a license from compan= y X; risk a ruinous lawsuit from X.
>
> 3.=C2=A0 Do not implement WebRTC, and risk a ruinous loss of relevance= .


I don't see the risk of 1. having changed because of the IETF's
statement. Plenty of small companies are already doing 1. and have had
to risk getting sued by Nokia at this point in time already. In fact,
it's a risk that small companies always have to deal with since there is so much patented technology around that you invariable will step on
something. I doubt very much that the IETF's decision has any impact on small business' risk in that space at all.


> I do not think that the IETF should be placing anyone into the positio= n of having three extremely unpalatable choices.

For a small company in the WebRTC space, 3. is a non-choice. 2. Is
more of a business decision than an IP decision - which market are you
trying to address? Are you trying to be interoperable with (current)
browsers - then implement VP8. Are you trying to be interoperable with
legacy devices - then implement H.264 (and probably even H.263).

If you are trying to argue for a large company, the situation changes.
However, as a large company, you tend to have an existing portfolio of
patents. You're already playing the game of patents. As long as your hypothetical "IPR owners to grant a license only to =E2=80=98conformin= g
implementations=E2=80=99" doesn't happen, you are free to choose 2= . and avoid
Nokia.

As for the threat in your option 2. - I can only see Google with IPR
around VP8. Now, Google's IPR statement on WebM codecs, which includes<= br> VP8 and VP9 currently states: "Google hereby grants to you a
perpetual, worldwide, non-exclusive, no-charge, royalty-free,
irrevocable (except as stated in this section) patent license"
http://www.webmproject.org/license/additional/
The word "perpetual" implies (to my non-lawyer eyes) that they ca= n't
suddenly change this to mean "only if you are conformant to the
standard". So you can't be referring to such a risk associated wit= h
VP8 being created by Google. I don't know which other company you
would want to be afraid of for your hypothetical threat in 2. Could
you clarify?


Best Regards,
Silvia.


> (Yes, I am aware that #2 is =E2=80=98unlikely=E2=80=99, but one day so= meone will decide that the =E2=80=9Conly to conformant implementations=E2= =80=9D clause needs to be real and enforced, and will do this; our hypothet= ical small company might prefer not to be the example case.)
>
> (I use a small company as the example, because for them the risk is ba= nkruptcy, but of course no-one likes to step into the path of trouble even = if they have the resources to weather it.)
>
> Dave Singer
>
> singer@mac.com=
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
> _______________________________________________
> 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

--001a11c10b340fe24805095d1241-- From nobody Wed Dec 3 21:47:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286DA1A88C3 for ; Wed, 3 Dec 2014 21:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrUgtGLVXJpb for ; Wed, 3 Dec 2014 21:47:22 -0800 (PST) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937B01A87AD for ; Wed, 3 Dec 2014 21:47:22 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id hy4so7664131vcb.1 for ; Wed, 03 Dec 2014 21:47:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Vq549Z6/vGT9BcjXQzJeQfi3jeWKIuDrgtApG09A85Y=; b=ALoRy+236Ob8iGC75m69uvDUyRgUnqKF6jCaRPUixN/j0Pck1yRWT+2wFI6x8vXmpH O8Egk1h+bRj7Z/hls+z6ST+lN8/34txw/ZmrDO0A2G+TiLUXmpflr4eca0Vt2MAHuy4l lGhtrKXcjw84l85GvKO6D1PEVoTrnNBUqa7+qAbVjeZhAs8t+9/Ls5kt9KJEaPD8Fze5 NZnhGp3s3W5rmXw3RlVtVHL2jkIU0uoqgfOXCaqzaN4yUtu1AlMCi2wMENpyi7SS/6nc EhQcOnSpu9ODrxkcWEuqf6e0ybSdlYHAV4m29gJw7orf1llBQNfDBvKeym/kcOUMEW46 PrKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Vq549Z6/vGT9BcjXQzJeQfi3jeWKIuDrgtApG09A85Y=; b=lRFnjwwKzh4fKKz1c+BnTtEyYqm1rNkH3rbs1TfOY7tbgpwZv9CV3NjxwOzEoLpMq0 AktdJkQ/TpT5/WuJ9wYNSG8Jek4Aa3AS3mp34JRAzvakaEjeh13EviuZiQrh6mRsSTjt ET9sTROipc+iB2JczqzjSaaeh0HebKUEj716tTwSjNksDGoiTHisvrQzfB/3OOdg/P9/ 8BzPOXKoOJxOg8CmlkiOOUZAk6xFiGCZX/hNncHA9flN6dZn7Vc6s30y5jPI7gNoFHaQ m37evi0PJxDM6FnQuI7xVi3cwtP89eO9RVGxsxRUvjarFrCuYu5Bslk9at99O3itXXrk GZqQ== X-Gm-Message-State: ALoCoQlmUWDiDiiRfbXbnY4uejH5uRGCApZrJ6GljjzzEiaei2br89P/rRn/7bxfuEGJuMFWx8eK X-Received: by 10.52.136.80 with SMTP id py16mr4116470vdb.54.1417672041531; Wed, 03 Dec 2014 21:47:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Wed, 3 Dec 2014 21:47:01 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5773BD@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D56EA42@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EDF50@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D573154@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5773BD@ESESSMB209.ericsson.se> From: Justin Uberti Date: Wed, 3 Dec 2014 21:47:01 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=bcaec52d4dad71a98e05095d7e2e Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TJaBkxfxcJrkH_yXAfMG74b2-XU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 05:47:24 -0000 --bcaec52d4dad71a98e05095d7e2e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That sounds like a 5763-bis. On Wed, Dec 3, 2014 at 8:41 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Inaki, > > My intention is not to be able to do everything with O/A. > > I am trying to figure out what can be done with O/A, and how/if O/A > affects existing DTLS connections. > > If something can NOT be done, I think it would be good to document > somewhere. > > I am willing to start drafting a "TLS with SDP O/A" draft, if people thin= k > such would be useful. > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > From: I=C3=B1aki Baz Castillo > Sent: =E2=80=8E03/=E2=80=8E12/=E2=80=8E2014 17:01 > To: Roman Shpount > Cc: Christer Holmberg ; rtcweb@ietf.org > Subject: Re: [rtcweb] Unsolicited DTLS Handshake > > 2014-12-03 15:43 GMT+01:00 Roman Shpount : > > If the transport parameter have NOT changed, can the fingerprint be > changed? > > > Correct me if I'm wrong, but during a DTLS/TLS session certificates > are sent just once, at the beginning. Changing the a=3Dfingerprint > attribute in a new SDP O/A round-trip without forcing a new DTLS > session should just be considered an error. > > Again: we are trying to signal too much in the SDP. > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --bcaec52d4dad71a98e05095d7e2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That sounds like a 5763-bis.

On Wed, Dec 3, 2014 at 8:41 PM, Christer = Holmberg <christer.holmberg@ericsson.com> wrote= :
Hi Inaki,

My intention is not to be able to do everything with O/A.

I am trying to figure out what can be done with O/A, and how/if O/A affects= existing DTLS connections.

If something can NOT be done, I think it would be good to document somewher= e.

I am willing to start drafting a "TLS with SDP O/A" draft, if peo= ple think such would be useful.

Regards,

Christer

Sent from my Windows Phone
From: I=C3=B1aki Baz Castillo
Sent: =E2=80= =8E03/=E2=80=8E12/=E2=80=8E2014 17:01
To: Roman Shpount Cc: Christer Holm= berg; rtcweb@ietf.org
Subject: Re: [r= tcweb] Unsolicited DTLS Handshake

2014-12-03 15:43 GMT+01:00 Roman Shpount <roman@telurix.com>:
> If the transport parameter have NOT changed, can the fingerprint be ch= anged?


Correct me if I'm wrong, but during a DTLS/TLS session certificates
are sent just once, at the beginning. Changing the a=3Dfingerprint
attribute in a new SDP O/A round-trip without forcing a new DTLS
session should just be considered an error.

Again: we are trying to signal too much in the SDP.

--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>= ;

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--bcaec52d4dad71a98e05095d7e2e-- From nobody Wed Dec 3 21:49:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDE81A87AD for ; Wed, 3 Dec 2014 21:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pw9P8hQQ52s6 for ; Wed, 3 Dec 2014 21:49:32 -0800 (PST) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354391A00AA for ; Wed, 3 Dec 2014 21:49:32 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id le20so7644009vcb.12 for ; Wed, 03 Dec 2014 21:49:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=njEcOnpfnqNwZtNIDbrNCYRob1jQgrmBydtoCcUmgSo=; b=Tjd4pYK+ooP73+gQZHcPA9PpE+iQc2ZLSBwHfFSDSiT3Ot+/eLmJ4tC+xvvzaCF93A wmRa4g5pTt+aIvIq6S7FZGJugGQ275PE3MpYpRNf4Eez2kkRZQDxwZNFRDas6QZkAfSt zdgsPY9dje7c0JVKI7pvoci279vQRZ0RehymSytnjFgng910ZzMAqfDzpWxtg46a09yk U0JLvKO9AX66kGs7gLJs7AJ960lNOTLT+A3AqdJbn6LPJnXPN/4MN129EXpLWGeitv7b T6It9qHmrChvIBH5FbSuKALUxqm+82epqh2qdCbSsuCbQu2KLayhnoKYF6EcqSmIR7f/ Qxig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=njEcOnpfnqNwZtNIDbrNCYRob1jQgrmBydtoCcUmgSo=; b=JZVP2VPLQ9svSu5HUy5VBfDzfvc8wixjpSrziQ3HyVh29YFI8+ZpOLY1BlG8WeXjcU IyE8EmpmmXL6pEs61d32ZoIKDwn1354E2dT2zquQe7vAgqLgh6BDMw9j5z4tXuiVEIYv LwvwtG35CizbFRbuDcO42zvstLkeU+HKSzA4RMFWJyZ56fenc5iOcA/Kga/xIkbHTc5e ie2fFQMUlaEVWkAQKEt3pb34Y/oV8D0IBDkpdFltkvLazIa98+J6uRXgO9aebTBS9AG5 +039xW74sQCPGhdMxXjdYT0CLeFwy0MhOteDmKPr9maFaY+P4HHpK9ziJOIKf59hwgwK vuLQ== X-Gm-Message-State: ALoCoQmCrqb41MIIO9yJlsNb2b7X2RmfJOxEOsG9kitJywTbEwZnee3nDxwHRNQt8aLwh2B5s+E8 X-Received: by 10.220.118.194 with SMTP id w2mr4914796vcq.24.1417672171300; Wed, 03 Dec 2014 21:49:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Wed, 3 Dec 2014 21:49:11 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D577322@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE2BC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577322@ESESSMB209.ericsson.se> From: Justin Uberti Date: Wed, 3 Dec 2014 21:49:11 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1132f4ba2dc8eb05095d8646 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NkLiCU26TQfSHxck07eqz_Z1DI4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 05:49:35 -0000 --001a1132f4ba2dc8eb05095d8646 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Currently, Chrome errors out (i.e. setRD fails). However, I suspect that teardown of the old DTLS association and setup of a new DTLS association is the desired behavior. On Wed, Dec 3, 2014 at 8:34 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Issue #72 talks about maintaining the previously negotiated role when > actpass is received. I think that is a good approach, and could be used i= n > Offer/Answer too. > > BUT, what does the browser do if e.g. the previous role is passive and > active is received? > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > From: Stefan H=C3=A5kansson LK > Sent: =E2=80=8E03/=E2=80=8E12/=E2=80=8E2014 17:48 > To: Justin Uberti > Cc: Makaraju, Maridi Raju (Raju) ; Chri= ster > Holmberg ; Roman Shpount > ; rtcweb@ietf.org > Subject: Re: [rtcweb] JSEP: Why always offer actpass? > > On 01/12/14 18:26, Justin Uberti wrote: > > > > > > On Sun, Nov 30, 2014 at 7:26 AM, Stefan H=C3=A5kansson LK > > > >> wrote: > > > > On 30/11/14 16:06, Makaraju, Maridi Raju (Raju) wrote: > > >> On 30/11/14 14:51, Makaraju, Maridi Raju (Raju) wrote: > > >>>> Hi, > > >>>> > > >>>>>> RFC 7345 (UDPTL-DTLS) says the following: > > >>>>>> > > >>>>>> "Once an offer/answer exchange has been completed, either > > >>>>>> endpoint > > >>>> MAY > > >>>>>> send a new offer in order to modify the session. The > > >>>>>> endpoints > > >>>> can > > >>>>>> reuse the existing DTLS association if the key fingerprint > > >>>>>> values > > >>>> and > > >>>>>> transport parameters indicated by each endpoint are > unchanged. > > >>>>>> Otherwise, following the rules for the initial offer/answer > > >>>> exchange, > > >>>>>> the endpoints can negotiate and create a new DTLS associati= on > > >>>>>> and, once created, delete the previous DTLS association, > > >>>>>> following the same rules for the initial offer/answer > exchange. > > >>>>>> Each endpoint needs to be prepared to receive data on both > the > > >>>>>> new and old DTLS associations as long as both are alive." > > >>>>>> > > >>>>>> So, I guess that can be read in a way that the setup > attribute > > >>>>>> as such > > >>>> does not impact previously > > >>>>>> negotiated TLS roles - unless the key fingerprint values > and/or > > >>>>>> transport > > >>>> parameters are modified. > > >>>>>> > > >>>>>> The SCTP-SDP draft currently says that a subsequent offer > must > > >>>>>> not change > > >>>> the previously negotiated roles. But, I guess > > >>>>>> we could say something similar as in RFC 7345. > > >>>>> > > >>>>> I have struggled with this language quite a bit from the > > >>>>> implementation > > >>>> perspective. I think we need to explicitly state > > >>>>> that endpoints MUST reuse the existing association if the ke= y > > >>>>> fingerprint > > >>>> values and transport parameters indicated > > >>>>> by each endpoint are unchanged. > > >>>> > > >>>> We could take such general approach. > > >>>> > > >>>> However, for 'SCTP/DTLS' (DTLS over SCTP), I assume that the > DTLS > > >>>> connection will also be re-established if the underlying SCTP > > >>>> association is re- established - even if no transport > parameters > > >>>> etc are changed. > > >>>> > > >>>> Also, RFC 6083 says: > > >>>> > > >>>> "Each DTLS connection MUST be established and terminated > > within the > > >>>> same SCTP association." > > >>>> > > >>>> > > >>>>> The way this language reads to me is that endpoints can reus= e > the > > >>>>> existing > > >>>> association if they want to, but they can create a new one if > they > > >>>> don't. Also, when this new > > >>>>> association is created, it is unclear if old setup roles MUS= T > be > > >>>>> preserved > > >>>> or if they MUST be selected based on the current offer/answer > > >>>> exchange. It seems the current > > >>>>> specification language is not strong or clear enough on this > > >>>>> topic. > > >>>> > > >>>> In my opinion, IF a new DTLS connection needs to be establish= ed > > >>>> (for whatever reasons), the current roles should be used. > > >>> > > >>> When ICE is NOT used, how does the offerer know that th= e > > >>> answerer does not change the fingerprint and/or transport > > parameters? > > >>> I guess it does not know. So, offerer has to be prepared for > > new DTLS > > >>> association by offering actpass. When ICE is used, the answere= r > > can't > > >>> change transport parameter unless offerer does ICE restart > (which > > >>> changes offerer transport parameters); Ref [1] is very clear o= n > > this > > >>> indicating "DTLS handshake procedure is repeated". However, > > even when > > >>> ICE is used, I do not find any restriction about answerer not > > >>> changing fingerprint. So, even without ICE restart answerer ca= n > > >>> trigger a DTLS renegotiation by changing its fingerprint. > > >>> > > >>> To conclude all this, IMO whether ICE is used or not, sending > > actpass > > >>> for all new offers may be cover all possible scenarios. > > >> > > >> That is also my conclusion based on the discussion so far. > > >> > > >> I also think the JSEP draft as far as detailed out is correct, > > but info > > >> about how the implementation should behave for Subsequent > answers is > > >> missing. Text saying that the role must be maintained (unless > > there is > > >> an ICE restart) should be put in there. > > > > > > > > > Hi Stefan, > > > Looks like, there is some misunderstanding here. > > > > Probably my fault in that case :) > > > > > My conclusion is to include > > > actpass, but not the previously negotiated role, in all subsequen= t > offers, > > > not just during ICE-restarts. > > > > I think that is what the JSEP draft says - and my conclusion is tha= t > it > > _is_ correct. > > > > My point was that the _answer_ should (when it is a subsequent > answer) > > should say the same role as in previous answers (unless there is an > ICE > > restart). > > > > I agree the JSEP text should indicate that roles should stay the same. > > We have had this as a TODO for a while: > > https://github.com/rtcweb-wg/jsep/issues/72 > > Great. I should have checked that out before. > > --001a1132f4ba2dc8eb05095d8646 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Currently, Chrome errors out (i.e. setRD fails).

<= /div>
However, I suspect that teardown of the old DTLS association and = setup of a new DTLS association is the desired behavior.

On Wed, Dec 3, 2014 at 8= :34 PM, Christer Holmberg <christer.holmberg@ericsson.com= > wrote:
Hi,

Issue #72 talks about maintaining the previously negotiated role when actpa= ss is received. I think that is a good approach, and could be used in Offer= /Answer too.

BUT, what does the browser do if e.g. the previous role is passive and acti= ve is received?

Regards,

Christer

Sent from my Windows Phone
From: Stefan H=C3= =A5kansson LK
Sent: =E2=80= =8E03/=E2=80=8E12/=E2=80=8E2014 17:48
To: Justin Uberti<= br> Cc: Makaraju, M= aridi Raju (Raju); Christe= r Holmberg; Roman Shpount; rtc= web@ietf.org
Subject: Re: [r= tcweb] JSEP: Why always offer actpass?

On 01/12/14 18:26, Justin Uberti wrote:
>
>
> On Sun, Nov 30, 2014 at 7:26 AM, Stefan H=C3=A5kansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>=C2=A0=C2=A0=C2=A0=C2=A0 On 30/11/14 16:06, Makaraju, Maridi Raju (Raju= ) wrote:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> On 30/11/14 14:51, Makaraju, Ma= ridi Raju (Raju) wrote:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> Hi,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> RFC 7345 (UDPTL= -DTLS) says the following:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> "Once an o= ffer/answer exchange has been completed, either
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> endpoint
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> MAY
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> send a new offe= r in order to modify the session.=C2=A0 The
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> endpoints
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> can
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> reuse the exist= ing DTLS association if the key fingerprint
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> values
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> and
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> transport param= eters indicated by each endpoint are unchanged.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> Otherwise, foll= owing the rules for the initial offer/answer
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> exchange,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> the endpoints c= an negotiate and create a new DTLS association
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> and, once creat= ed, delete the previous DTLS association,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> following the s= ame rules for the initial offer/answer exchange.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> Each endpoint n= eeds to be prepared to receive data on both the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> new and old DTL= S associations as long as both are alive."
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> So, I guess tha= t can be read in a way that the setup attribute
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> as such
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> does not impact previou= sly
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> negotiated TLS = roles - unless the key fingerprint values and/or
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> transport
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> parameters are modified= .
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> The SCTP-SDP dr= aft currently says that a subsequent offer must
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> not change
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> the previously negotiat= ed roles. But, I guess
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> we could say so= mething similar as in RFC 7345.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> I have struggled wi= th this language quite a bit from the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> implementation
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> perspective. I think we= need to explicitly state
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> that endpoints MUST= reuse the existing association if the key
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> fingerprint
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> values and transport pa= rameters indicated
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> by each endpoint ar= e unchanged.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> We could take such gene= ral approach.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> However, for 'SCTP/= DTLS' (DTLS over SCTP), I assume that the DTLS
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> connection will also be= re-established if the underlying SCTP
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> association is re- esta= blished - even if no transport parameters
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> etc are changed.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> Also, RFC 6083 says: >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> "Each DTLS connect= ion MUST be established and terminated
>=C2=A0=C2=A0=C2=A0=C2=A0 within the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> same SCTP association.&= quot;
>=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=A0=C2=A0=C2=A0 >>>>> The way this langua= ge reads to me is that endpoints can reuse the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> existing
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> association if they wan= t to, but they can create a new one if they
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> don't. Also, when t= his new
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> association is crea= ted, it is unclear if old setup roles MUST be
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> preserved
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> or if they MUST be sele= cted based on the current offer/answer
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> exchange. It seems the = current
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> specification langu= age is not strong or clear enough on this
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> topic.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> In my opinion, IF a new= DTLS connection needs to be established
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> (for whatever reasons),= the current roles should be used.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> <Raju> When ICE is NO= T used, how does the offerer know that the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> answerer does not change th= e fingerprint and/or transport
>=C2=A0=C2=A0=C2=A0=C2=A0 parameters?
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> I guess it does not know. S= o, offerer has to be prepared for
>=C2=A0=C2=A0=C2=A0=C2=A0 new DTLS
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> association by offering act= pass. When ICE is used, the answerer
>=C2=A0=C2=A0=C2=A0=C2=A0 can't
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> change transport parameter = unless offerer does ICE restart (which
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> changes offerer transport p= arameters); Ref [1] is very clear on
>=C2=A0=C2=A0=C2=A0=C2=A0 this
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> indicating "DTLS hands= hake procedure is repeated". However,
>=C2=A0=C2=A0=C2=A0=C2=A0 even when
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> ICE is used, I do not find = any restriction about answerer not
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> changing fingerprint. So, e= ven without ICE restart answerer can
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> trigger a DTLS renegotiatio= n by changing its fingerprint.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> To conclude all this, IMO w= hether ICE is used or not, sending
>=C2=A0=C2=A0=C2=A0=C2=A0 actpass
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> for all new offers may be c= over all possible scenarios.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> That is also my conclusion base= d on the discussion so far.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> I also think the JSEP draft as = far as detailed out is correct,
>=C2=A0=C2=A0=C2=A0=C2=A0 but info
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> about how the implementation sh= ould behave for Subsequent answers is
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> missing. Text saying that the r= ole must be maintained (unless
>=C2=A0=C2=A0=C2=A0=C2=A0 there is
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> an ICE restart) should be put i= n there.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <Raju>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Hi Stefan,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Looks like, there is some misunders= tanding here.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Probably my fault in that case :)
>
>=C2=A0=C2=A0=C2=A0=C2=A0 > My conclusion is to include
>=C2=A0=C2=A0=C2=A0=C2=A0 > actpass, but not the previously negotiate= d role, in all subsequent offers,
>=C2=A0=C2=A0=C2=A0=C2=A0 > not just during ICE-restarts.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 I think that is what the JSEP draft says - and= my conclusion is that it
>=C2=A0=C2=A0=C2=A0=C2=A0 _is_ correct.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 My point was that the _answer_ should (when it= is a subsequent answer)
>=C2=A0=C2=A0=C2=A0=C2=A0 should say the same role as in previous answer= s (unless there is an ICE
>=C2=A0=C2=A0=C2=A0=C2=A0 restart).
>
> I agree the JSEP text should indicate that roles should stay the same.=
> We have had this as a TODO for a while:
> https://github.com/rtcweb-wg/jsep/issues/72

Great. I should have checked that out before.

--001a1132f4ba2dc8eb05095d8646-- From nobody Wed Dec 3 22:28:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FB31A88CB for ; Wed, 3 Dec 2014 22:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTAFMryycSjk for ; Wed, 3 Dec 2014 22:28:21 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBBE31A88C8 for ; Wed, 3 Dec 2014 22:28:20 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-e9-547fff023dc3 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 1D.C8.24955.20FFF745; Thu, 4 Dec 2014 07:28:19 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 07:28:18 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: [rtcweb] Unsolicited DTLS Handshake Thread-Index: AQHQDbgwjr0wkzj8TUKVKwdS4+MXBJx9xuEggAAb0wCAAAUYAIAA9eU6gAABjYCAABvl8A== Date: Thu, 4 Dec 2014 06:28:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D577B42@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D56EA42@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EDF50@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D573154@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5773BD@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D577B42ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM+JvjS7z//oQg7+/2S2m77Ox2DpVyGLG hanMFmv/tbM7sHica3jP7rFgU6nHkiU/mTxuTSkIYInisklJzcksSy3St0vgytjxeBZzQVde RfuplWwNjD3ZXYycHBICJhJvJ51kgbDFJC7cW8/WxcjFISRwhFFiwtp97BDOYkaJ9y9mM3Ux cnCwCVhIdP/TBmkQEVCTeDhrFytIDbNAG6PEy/tHwSYJCxhITJ80nRmiyFCi+fRZFpBeEYEw iSfnZUHCLAIqEifPLGUCsXkFfCX2v10Ltfg+u8TZOa9ZQRKcAoESM7qnMYLYjEDXfT+1BqyB WUBc4taT+UwQVwtILNlznhnCFpV4+fgfK8guCQEliWlb0yDK8yXu9/9jh9glKHFy5hOWCYyi s5BMmoWkbBaSsllAk5gFNCXW79KHKFGUmNL9kB3C1pBonTOXHVl8ASP7KkbR4tTipNx0I2O9 1KLM5OLi/Dy9vNSSTYzAaDy45bfqDsbLbxwPMQpwMCrx8Bqcqw8RYk0sK67MPcQozcGiJM67 8Ny8YCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MHm+y5/5VLHui3cB7vEPHJyFzXUmutt69 5wXdk9P/hIozsdze7ix1dmkEyz7bo3cOHgh9XvflyY4bwk8qE/4fmLVkTd9bsawqThkXyw19 W/hLcxdxPDjCc+H5hlML19gVec1Or50lkP3rr+CP/e4+nN6u07bqTjom8MVx88HtSnxWdhdd buzOVGIpzkg01GIuKk4EABU0rD+nAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/v2ganZEumAspXcnyKCwj2W1l_Pw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsolicited DTLS Handshake X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 06:28:23 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D577B42ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 NTc2MyBpcyBzcGVjaWZpYyB0byBTUlRQLCBidXQgdGhlcmUgYXJlIGFsc28gb3RoZXIgcHJvdG9j b2xzIHVzaW5nIERUTFMuDQoNClRoZSBPZmZlci9BbnN3ZXIgY29uc2lkZXJhdGlvbnMgc2hvdWxk IGJlIHRoZSBzYW1lIGZvciBhbGwgb2YgdGhlbSDigJMgb3RoZXJ3aXNlIHdlIHdpbGwgaGF2ZSBw cm9ibGVtcyBlLmcuIGluIEJVTkRMRSwgaWYgZGlmZmVyZW50IHByb3RvY29scyB3aXRoaW4gYSBC VU5ETEUgZ3JvdXAgdXNlIGRpZmZlcmVudCBydWxlcyBmb3IgbmVnb3RpYXRpbmcgVExTIHJvbGVz IGV0Y+KApg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBKdXN0aW4gVWJlcnRpIFtt YWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KU2VudDogNC4gam91bHVrdXV0YSAyMDE0IDc6NDcN ClRvOiBDaHJpc3RlciBIb2xtYmVyZw0KQ2M6IEnDsWFraSBCYXogQ2FzdGlsbG87IFJvbWFuIFNo cG91bnQ7IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFVuc29saWNpdGVk IERUTFMgSGFuZHNoYWtlDQoNClRoYXQgc291bmRzIGxpa2UgYSA1NzYzLWJpcy4NCg0KT24gV2Vk LCBEZWMgMywgMjAxNCBhdCA4OjQxIFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+ PiB3cm90ZToNCkhpIEluYWtpLA0KDQpNeSBpbnRlbnRpb24gaXMgbm90IHRvIGJlIGFibGUgdG8g ZG8gZXZlcnl0aGluZyB3aXRoIE8vQS4NCg0KSSBhbSB0cnlpbmcgdG8gZmlndXJlIG91dCB3aGF0 IGNhbiBiZSBkb25lIHdpdGggTy9BLCBhbmQgaG93L2lmIE8vQSBhZmZlY3RzIGV4aXN0aW5nIERU TFMgY29ubmVjdGlvbnMuDQoNCklmIHNvbWV0aGluZyBjYW4gTk9UIGJlIGRvbmUsIEkgdGhpbmsg aXQgd291bGQgYmUgZ29vZCB0byBkb2N1bWVudCBzb21ld2hlcmUuDQoNCkkgYW0gd2lsbGluZyB0 byBzdGFydCBkcmFmdGluZyBhICJUTFMgd2l0aCBTRFAgTy9BIiBkcmFmdCwgaWYgcGVvcGxlIHRo aW5rIHN1Y2ggd291bGQgYmUgdXNlZnVsLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpTZW50 IGZyb20gbXkgV2luZG93cyBQaG9uZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkZyb206IEnDsWFraSBCYXogQ2FzdGlsbG88bWFpbHRvOmliY0BhbGlheC5uZXQ+DQpTZW50OiDi gI4wMy/igI4xMi/igI4yMDE0IDE3OjAxDQpUbzogUm9tYW4gU2hwb3VudDxtYWlsdG86cm9tYW5A dGVsdXJpeC5jb20+DQpDYzogQ2hyaXN0ZXIgSG9sbWJlcmc8bWFpbHRvOmNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbT47IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFVuc29saWNpdGVkIERUTFMgSGFuZHNoYWtlDQoyMDE0 LTEyLTAzIDE1OjQzIEdNVCswMTowMCBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxt YWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PjoNCj4gSWYgdGhlIHRyYW5zcG9ydCBwYXJhbWV0ZXIg aGF2ZSBOT1QgY2hhbmdlZCwgY2FuIHRoZSBmaW5nZXJwcmludCBiZSBjaGFuZ2VkPw0KDQoNCkNv cnJlY3QgbWUgaWYgSSdtIHdyb25nLCBidXQgZHVyaW5nIGEgRFRMUy9UTFMgc2Vzc2lvbiBjZXJ0 aWZpY2F0ZXMNCmFyZSBzZW50IGp1c3Qgb25jZSwgYXQgdGhlIGJlZ2lubmluZy4gQ2hhbmdpbmcg dGhlIGE9ZmluZ2VycHJpbnQNCmF0dHJpYnV0ZSBpbiBhIG5ldyBTRFAgTy9BIHJvdW5kLXRyaXAg d2l0aG91dCBmb3JjaW5nIGEgbmV3IERUTFMNCnNlc3Npb24gc2hvdWxkIGp1c3QgYmUgY29uc2lk ZXJlZCBhbiBlcnJvci4NCg0KQWdhaW46IHdlIGFyZSB0cnlpbmcgdG8gc2lnbmFsIHRvbyBtdWNo IGluIHRoZSBTRFAuDQoNCi0tDQpJw7Fha2kgQmF6IENhc3RpbGxvDQo8aWJjQGFsaWF4Lm5ldDxt YWlsdG86aWJjQGFsaWF4Lm5ldD4+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRjd2ViDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D577B42ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4w cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjU3NjMgaXMgc3BlY2lmaWMgdG8gU1JUUCwgYnV0 IHRoZXJlIGFyZSBhbHNvIG90aGVyIHByb3RvY29scyB1c2luZyBEVExTLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhl IE9mZmVyL0Fuc3dlciBjb25zaWRlcmF0aW9ucyBzaG91bGQgYmUgdGhlIHNhbWUgZm9yIGFsbCBv ZiB0aGVtIOKAkyBvdGhlcndpc2Ugd2Ugd2lsbCBoYXZlIHByb2JsZW1zIGUuZy4gaW4gQlVORExF LCBpZiBkaWZmZXJlbnQgcHJvdG9jb2xzIHdpdGhpbiBhIEJVTkRMRQ0KIGdyb3VwIHVzZSBkaWZm ZXJlbnQgcnVsZXMgZm9yIG5lZ290aWF0aW5nIFRMUyByb2xlcyBldGPigKY8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbV0NCjxi cj4NCjxiPlNlbnQ6PC9iPiA0LiBqb3VsdWt1dXRhIDIwMTQgNzo0Nzxicj4NCjxiPlRvOjwvYj4g Q2hyaXN0ZXIgSG9sbWJlcmc8YnI+DQo8Yj5DYzo8L2I+IEnDsWFraSBCYXogQ2FzdGlsbG87IFJv bWFuIFNocG91bnQ7IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0 Y3dlYl0gVW5zb2xpY2l0ZWQgRFRMUyBIYW5kc2hha2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGF0IHNvdW5kcyBsaWtlIGEgNTc2My1iaXMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIERlYyAzLCAyMDE0IGF0IDg6 NDEgUE0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5IaSBJbmFraSw8YnI+DQo8YnI+DQpNeSBpbnRlbnRpb24gaXMgbm90IHRvIGJlIGFibGUg dG8gZG8gZXZlcnl0aGluZyB3aXRoIE8vQS48YnI+DQo8YnI+DQpJIGFtIHRyeWluZyB0byBmaWd1 cmUgb3V0IHdoYXQgY2FuIGJlIGRvbmUgd2l0aCBPL0EsIGFuZCBob3cvaWYgTy9BIGFmZmVjdHMg ZXhpc3RpbmcgRFRMUyBjb25uZWN0aW9ucy48YnI+DQo8YnI+DQpJZiBzb21ldGhpbmcgY2FuIE5P VCBiZSBkb25lLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gZG9jdW1lbnQgc29tZXdoZXJl Ljxicj4NCjxicj4NCkkgYW0gd2lsbGluZyB0byBzdGFydCBkcmFmdGluZyBhICZxdW90O1RMUyB3 aXRoIFNEUCBPL0EmcXVvdDsgZHJhZnQsIGlmIHBlb3BsZSB0aGluayBzdWNoIHdvdWxkIGJlIHVz ZWZ1bC48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0K U2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5 bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249 ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOg0KPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzppYmNAYWxp YXgubmV0IiB0YXJnZXQ9Il9ibGFuayI+ScOxYWtpIEJheiBDYXN0aWxsbzwvYT48L3NwYW4+PGJy Pg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TZW50OiA8L3NwYW4+DQo8L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igI4wMy/igI4xMi/igI4yMDE0IDE3OjAxPC9zcGFu Pjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VG86IDwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5j b20iIHRhcmdldD0iX2JsYW5rIj5Sb21hbiBTaHBvdW50PC9hPjwvc3Bhbj48YnI+DQo8Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNjOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPkNocmlzdGVyIEhvbG1iZXJnPC9hPjsNCjxhIGhyZWY9Im1haWx0 bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PC9z cGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3ViamVjdDogPC9zcGFu Pg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmU6IFtydGN3ZWJdIFVuc29saWNp dGVkIERUTFMgSGFuZHNoYWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+MjAxNC0xMi0wMyAxNTo0MyBHTVQmIzQzOzAxOjAwIFJvbWFuIFNocG91bnQgJmx0OzxhIGhy ZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVy aXguY29tPC9hPiZndDs6PGJyPg0KJmd0OyBJZiB0aGUgdHJhbnNwb3J0IHBhcmFtZXRlciBoYXZl IE5PVCBjaGFuZ2VkLCBjYW4gdGhlIGZpbmdlcnByaW50IGJlIGNoYW5nZWQ/PGJyPg0KPGJyPg0K PGJyPg0KQ29ycmVjdCBtZSBpZiBJJ20gd3JvbmcsIGJ1dCBkdXJpbmcgYSBEVExTL1RMUyBzZXNz aW9uIGNlcnRpZmljYXRlczxicj4NCmFyZSBzZW50IGp1c3Qgb25jZSwgYXQgdGhlIGJlZ2lubmlu Zy4gQ2hhbmdpbmcgdGhlIGE9ZmluZ2VycHJpbnQ8YnI+DQphdHRyaWJ1dGUgaW4gYSBuZXcgU0RQ IE8vQSByb3VuZC10cmlwIHdpdGhvdXQgZm9yY2luZyBhIG5ldyBEVExTPGJyPg0Kc2Vzc2lvbiBz aG91bGQganVzdCBiZSBjb25zaWRlcmVkIGFuIGVycm9yLjxicj4NCjxicj4NCkFnYWluOiB3ZSBh cmUgdHJ5aW5nIHRvIHNpZ25hbCB0b28gbXVjaCBpbiB0aGUgU0RQLjxicj4NCjxicj4NCi0tIDxi cj4NCknDsWFraSBCYXogQ2FzdGlsbG88YnI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmliY0BhbGlh eC5uZXQiIHRhcmdldD0iX2JsYW5rIj5pYmNAYWxpYXgubmV0PC9hPiZndDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D577B42ESESSMB209erics_-- From nobody Wed Dec 3 22:30:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E3C1A88C8 for ; Wed, 3 Dec 2014 22:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yh8gYLvlmu0d for ; Wed, 3 Dec 2014 22:30:25 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB181A88CF for ; Wed, 3 Dec 2014 22:30:20 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-fa-547fff7af393 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F9.E4.04076.A7FFF745; Thu, 4 Dec 2014 07:30:18 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 07:30:18 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAHfyaaUAACD+YAAA3cSQA== Date: Thu, 4 Dec 2014 06:30:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D577B77@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE2BC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577322@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D577B77ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM+JvjW7V//oQgzMXjS22ThWyaNh4hdVi xoWpzBZr/7WzO7B4tD7by+qxYFOpx5IlP5k8bk0pCGCJ4rJJSc3JLEst0rdL4MqY/Ow1Y8GS yUwVt45+Zmtg7Ohh6mLk5JAQMJG4fmYVC4QtJnHh3nq2LkYuDiGBI4wSEz89gnIWM0rsfPES qIODg03AQqL7nzZIg4iAmsTDWbtYQWqYBR4wSnyZ+RpsqrCAqcT7uUeYIYrMJBaenMAI0isi 4CQx87ctSJhFQEXi6oLLrCA2r4CvxP9vE1ghdj3gklh1fT3YHE6BQIm2RZsZQWxGoOu+n1oD FmcWEJe49WQ+1AcCEkv2nGeGsEUlXj7+xwqyS0JASWLa1jSI8nyJ1V9OM0HsEpQ4OfMJywRG 0VlIJs1CUjYLSdksoEnMApoS63fpQ5QoSkzpfsgOYWtItM6Zy44svoCRfRWjaHFqcXFuupGR XmpRZnJxcX6eXl5qySZGYEwe3PLbagfjweeOhxgFOBiVeHgNztWHCLEmlhVX5h5ilOZgURLn XXhuXrCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxpiby9gX9Bz9tcP2eYvpxNLa2SyqtbsU r2t09XyQYv8f2mM9e3p59OS3Zd4LpoZrmW1pmiicsEX1XJLIzpikBrtn2Wt4FS9ePa6/Ifig V9+3+183mVyp+3Fbe5JIhbtb3lVvmYpLp1n/dbzf5yWxvWl10N6lim6/p7S2nDWyLL4hV/9D p/MDpxJLcUaioRZzUXEiAEcvd7CqAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MzRxkVmtBgFw8ayoyPYtHLQ1rs8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 06:30:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D577B77ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClNvLCBvbmUgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBzYXkgdGhhdCwgSUYgb25lICh0 aGVyZSBvZmZlcmVyIG9yIGFuc3dlcmVyKSBjaGFuZ2VzIHRoZSBwcmV2aW91c2x5IG5lZ290aWF0 ZWQgcm9sZXMsIHRoZSBEVExTIGNvbm5lY3Rpb24gTVVTVCBiZSByZS1lc3RhYmxpc2hlZCDigJMg ZXZlbiBpZiB0aGUgdHJhbnNwb3J0IHBhcmFtZXRlcnMgZXRjIGFyZW7igJl0IGNoYW5nZWQuIEkg dGhpbmsgdGhhdCB3b3VsZCBiZSBhIHZlcnkgdXNlZnVsIGNsYXJpZmljYXRpb24uDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdv b2dsZS5jb21dDQpTZW50OiA0LiBqb3VsdWt1dXRhIDIwMTQgNzo0OQ0KVG86IENocmlzdGVyIEhv bG1iZXJnDQpDYzogU3RlZmFuIEjDpWthbnNzb24gTEs7IE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAo UmFqdSk7IFJvbWFuIFNocG91bnQ7IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3 ZWJdIEpTRVA6IFdoeSBhbHdheXMgb2ZmZXIgYWN0cGFzcz8NCg0KQ3VycmVudGx5LCBDaHJvbWUg ZXJyb3JzIG91dCAoaS5lLiBzZXRSRCBmYWlscykuDQoNCkhvd2V2ZXIsIEkgc3VzcGVjdCB0aGF0 IHRlYXJkb3duIG9mIHRoZSBvbGQgRFRMUyBhc3NvY2lhdGlvbiBhbmQgc2V0dXAgb2YgYSBuZXcg RFRMUyBhc3NvY2lhdGlvbiBpcyB0aGUgZGVzaXJlZCBiZWhhdmlvci4NCg0KT24gV2VkLCBEZWMg MywgMjAxNCBhdCA4OjM0IFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90 ZToNCkhpLA0KDQpJc3N1ZSAjNzIgdGFsa3MgYWJvdXQgbWFpbnRhaW5pbmcgdGhlIHByZXZpb3Vz bHkgbmVnb3RpYXRlZCByb2xlIHdoZW4gYWN0cGFzcyBpcyByZWNlaXZlZC4gSSB0aGluayB0aGF0 IGlzIGEgZ29vZCBhcHByb2FjaCwgYW5kIGNvdWxkIGJlIHVzZWQgaW4gT2ZmZXIvQW5zd2VyIHRv by4NCg0KQlVULCB3aGF0IGRvZXMgdGhlIGJyb3dzZXIgZG8gaWYgZS5nLiB0aGUgcHJldmlvdXMg cm9sZSBpcyBwYXNzaXZlIGFuZCBhY3RpdmUgaXMgcmVjZWl2ZWQ/DQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNClNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KRnJvbTogU3RlZmFuIEjDpWthbnNzb24gTEs8bWFpbHRvOnN0ZWZhbi5s ay5oYWthbnNzb25AZXJpY3Nzb24uY29tPg0KU2VudDog4oCOMDMv4oCOMTIv4oCOMjAxNCAxNzo0 OA0KVG86IEp1c3RpbiBVYmVydGk8bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbT4NCkNjOiBNYWth cmFqdSwgTWFyaWRpIFJhanUgKFJhanUpPG1haWx0bzpSYWp1Lk1ha2FyYWp1QGFsY2F0ZWwtbHVj ZW50LmNvbT47IENocmlzdGVyIEhvbG1iZXJnPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb20+OyBSb21hbiBTaHBvdW50PG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT47IHJ0Y3dl YkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJd IEpTRVA6IFdoeSBhbHdheXMgb2ZmZXIgYWN0cGFzcz8NCk9uIDAxLzEyLzE0IDE4OjI2LCBKdXN0 aW4gVWJlcnRpIHdyb3RlOg0KPg0KPg0KPiBPbiBTdW4sIE5vdiAzMCwgMjAxNCBhdCA3OjI2IEFN LCBTdGVmYW4gSMOla2Fuc3NvbiBMSw0KPiA8c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5j b208bWFpbHRvOnN0ZWZhbi5say5oYWthbnNzb25AZXJpY3Nzb24uY29tPg0KPiA8bWFpbHRvOnN0 ZWZhbi5say5oYWthbnNzb25AZXJpY3Nzb24uY29tPj4gd3JvdGU6DQo+DQo+ICAgICBPbiAzMC8x MS8xNCAxNjowNiwgTWFrYXJhanUsIE1hcmlkaSBSYWp1IChSYWp1KSB3cm90ZToNCj4gICAgICA+ PiBPbiAzMC8xMS8xNCAxNDo1MSwgTWFrYXJhanUsIE1hcmlkaSBSYWp1IChSYWp1KSB3cm90ZToN Cj4gICAgICA+Pj4+IEhpLA0KPiAgICAgID4+Pj4NCj4gICAgICA+Pj4+Pj4gUkZDIDczNDUgKFVE UFRMLURUTFMpIHNheXMgdGhlIGZvbGxvd2luZzoNCj4gICAgICA+Pj4+Pj4NCj4gICAgICA+Pj4+ Pj4gIk9uY2UgYW4gb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIGhhcyBiZWVuIGNvbXBsZXRlZCwgZWl0 aGVyDQo+ICAgICAgPj4+Pj4+IGVuZHBvaW50DQo+ICAgICAgPj4+PiBNQVkNCj4gICAgICA+Pj4+ Pj4gc2VuZCBhIG5ldyBvZmZlciBpbiBvcmRlciB0byBtb2RpZnkgdGhlIHNlc3Npb24uICBUaGUN Cj4gICAgICA+Pj4+Pj4gZW5kcG9pbnRzDQo+ICAgICAgPj4+PiBjYW4NCj4gICAgICA+Pj4+Pj4g cmV1c2UgdGhlIGV4aXN0aW5nIERUTFMgYXNzb2NpYXRpb24gaWYgdGhlIGtleSBmaW5nZXJwcmlu dA0KPiAgICAgID4+Pj4+PiB2YWx1ZXMNCj4gICAgICA+Pj4+IGFuZA0KPiAgICAgID4+Pj4+PiB0 cmFuc3BvcnQgcGFyYW1ldGVycyBpbmRpY2F0ZWQgYnkgZWFjaCBlbmRwb2ludCBhcmUgdW5jaGFu Z2VkLg0KPiAgICAgID4+Pj4+PiBPdGhlcndpc2UsIGZvbGxvd2luZyB0aGUgcnVsZXMgZm9yIHRo ZSBpbml0aWFsIG9mZmVyL2Fuc3dlcg0KPiAgICAgID4+Pj4gZXhjaGFuZ2UsDQo+ICAgICAgPj4+ Pj4+IHRoZSBlbmRwb2ludHMgY2FuIG5lZ290aWF0ZSBhbmQgY3JlYXRlIGEgbmV3IERUTFMgYXNz b2NpYXRpb24NCj4gICAgICA+Pj4+Pj4gYW5kLCBvbmNlIGNyZWF0ZWQsIGRlbGV0ZSB0aGUgcHJl dmlvdXMgRFRMUyBhc3NvY2lhdGlvbiwNCj4gICAgICA+Pj4+Pj4gZm9sbG93aW5nIHRoZSBzYW1l IHJ1bGVzIGZvciB0aGUgaW5pdGlhbCBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UuDQo+ICAgICAgPj4+ Pj4+IEVhY2ggZW5kcG9pbnQgbmVlZHMgdG8gYmUgcHJlcGFyZWQgdG8gcmVjZWl2ZSBkYXRhIG9u IGJvdGggdGhlDQo+ICAgICAgPj4+Pj4+IG5ldyBhbmQgb2xkIERUTFMgYXNzb2NpYXRpb25zIGFz IGxvbmcgYXMgYm90aCBhcmUgYWxpdmUuIg0KPiAgICAgID4+Pj4+Pg0KPiAgICAgID4+Pj4+PiBT bywgSSBndWVzcyB0aGF0IGNhbiBiZSByZWFkIGluIGEgd2F5IHRoYXQgdGhlIHNldHVwIGF0dHJp YnV0ZQ0KPiAgICAgID4+Pj4+PiBhcyBzdWNoDQo+ICAgICAgPj4+PiBkb2VzIG5vdCBpbXBhY3Qg cHJldmlvdXNseQ0KPiAgICAgID4+Pj4+PiBuZWdvdGlhdGVkIFRMUyByb2xlcyAtIHVubGVzcyB0 aGUga2V5IGZpbmdlcnByaW50IHZhbHVlcyBhbmQvb3INCj4gICAgICA+Pj4+Pj4gdHJhbnNwb3J0 DQo+ICAgICAgPj4+PiBwYXJhbWV0ZXJzIGFyZSBtb2RpZmllZC4NCj4gICAgICA+Pj4+Pj4NCj4g ICAgICA+Pj4+Pj4gVGhlIFNDVFAtU0RQIGRyYWZ0IGN1cnJlbnRseSBzYXlzIHRoYXQgYSBzdWJz ZXF1ZW50IG9mZmVyIG11c3QNCj4gICAgICA+Pj4+Pj4gbm90IGNoYW5nZQ0KPiAgICAgID4+Pj4g dGhlIHByZXZpb3VzbHkgbmVnb3RpYXRlZCByb2xlcy4gQnV0LCBJIGd1ZXNzDQo+ICAgICAgPj4+ Pj4+IHdlIGNvdWxkIHNheSBzb21ldGhpbmcgc2ltaWxhciBhcyBpbiBSRkMgNzM0NS4NCj4gICAg ICA+Pj4+Pg0KPiAgICAgID4+Pj4+IEkgaGF2ZSBzdHJ1Z2dsZWQgd2l0aCB0aGlzIGxhbmd1YWdl IHF1aXRlIGEgYml0IGZyb20gdGhlDQo+ICAgICAgPj4+Pj4gaW1wbGVtZW50YXRpb24NCj4gICAg ICA+Pj4+IHBlcnNwZWN0aXZlLiBJIHRoaW5rIHdlIG5lZWQgdG8gZXhwbGljaXRseSBzdGF0ZQ0K PiAgICAgID4+Pj4+IHRoYXQgZW5kcG9pbnRzIE1VU1QgcmV1c2UgdGhlIGV4aXN0aW5nIGFzc29j aWF0aW9uIGlmIHRoZSBrZXkNCj4gICAgICA+Pj4+PiBmaW5nZXJwcmludA0KPiAgICAgID4+Pj4g dmFsdWVzIGFuZCB0cmFuc3BvcnQgcGFyYW1ldGVycyBpbmRpY2F0ZWQNCj4gICAgICA+Pj4+PiBi eSBlYWNoIGVuZHBvaW50IGFyZSB1bmNoYW5nZWQuDQo+ICAgICAgPj4+Pg0KPiAgICAgID4+Pj4g V2UgY291bGQgdGFrZSBzdWNoIGdlbmVyYWwgYXBwcm9hY2guDQo+ICAgICAgPj4+Pg0KPiAgICAg ID4+Pj4gSG93ZXZlciwgZm9yICdTQ1RQL0RUTFMnIChEVExTIG92ZXIgU0NUUCksIEkgYXNzdW1l IHRoYXQgdGhlIERUTFMNCj4gICAgICA+Pj4+IGNvbm5lY3Rpb24gd2lsbCBhbHNvIGJlIHJlLWVz dGFibGlzaGVkIGlmIHRoZSB1bmRlcmx5aW5nIFNDVFANCj4gICAgICA+Pj4+IGFzc29jaWF0aW9u IGlzIHJlLSBlc3RhYmxpc2hlZCAtIGV2ZW4gaWYgbm8gdHJhbnNwb3J0IHBhcmFtZXRlcnMNCj4g ICAgICA+Pj4+IGV0YyBhcmUgY2hhbmdlZC4NCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+PiBBbHNv LCBSRkMgNjA4MyBzYXlzOg0KPiAgICAgID4+Pj4NCj4gICAgICA+Pj4+ICJFYWNoIERUTFMgY29u bmVjdGlvbiBNVVNUIGJlIGVzdGFibGlzaGVkIGFuZCB0ZXJtaW5hdGVkDQo+ICAgICB3aXRoaW4g dGhlDQo+ICAgICAgPj4+PiBzYW1lIFNDVFAgYXNzb2NpYXRpb24uIg0KPiAgICAgID4+Pj4NCj4g ICAgICA+Pj4+DQo+ICAgICAgPj4+Pj4gVGhlIHdheSB0aGlzIGxhbmd1YWdlIHJlYWRzIHRvIG1l IGlzIHRoYXQgZW5kcG9pbnRzIGNhbiByZXVzZSB0aGUNCj4gICAgICA+Pj4+PiBleGlzdGluZw0K PiAgICAgID4+Pj4gYXNzb2NpYXRpb24gaWYgdGhleSB3YW50IHRvLCBidXQgdGhleSBjYW4gY3Jl YXRlIGEgbmV3IG9uZSBpZiB0aGV5DQo+ICAgICAgPj4+PiBkb24ndC4gQWxzbywgd2hlbiB0aGlz IG5ldw0KPiAgICAgID4+Pj4+IGFzc29jaWF0aW9uIGlzIGNyZWF0ZWQsIGl0IGlzIHVuY2xlYXIg aWYgb2xkIHNldHVwIHJvbGVzIE1VU1QgYmUNCj4gICAgICA+Pj4+PiBwcmVzZXJ2ZWQNCj4gICAg ICA+Pj4+IG9yIGlmIHRoZXkgTVVTVCBiZSBzZWxlY3RlZCBiYXNlZCBvbiB0aGUgY3VycmVudCBv ZmZlci9hbnN3ZXINCj4gICAgICA+Pj4+IGV4Y2hhbmdlLiBJdCBzZWVtcyB0aGUgY3VycmVudA0K PiAgICAgID4+Pj4+IHNwZWNpZmljYXRpb24gbGFuZ3VhZ2UgaXMgbm90IHN0cm9uZyBvciBjbGVh ciBlbm91Z2ggb24gdGhpcw0KPiAgICAgID4+Pj4+IHRvcGljLg0KPiAgICAgID4+Pj4NCj4gICAg ICA+Pj4+IEluIG15IG9waW5pb24sIElGIGEgbmV3IERUTFMgY29ubmVjdGlvbiBuZWVkcyB0byBi ZSBlc3RhYmxpc2hlZA0KPiAgICAgID4+Pj4gKGZvciB3aGF0ZXZlciByZWFzb25zKSwgdGhlIGN1 cnJlbnQgcm9sZXMgc2hvdWxkIGJlIHVzZWQuDQo+ICAgICAgPj4+DQo+ICAgICAgPj4+IDxSYWp1 PiBXaGVuIElDRSBpcyBOT1QgdXNlZCwgaG93IGRvZXMgdGhlIG9mZmVyZXIga25vdyB0aGF0IHRo ZQ0KPiAgICAgID4+PiBhbnN3ZXJlciBkb2VzIG5vdCBjaGFuZ2UgdGhlIGZpbmdlcnByaW50IGFu ZC9vciB0cmFuc3BvcnQNCj4gICAgIHBhcmFtZXRlcnM/DQo+ICAgICAgPj4+IEkgZ3Vlc3MgaXQg ZG9lcyBub3Qga25vdy4gU28sIG9mZmVyZXIgaGFzIHRvIGJlIHByZXBhcmVkIGZvcg0KPiAgICAg bmV3IERUTFMNCj4gICAgICA+Pj4gYXNzb2NpYXRpb24gYnkgb2ZmZXJpbmcgYWN0cGFzcy4gV2hl biBJQ0UgaXMgdXNlZCwgdGhlIGFuc3dlcmVyDQo+ICAgICBjYW4ndA0KPiAgICAgID4+PiBjaGFu Z2UgdHJhbnNwb3J0IHBhcmFtZXRlciB1bmxlc3Mgb2ZmZXJlciBkb2VzIElDRSByZXN0YXJ0ICh3 aGljaA0KPiAgICAgID4+PiBjaGFuZ2VzIG9mZmVyZXIgdHJhbnNwb3J0IHBhcmFtZXRlcnMpOyBS ZWYgWzFdIGlzIHZlcnkgY2xlYXIgb24NCj4gICAgIHRoaXMNCj4gICAgICA+Pj4gaW5kaWNhdGlu ZyAiRFRMUyBoYW5kc2hha2UgcHJvY2VkdXJlIGlzIHJlcGVhdGVkIi4gSG93ZXZlciwNCj4gICAg IGV2ZW4gd2hlbg0KPiAgICAgID4+PiBJQ0UgaXMgdXNlZCwgSSBkbyBub3QgZmluZCBhbnkgcmVz dHJpY3Rpb24gYWJvdXQgYW5zd2VyZXIgbm90DQo+ICAgICAgPj4+IGNoYW5naW5nIGZpbmdlcnBy aW50LiBTbywgZXZlbiB3aXRob3V0IElDRSByZXN0YXJ0IGFuc3dlcmVyIGNhbg0KPiAgICAgID4+ PiB0cmlnZ2VyIGEgRFRMUyByZW5lZ290aWF0aW9uIGJ5IGNoYW5naW5nIGl0cyBmaW5nZXJwcmlu dC4NCj4gICAgICA+Pj4NCj4gICAgICA+Pj4gVG8gY29uY2x1ZGUgYWxsIHRoaXMsIElNTyB3aGV0 aGVyIElDRSBpcyB1c2VkIG9yIG5vdCwgc2VuZGluZw0KPiAgICAgYWN0cGFzcw0KPiAgICAgID4+ PiBmb3IgYWxsIG5ldyBvZmZlcnMgbWF5IGJlIGNvdmVyIGFsbCBwb3NzaWJsZSBzY2VuYXJpb3Mu DQo+ICAgICAgPj4NCj4gICAgICA+PiBUaGF0IGlzIGFsc28gbXkgY29uY2x1c2lvbiBiYXNlZCBv biB0aGUgZGlzY3Vzc2lvbiBzbyBmYXIuDQo+ICAgICAgPj4NCj4gICAgICA+PiBJIGFsc28gdGhp bmsgdGhlIEpTRVAgZHJhZnQgYXMgZmFyIGFzIGRldGFpbGVkIG91dCBpcyBjb3JyZWN0LA0KPiAg ICAgYnV0IGluZm8NCj4gICAgICA+PiBhYm91dCBob3cgdGhlIGltcGxlbWVudGF0aW9uIHNob3Vs ZCBiZWhhdmUgZm9yIFN1YnNlcXVlbnQgYW5zd2VycyBpcw0KPiAgICAgID4+IG1pc3NpbmcuIFRl eHQgc2F5aW5nIHRoYXQgdGhlIHJvbGUgbXVzdCBiZSBtYWludGFpbmVkICh1bmxlc3MNCj4gICAg IHRoZXJlIGlzDQo+ICAgICAgPj4gYW4gSUNFIHJlc3RhcnQpIHNob3VsZCBiZSBwdXQgaW4gdGhl cmUuDQo+ICAgICAgPg0KPiAgICAgID4gPFJhanU+DQo+ICAgICAgPiBIaSBTdGVmYW4sDQo+ICAg ICAgPiBMb29rcyBsaWtlLCB0aGVyZSBpcyBzb21lIG1pc3VuZGVyc3RhbmRpbmcgaGVyZS4NCj4N Cj4gICAgIFByb2JhYmx5IG15IGZhdWx0IGluIHRoYXQgY2FzZSA6KQ0KPg0KPiAgICAgPiBNeSBj b25jbHVzaW9uIGlzIHRvIGluY2x1ZGUNCj4gICAgID4gYWN0cGFzcywgYnV0IG5vdCB0aGUgcHJl dmlvdXNseSBuZWdvdGlhdGVkIHJvbGUsIGluIGFsbCBzdWJzZXF1ZW50IG9mZmVycywNCj4gICAg ID4gbm90IGp1c3QgZHVyaW5nIElDRS1yZXN0YXJ0cy4NCj4NCj4gICAgIEkgdGhpbmsgdGhhdCBp cyB3aGF0IHRoZSBKU0VQIGRyYWZ0IHNheXMgLSBhbmQgbXkgY29uY2x1c2lvbiBpcyB0aGF0IGl0 DQo+ICAgICBfaXNfIGNvcnJlY3QuDQo+DQo+ICAgICBNeSBwb2ludCB3YXMgdGhhdCB0aGUgX2Fu c3dlcl8gc2hvdWxkICh3aGVuIGl0IGlzIGEgc3Vic2VxdWVudCBhbnN3ZXIpDQo+ICAgICBzaG91 bGQgc2F5IHRoZSBzYW1lIHJvbGUgYXMgaW4gcHJldmlvdXMgYW5zd2VycyAodW5sZXNzIHRoZXJl IGlzIGFuIElDRQ0KPiAgICAgcmVzdGFydCkuDQo+DQo+IEkgYWdyZWUgdGhlIEpTRVAgdGV4dCBz aG91bGQgaW5kaWNhdGUgdGhhdCByb2xlcyBzaG91bGQgc3RheSB0aGUgc2FtZS4NCj4gV2UgaGF2 ZSBoYWQgdGhpcyBhcyBhIFRPRE8gZm9yIGEgd2hpbGU6DQo+IGh0dHBzOi8vZ2l0aHViLmNvbS9y dGN3ZWItd2cvanNlcC9pc3N1ZXMvNzINCg0KR3JlYXQuIEkgc2hvdWxkIGhhdmUgY2hlY2tlZCB0 aGF0IG91dCBiZWZvcmUuDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D577B77ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4w cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28sIG9uZSBzdWdnZXN0 aW9uIHdvdWxkIGJlIHRvIHNheSB0aGF0LCBJRiBvbmUgKHRoZXJlIG9mZmVyZXIgb3IgYW5zd2Vy ZXIpIGNoYW5nZXMgdGhlIHByZXZpb3VzbHkgbmVnb3RpYXRlZCByb2xlcywgdGhlIERUTFMgY29u bmVjdGlvbiBNVVNUIGJlIHJlLWVzdGFibGlzaGVkDQog4oCTIGV2ZW4gaWYgdGhlIHRyYW5zcG9y dCBwYXJhbWV0ZXJzIGV0YyBhcmVu4oCZdCBjaGFuZ2VkLiBJIHRoaW5rIHRoYXQgd291bGQgYmUg YSB2ZXJ5IHVzZWZ1bCBjbGFyaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0 aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IDQuIGpvdWx1a3V1dGEgMjAxNCA3OjQ5PGJyPg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVy Zzxicj4NCjxiPkNjOjwvYj4gU3RlZmFuIEjDpWthbnNzb24gTEs7IE1ha2FyYWp1LCBNYXJpZGkg UmFqdSAoUmFqdSk7IFJvbWFuIFNocG91bnQ7IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW3J0Y3dlYl0gSlNFUDogV2h5IGFsd2F5cyBvZmZlciBhY3RwYXNzPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkN1cnJlbnRseSwgQ2hyb21lIGVycm9y cyBvdXQgKGkuZS4gc2V0UkQgZmFpbHMpLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SG93ZXZlciwgSSBzdXNwZWN0IHRoYXQgdGVhcmRvd24gb2YgdGhlIG9s ZCBEVExTIGFzc29jaWF0aW9uIGFuZCBzZXR1cCBvZiBhIG5ldyBEVExTIGFzc29jaWF0aW9uIGlz IHRoZSBkZXNpcmVkIGJlaGF2aW9yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIERlYyAzLCAyMDE0IGF0IDg6MzQgUE0sIENocmlz dGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSw8YnI+ DQo8YnI+DQpJc3N1ZSAjNzIgdGFsa3MgYWJvdXQgbWFpbnRhaW5pbmcgdGhlIHByZXZpb3VzbHkg bmVnb3RpYXRlZCByb2xlIHdoZW4gYWN0cGFzcyBpcyByZWNlaXZlZC4gSSB0aGluayB0aGF0IGlz IGEgZ29vZCBhcHByb2FjaCwgYW5kIGNvdWxkIGJlIHVzZWQgaW4gT2ZmZXIvQW5zd2VyIHRvby48 YnI+DQo8YnI+DQpCVVQsIHdoYXQgZG9lcyB0aGUgYnJvd3NlciBkbyBpZiBlLmcuIHRoZSBwcmV2 aW91cyByb2xlIGlzIHBhc3NpdmUgYW5kIGFjdGl2ZSBpcyByZWNlaXZlZD88YnI+DQo8YnI+DQpS ZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IFdpbmRv d3MgUGhvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2Vu dGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpzdGVmYW4ubGsuaGFrYW5zc29uQGVyaWNz c29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlN0ZWZhbiBIw6VrYW5zc29uIExLPC9hPjwvc3Bhbj48 YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlbnQ6IDwvc3Bhbj4NCjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAjjAzL+KAjjEyL+KAjjIwMTQgMTc6NDg8L3Nw YW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UbzogPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdvb2ds ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5KdXN0aW4gVWJlcnRpPC9hPjwvc3Bhbj48YnI+DQo8Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNjOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOlJhanUuTWFrYXJhanVAYWxjYXRlbC1sdWNl bnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWFrYXJhanUsIE1hcmlkaSBSYWp1IChSYWp1KTwvYT47 DQo8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9 Il9ibGFuayI+Q2hyaXN0ZXIgSG9sbWJlcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRl bHVyaXguY29tIiB0YXJnZXQ9Il9ibGFuayI+Um9tYW4gU2hwb3VudDwvYT47IDxhIGhyZWY9Im1h aWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnJ0Y3dlYkBpZXRmLm9yZzwv YT48L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWJqZWN0OiA8 L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZTogW3J0Y3dlYl0gSlNF UDogV2h5IGFsd2F5cyBvZmZlciBhY3RwYXNzPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5P biAwMS8xMi8xNCAxODoyNiwgSnVzdGluIFViZXJ0aSB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDsgT24gU3VuLCBOb3YgMzAsIDIwMTQgYXQgNzoyNiBBTSwgU3RlZmFuIEjDpWth bnNzb24gTEs8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3RlZmFuLmxrLmhha2Fuc3Nv bkBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5zdGVmYW4ubGsuaGFrYW5zc29uQGVyaWNz c29uLmNvbTwvYT48YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3RlZmFuLmxrLmhha2Fu c3NvbkBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c3RlZmFuLmxrLmhha2Fu c3NvbkBlcmljc3Nvbi5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT24gMzAvMTEvMTQgMTY6MDYsIE1ha2FyYWp1LCBNYXJp ZGkgUmFqdSAoUmFqdSkgd3JvdGU6PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7Jmd0OyBPbiAzMC8xMS8xNCAxNDo1MSwgTWFrYXJhanUsIE1hcmlkaSBSYWp1IChS YWp1KSB3cm90ZTo8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsgSGksPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUkZDIDczNDUgKFVEUFRMLURUTFMpIHNheXMgdGhlIGZv bGxvd2luZzo8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZxdW90O09uY2UgYW4gb2ZmZXIvYW5zd2VyIGV4Y2hh bmdlIGhhcyBiZWVuIGNvbXBsZXRlZCwgZWl0aGVyPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZW5kcG9pbnQ8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgTUFZPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgc2VuZCBhIG5ldyBvZmZlciBpbiBvcmRlciB0byBtb2RpZnkgdGhlIHNlc3Npb24uJm5ic3A7 IFRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGVuZHBvaW50czxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBjYW48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZXVzZSB0aGUgZXhpc3RpbmcgRFRM UyBhc3NvY2lhdGlvbiBpZiB0aGUga2V5IGZpbmdlcnByaW50PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdmFsdWVzPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFuZDxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHRyYW5zcG9ydCBwYXJhbWV0ZXJzIGluZGljYXRlZCBieSBlYWNoIGVuZHBvaW50IGFy ZSB1bmNoYW5nZWQuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT3RoZXJ3aXNlLCBmb2xsb3dpbmcgdGhlIHJ1bGVzIGZvciB0 aGUgaW5pdGlhbCBvZmZlci9hbnN3ZXI8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgZXhjaGFuZ2UsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIGVuZHBvaW50cyBj YW4gbmVnb3RpYXRlIGFuZCBjcmVhdGUgYSBuZXcgRFRMUyBhc3NvY2lhdGlvbjxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFu ZCwgb25jZSBjcmVhdGVkLCBkZWxldGUgdGhlIHByZXZpb3VzIERUTFMgYXNzb2NpYXRpb24sPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgZm9sbG93aW5nIHRoZSBzYW1lIHJ1bGVzIGZvciB0aGUgaW5pdGlhbCBvZmZlci9hbnN3 ZXIgZXhjaGFuZ2UuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRWFjaCBlbmRwb2ludCBuZWVkcyB0byBiZSBwcmVwYXJlZCB0 byByZWNlaXZlIGRhdGEgb24gYm90aCB0aGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZXcgYW5kIG9sZCBEVExTIGFzc29j aWF0aW9ucyBhcyBsb25nIGFzIGJvdGggYXJlIGFsaXZlLiZxdW90Ozxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg U28sIEkgZ3Vlc3MgdGhhdCBjYW4gYmUgcmVhZCBpbiBhIHdheSB0aGF0IHRoZSBzZXR1cCBhdHRy aWJ1dGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBhcyBzdWNoPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IGRvZXMgbm90IGltcGFjdCBwcmV2aW91c2x5PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg bmVnb3RpYXRlZCBUTFMgcm9sZXMgLSB1bmxlc3MgdGhlIGtleSBmaW5nZXJwcmludCB2YWx1ZXMg YW5kL29yPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgdHJhbnNwb3J0PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IHBhcmFtZXRlcnMgYXJlIG1vZGlmaWVkLjxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgVGhlIFNDVFAtU0RQIGRyYWZ0IGN1cnJlbnRseSBzYXlzIHRoYXQgYSBzdWJzZXF1 ZW50IG9mZmVyIG11c3Q8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBub3QgY2hhbmdlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBwcmV2aW91c2x5IG5lZ290aWF0 ZWQgcm9sZXMuIEJ1dCwgSSBndWVzczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdlIGNvdWxkIHNheSBzb21ldGhpbmcgc2lt aWxhciBhcyBpbiBSRkMgNzM0NS48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGhhdmUgc3RydWdnbGVkIHdpdGggdGhpcyBs YW5ndWFnZSBxdWl0ZSBhIGJpdCBmcm9tIHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW1wbGVtZW50YXRpb248YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgcGVyc3BlY3Rp dmUuIEkgdGhpbmsgd2UgbmVlZCB0byBleHBsaWNpdGx5IHN0YXRlPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGF0IGVuZHBvaW50 cyBNVVNUIHJldXNlIHRoZSBleGlzdGluZyBhc3NvY2lhdGlvbiBpZiB0aGUga2V5PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmaW5n ZXJwcmludDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyB2YWx1ZXMgYW5kIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIGluZGljYXRlZDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYnkg ZWFjaCBlbmRwb2ludCBhcmUgdW5jaGFuZ2VkLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBXZSBjb3VsZCB0YWtlIHN1Y2ggZ2VuZXJhbCBh cHByb2FjaC48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsgSG93ZXZlciwgZm9yICdTQ1RQL0RUTFMnIChEVExTIG92ZXIgU0NUUCksIEkgYXNz dW1lIHRoYXQgdGhlIERUTFM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyZndDsgY29ubmVjdGlvbiB3aWxsIGFsc28gYmUgcmUtZXN0YWJsaXNoZWQg aWYgdGhlIHVuZGVybHlpbmcgU0NUUDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBhc3NvY2lhdGlvbiBpcyByZS0gZXN0YWJsaXNoZWQgLSBl dmVuIGlmIG5vIHRyYW5zcG9ydCBwYXJhbWV0ZXJzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IGV0YyBhcmUgY2hhbmdlZC48YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgQWxzbywgUkZD IDYwODMgc2F5czo8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsgJnF1b3Q7RWFjaCBEVExTIGNvbm5lY3Rpb24gTVVTVCBiZSBlc3RhYmxpc2hl ZCBhbmQgdGVybWluYXRlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2l0aGlu IHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyBzYW1lIFNDVFAgYXNzb2NpYXRpb24uJnF1b3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgd2F5IHRoaXMgbGFuZ3Vh Z2UgcmVhZHMgdG8gbWUgaXMgdGhhdCBlbmRwb2ludHMgY2FuIHJldXNlIHRoZTxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZXhpc3Rp bmc8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDsgYXNzb2NpYXRpb24gaWYgdGhleSB3YW50IHRvLCBidXQgdGhleSBjYW4gY3JlYXRlIGEgbmV3 IG9uZSBpZiB0aGV5PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7IGRvbid0LiBBbHNvLCB3aGVuIHRoaXMgbmV3PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhc3NvY2lhdGlvbiBp cyBjcmVhdGVkLCBpdCBpcyB1bmNsZWFyIGlmIG9sZCBzZXR1cCByb2xlcyBNVVNUIGJlPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBw cmVzZXJ2ZWQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsgb3IgaWYgdGhleSBNVVNUIGJlIHNlbGVjdGVkIGJhc2VkIG9uIHRoZSBjdXJyZW50 IG9mZmVyL2Fuc3dlcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZndDsmZ3Q7Jmd0OyBleGNoYW5nZS4gSXQgc2VlbXMgdGhlIGN1cnJlbnQ8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNwZWNpZmlj YXRpb24gbGFuZ3VhZ2UgaXMgbm90IHN0cm9uZyBvciBjbGVhciBlbm91Z2ggb24gdGhpczxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg dG9waWMuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7IEluIG15IG9waW5pb24sIElGIGEgbmV3IERUTFMgY29ubmVjdGlvbiBuZWVkcyB0byBi ZSBlc3RhYmxpc2hlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZndDsmZ3Q7Jmd0OyAoZm9yIHdoYXRldmVyIHJlYXNvbnMpLCB0aGUgY3VycmVudCByb2xlcyBz aG91bGQgYmUgdXNlZC48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7ICZsdDtSYWp1Jmd0OyBXaGVuIElDRSBpcyBOT1QgdXNlZCwgaG93IGRvZXMgdGhlIG9m ZmVyZXIga25vdyB0aGF0IHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyZndDsmZ3Q7IGFuc3dlcmVyIGRvZXMgbm90IGNoYW5nZSB0aGUgZmluZ2VycHJpbnQg YW5kL29yIHRyYW5zcG9ydDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGFyYW1l dGVycz88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyBJIGd1ZXNzIGl0IGRvZXMgbm90IGtub3cuIFNvLCBvZmZlcmVyIGhhcyB0byBiZSBwcmVwYXJl ZCBmb3I8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5ldyBEVExTPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgYXNzb2NpYXRpb24g Ynkgb2ZmZXJpbmcgYWN0cGFzcy4gV2hlbiBJQ0UgaXMgdXNlZCwgdGhlIGFuc3dlcmVyPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjYW4ndDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IGNoYW5nZSB0cmFuc3BvcnQgcGFyYW1ldGVy IHVubGVzcyBvZmZlcmVyIGRvZXMgSUNFIHJlc3RhcnQgKHdoaWNoPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgY2hhbmdlcyBvZmZlcmVyIHRyYW5z cG9ydCBwYXJhbWV0ZXJzKTsgUmVmIFsxXSBpcyB2ZXJ5IGNsZWFyIG9uPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB0aGlzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsgaW5kaWNhdGluZyAmcXVvdDtEVExTIGhhbmRzaGFrZSBwcm9j ZWR1cmUgaXMgcmVwZWF0ZWQmcXVvdDsuIEhvd2V2ZXIsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBldmVuIHdoZW48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyBJQ0UgaXMgdXNlZCwgSSBkbyBub3QgZmluZCBhbnkgcmVzdHJpY3Rp b24gYWJvdXQgYW5zd2VyZXIgbm90PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7Jmd0OyZndDsgY2hhbmdpbmcgZmluZ2VycHJpbnQuIFNvLCBldmVuIHdpdGhvdXQg SUNFIHJlc3RhcnQgYW5zd2VyZXIgY2FuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsgdHJpZ2dlciBhIERUTFMgcmVuZWdvdGlhdGlvbiBieSBjaGFu Z2luZyBpdHMgZmluZ2VycHJpbnQuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyBUbyBjb25jbHVkZSBhbGwgdGhpcywgSU1PIHdoZXRoZXIgSUNFIGlzIHVz ZWQgb3Igbm90LCBzZW5kaW5nPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhY3Rw YXNzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsg Zm9yIGFsbCBuZXcgb2ZmZXJzIG1heSBiZSBjb3ZlciBhbGwgcG9zc2libGUgc2NlbmFyaW9zLjxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IFRoYXQgaXMgYWxzbyBteSBj b25jbHVzaW9uIGJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uIHNvIGZhci48YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBJIGFsc28gdGhpbmsgdGhlIEpTRVAgZHJhZnQgYXMg ZmFyIGFzIGRldGFpbGVkIG91dCBpcyBjb3JyZWN0LDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgYnV0IGluZm88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmZ3Q7IGFib3V0IGhvdyB0aGUgaW1wbGVtZW50YXRpb24gc2hvdWxkIGJlaGF2ZSBmb3Ig U3Vic2VxdWVudCBhbnN3ZXJzIGlzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7Jmd0OyBtaXNzaW5nLiBUZXh0IHNheWluZyB0aGF0IHRoZSByb2xlIG11c3QgYmUg bWFpbnRhaW5lZCAodW5sZXNzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGVy ZSBpczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgYW4g SUNFIHJlc3RhcnQpIHNob3VsZCBiZSBwdXQgaW4gdGhlcmUuPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7ICZsdDtSYWp1Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyBIaSBTdGVmYW4sPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IExvb2tzIGxpa2UsIHRoZXJlIGlzIHNvbWUgbWlzdW5kZXJzdGFuZGluZyBo ZXJlLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByb2JhYmx5 IG15IGZhdWx0IGluIHRoYXQgY2FzZSA6KTxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgTXkgY29uY2x1c2lvbiBpcyB0byBpbmNsdWRlPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGFjdHBhc3MsIGJ1dCBub3QgdGhlIHByZXZpb3Vz bHkgbmVnb3RpYXRlZCByb2xlLCBpbiBhbGwgc3Vic2VxdWVudCBvZmZlcnMsPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IG5vdCBqdXN0IGR1cmluZyBJQ0UtcmVzdGFydHMu PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSB0aGluayB0aGF0 IGlzIHdoYXQgdGhlIEpTRVAgZHJhZnQgc2F5cyAtIGFuZCBteSBjb25jbHVzaW9uIGlzIHRoYXQg aXQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IF9pc18gY29ycmVjdC48YnI+DQom Z3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNeSBwb2ludCB3YXMgdGhhdCB0 aGUgX2Fuc3dlcl8gc2hvdWxkICh3aGVuIGl0IGlzIGEgc3Vic2VxdWVudCBhbnN3ZXIpPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzaG91bGQgc2F5IHRoZSBzYW1lIHJvbGUgYXMg aW4gcHJldmlvdXMgYW5zd2VycyAodW5sZXNzIHRoZXJlIGlzIGFuIElDRTxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVzdGFydCkuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBhZ3Jl ZSB0aGUgSlNFUCB0ZXh0IHNob3VsZCBpbmRpY2F0ZSB0aGF0IHJvbGVzIHNob3VsZCBzdGF5IHRo ZSBzYW1lLjxicj4NCiZndDsgV2UgaGF2ZSBoYWQgdGhpcyBhcyBhIFRPRE8gZm9yIGEgd2hpbGU6 PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAvaXNz dWVzLzcyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13Zy9qc2Vw L2lzc3Vlcy83MjwvYT48YnI+DQo8YnI+DQpHcmVhdC4gSSBzaG91bGQgaGF2ZSBjaGVja2VkIHRo YXQgb3V0IGJlZm9yZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D577B77ESESSMB209erics_-- From nobody Wed Dec 3 22:53:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393C91A88D0 for ; Wed, 3 Dec 2014 22:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcqiMSzxuyAc for ; Wed, 3 Dec 2014 22:52:56 -0800 (PST) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3451A88CB for ; Wed, 3 Dec 2014 22:52:55 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id hq12so7441829vcb.7 for ; Wed, 03 Dec 2014 22:52:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kBssoIZtzBjUTt8e205sFKorNGUJyJNF6n/PBRVbnAg=; b=BjI2OdwUJ2hZngpehcsjJzgsjJHFMrulF40owsPytZxGu4zfJCG+Y11eAMg5UXFhF/ zclDypfcSDZtuE1BO68PJaZMN5Z7y6lur1PEQq+g6IOt02IeolDbyVH0mrdb0IQPydoM Kmd8c7kEe9b02PhLijphhQWASN7aI+CMyRPS3A9uWKtj7jNoj6ICHuNPE4xK6R3TDaqD BP3XmacUMIhQf4pTEKahBuHVZXyRgZ3LLhByJWiEfy11YUkEHqnIW6AwbZmYqTBVTze/ 5vi90SAp3yUCDBS95qFHxifxomEULKYGA/yfuck8keOmv4Y4V6RpBZ1PvOijmOQiPx4U uqHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kBssoIZtzBjUTt8e205sFKorNGUJyJNF6n/PBRVbnAg=; b=JtotMNBl6bmdJa6AnGLCpXxSazVaOJYxgG1A/Owuf6VnLEkkc3Nr3EYzUqgrPw4s7V p7u6hQ3aqjIhsY6yaV9VKDvkaoeHLXbz4l+04ixQ9qhZMWJMVptOLil9ySUBU7xI20g4 KgzUK+5QAKuCNwFrNkhjvTIxNeY8k3AgmOBJxSUAbQoiXAsnIlgNKouhRI6Y1uwGq+nD 1vyGRlXLvvg8VzI10qF4yORx3lh/dzAOsZAcXrk3LyTNNMsI/tNuCCfhscpCJNIhkchI jAv2ZWy4QL26KmNvZTjZooykyY4YH7fb3ZjDfxJ9J7Hy7yESR/mdK8MvknPo0zIuP+Tw bfEg== X-Gm-Message-State: ALoCoQlm6Oh8bLoVEEf51DRDln9anzkDRCogrL/ACl/XODZ5GdPDq58mkflWN9XlgfdN71RtRD4z X-Received: by 10.220.178.3 with SMTP id bk3mr3601561vcb.16.1417675975043; Wed, 03 Dec 2014 22:52:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Wed, 3 Dec 2014 22:52:34 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D577B77@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE2BC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577322@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577B77@ESESSMB209.ericsson.se> From: Justin Uberti Date: Wed, 3 Dec 2014 22:52:34 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c1d370e6556305095e682c Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9hbsIwt18BKJU9gMdFYmJcaPRro Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 06:52:59 -0000 --001a11c1d370e6556305095e682c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 5763, S 6.6 seems to imply that: Note that if the active/passive status of the endpoints changes, a new connection MUST be established. On Wed, Dec 3, 2014 at 10:30 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > So, one suggestion would be to say that, IF one (there offerer or > answerer) changes the previously negotiated roles, the DTLS connection MU= ST > be re-established =E2=80=93 even if the transport parameters etc aren=E2= =80=99t changed. I > think that would be a very useful clarification. > > > > Regards, > > > > Christer > > > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* 4. joulukuuta 2014 7:49 > *To:* Christer Holmberg > *Cc:* Stefan H=C3=A5kansson LK; Makaraju, Maridi Raju (Raju); Roman Shpou= nt; > rtcweb@ietf.org > > *Subject:* Re: [rtcweb] JSEP: Why always offer actpass? > > > > Currently, Chrome errors out (i.e. setRD fails). > > > > However, I suspect that teardown of the old DTLS association and setup of > a new DTLS association is the desired behavior. > > > > On Wed, Dec 3, 2014 at 8:34 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > Issue #72 talks about maintaining the previously negotiated role when > actpass is received. I think that is a good approach, and could be used i= n > Offer/Answer too. > > BUT, what does the browser do if e.g. the previous role is passive and > active is received? > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > > *From: *Stefan H=C3=A5kansson LK > *Sent: *=E2=80=8E03/=E2=80=8E12/=E2=80=8E2014 17:48 > *To: *Justin Uberti > *Cc: *Makaraju, Maridi Raju (Raju) ; Ch= rister > Holmberg ; Roman Shpount > ; rtcweb@ietf.org > *Subject: *Re: [rtcweb] JSEP: Why always offer actpass? > > On 01/12/14 18:26, Justin Uberti wrote: > > > > > > On Sun, Nov 30, 2014 at 7:26 AM, Stefan H=C3=A5kansson LK > > > >> wrote: > > > > On 30/11/14 16:06, Makaraju, Maridi Raju (Raju) wrote: > > >> On 30/11/14 14:51, Makaraju, Maridi Raju (Raju) wrote: > > >>>> Hi, > > >>>> > > >>>>>> RFC 7345 (UDPTL-DTLS) says the following: > > >>>>>> > > >>>>>> "Once an offer/answer exchange has been completed, either > > >>>>>> endpoint > > >>>> MAY > > >>>>>> send a new offer in order to modify the session. The > > >>>>>> endpoints > > >>>> can > > >>>>>> reuse the existing DTLS association if the key fingerprint > > >>>>>> values > > >>>> and > > >>>>>> transport parameters indicated by each endpoint are > unchanged. > > >>>>>> Otherwise, following the rules for the initial offer/answer > > >>>> exchange, > > >>>>>> the endpoints can negotiate and create a new DTLS associati= on > > >>>>>> and, once created, delete the previous DTLS association, > > >>>>>> following the same rules for the initial offer/answer > exchange. > > >>>>>> Each endpoint needs to be prepared to receive data on both > the > > >>>>>> new and old DTLS associations as long as both are alive." > > >>>>>> > > >>>>>> So, I guess that can be read in a way that the setup > attribute > > >>>>>> as such > > >>>> does not impact previously > > >>>>>> negotiated TLS roles - unless the key fingerprint values > and/or > > >>>>>> transport > > >>>> parameters are modified. > > >>>>>> > > >>>>>> The SCTP-SDP draft currently says that a subsequent offer > must > > >>>>>> not change > > >>>> the previously negotiated roles. But, I guess > > >>>>>> we could say something similar as in RFC 7345. > > >>>>> > > >>>>> I have struggled with this language quite a bit from the > > >>>>> implementation > > >>>> perspective. I think we need to explicitly state > > >>>>> that endpoints MUST reuse the existing association if the ke= y > > >>>>> fingerprint > > >>>> values and transport parameters indicated > > >>>>> by each endpoint are unchanged. > > >>>> > > >>>> We could take such general approach. > > >>>> > > >>>> However, for 'SCTP/DTLS' (DTLS over SCTP), I assume that the > DTLS > > >>>> connection will also be re-established if the underlying SCTP > > >>>> association is re- established - even if no transport > parameters > > >>>> etc are changed. > > >>>> > > >>>> Also, RFC 6083 says: > > >>>> > > >>>> "Each DTLS connection MUST be established and terminated > > within the > > >>>> same SCTP association." > > >>>> > > >>>> > > >>>>> The way this language reads to me is that endpoints can reus= e > the > > >>>>> existing > > >>>> association if they want to, but they can create a new one if > they > > >>>> don't. Also, when this new > > >>>>> association is created, it is unclear if old setup roles MUS= T > be > > >>>>> preserved > > >>>> or if they MUST be selected based on the current offer/answer > > >>>> exchange. It seems the current > > >>>>> specification language is not strong or clear enough on this > > >>>>> topic. > > >>>> > > >>>> In my opinion, IF a new DTLS connection needs to be establish= ed > > >>>> (for whatever reasons), the current roles should be used. > > >>> > > >>> When ICE is NOT used, how does the offerer know that th= e > > >>> answerer does not change the fingerprint and/or transport > > parameters? > > >>> I guess it does not know. So, offerer has to be prepared for > > new DTLS > > >>> association by offering actpass. When ICE is used, the answere= r > > can't > > >>> change transport parameter unless offerer does ICE restart > (which > > >>> changes offerer transport parameters); Ref [1] is very clear o= n > > this > > >>> indicating "DTLS handshake procedure is repeated". However, > > even when > > >>> ICE is used, I do not find any restriction about answerer not > > >>> changing fingerprint. So, even without ICE restart answerer ca= n > > >>> trigger a DTLS renegotiation by changing its fingerprint. > > >>> > > >>> To conclude all this, IMO whether ICE is used or not, sending > > actpass > > >>> for all new offers may be cover all possible scenarios. > > >> > > >> That is also my conclusion based on the discussion so far. > > >> > > >> I also think the JSEP draft as far as detailed out is correct, > > but info > > >> about how the implementation should behave for Subsequent > answers is > > >> missing. Text saying that the role must be maintained (unless > > there is > > >> an ICE restart) should be put in there. > > > > > > > > > Hi Stefan, > > > Looks like, there is some misunderstanding here. > > > > Probably my fault in that case :) > > > > > My conclusion is to include > > > actpass, but not the previously negotiated role, in all subsequen= t > offers, > > > not just during ICE-restarts. > > > > I think that is what the JSEP draft says - and my conclusion is tha= t > it > > _is_ correct. > > > > My point was that the _answer_ should (when it is a subsequent > answer) > > should say the same role as in previous answers (unless there is an > ICE > > restart). > > > > I agree the JSEP text should indicate that roles should stay the same. > > We have had this as a TODO for a while: > > https://github.com/rtcweb-wg/jsep/issues/72 > > Great. I should have checked that out before. > > > --001a11c1d370e6556305095e682c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
5763, S 6.6 seems to imply that:

= =C2=A0Note that if the active/passive status of the endpoints changes, a ne= w
=C2=A0connection MUST be established.


On Wed, De= c 3, 2014 at 10:30 PM, Christer Holmberg <christer.holmberg@e= ricsson.com> wrote:

Hi,<= /p>

=C2=A0

So, one suggestion would = be to say that, IF one (there offerer or answerer) changes the previously n= egotiated roles, the DTLS connection MUST be re-established =E2=80=93 even if the transport parameters etc aren=E2=80=99t changed. I t= hink that would be a very useful clarification.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: 4. joulukuuta 2014 7:49
To: Christer Holmberg
Cc: Stefan H=C3=A5kansson LK; Makaraju, Maridi Raju (Raju); Roman Sh= pount; rtcweb@ietf.org=


Subject: Re: [rtcweb] JSEP: Why always offer actpass?<= /div>

=C2=A0

Currently, Chrome errors out (i.e. setRD fails).<= /u>

=C2=A0

However, I suspect that teardown of the old DTLS ass= ociation and setup of a new DTLS association is the desired behavior.

=C2=A0

On Wed, Dec 3, 2014 at 8:34 PM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:

Hi,

Issue #72 talks about maintaining the previously negotiated role when actpa= ss is received. I think that is a good approach, and could be used in Offer= /Answer too.

BUT, what does the browser do if e.g. the previous role is passive and acti= ve is received?

Regards,

Christer

Sent from my Windows Phone

From: Stefan H=C3=A5kansson LK
Sent: =E2=80=8E03/=E2=80=8E12/=E2=80=8E2014 17:48
To: Justin Uberti
Cc: Makaraju, Maridi Raju (Raju); Christe= r Holmberg; Roman Shpount; <= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank"> rtcweb@ietf.org
Subject: Re: [rtcweb] JSEP: Why always offer actpass?=

On 01/12/14 18:26, Justin Uberti wrote:
>
>
> On Sun, Nov 30, 2014 at 7:26 AM, Stefan H=C3=A5kansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>=C2=A0=C2=A0=C2=A0=C2=A0 On 30/11/14 16:06, Makaraju, Maridi Raju (Raju= ) wrote:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> On 30/11/14 14:51, Makaraju, Ma= ridi Raju (Raju) wrote:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> Hi,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> RFC 7345 (UDPTL= -DTLS) says the following:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> "Once an o= ffer/answer exchange has been completed, either
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> endpoint
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> MAY
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> send a new offe= r in order to modify the session.=C2=A0 The
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> endpoints
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> can
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> reuse the exist= ing DTLS association if the key fingerprint
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> values
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> and
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> transport param= eters indicated by each endpoint are unchanged.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> Otherwise, foll= owing the rules for the initial offer/answer
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> exchange,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> the endpoints c= an negotiate and create a new DTLS association
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> and, once creat= ed, delete the previous DTLS association,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> following the s= ame rules for the initial offer/answer exchange.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> Each endpoint n= eeds to be prepared to receive data on both the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> new and old DTL= S associations as long as both are alive."
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> So, I guess tha= t can be read in a way that the setup attribute
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> as such
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> does not impact previou= sly
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> negotiated TLS = roles - unless the key fingerprint values and/or
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> transport
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> parameters are modified= .
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> The SCTP-SDP dr= aft currently says that a subsequent offer must
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> not change
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> the previously negotiat= ed roles. But, I guess
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> we could say so= mething similar as in RFC 7345.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> I have struggled wi= th this language quite a bit from the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> implementation
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> perspective. I think we= need to explicitly state
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> that endpoints MUST= reuse the existing association if the key
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> fingerprint
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> values and transport pa= rameters indicated
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> by each endpoint ar= e unchanged.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> We could take such gene= ral approach.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> However, for 'SCTP/= DTLS' (DTLS over SCTP), I assume that the DTLS
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> connection will also be= re-established if the underlying SCTP
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> association is re- esta= blished - even if no transport parameters
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> etc are changed.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> Also, RFC 6083 says: >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> "Each DTLS connect= ion MUST be established and terminated
>=C2=A0=C2=A0=C2=A0=C2=A0 within the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> same SCTP association.&= quot;
>=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=A0=C2=A0=C2=A0 >>>>> The way this langua= ge reads to me is that endpoints can reuse the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> existing
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> association if they wan= t to, but they can create a new one if they
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> don't. Also, when t= his new
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> association is crea= ted, it is unclear if old setup roles MUST be
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> preserved
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> or if they MUST be sele= cted based on the current offer/answer
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> exchange. It seems the = current
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> specification langu= age is not strong or clear enough on this
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> topic.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> In my opinion, IF a new= DTLS connection needs to be established
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> (for whatever reasons),= the current roles should be used.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> <Raju> When ICE is NO= T used, how does the offerer know that the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> answerer does not change th= e fingerprint and/or transport
>=C2=A0=C2=A0=C2=A0=C2=A0 parameters?
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> I guess it does not know. S= o, offerer has to be prepared for
>=C2=A0=C2=A0=C2=A0=C2=A0 new DTLS
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> association by offering act= pass. When ICE is used, the answerer
>=C2=A0=C2=A0=C2=A0=C2=A0 can't
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> change transport parameter = unless offerer does ICE restart (which
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> changes offerer transport p= arameters); Ref [1] is very clear on
>=C2=A0=C2=A0=C2=A0=C2=A0 this
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> indicating "DTLS hands= hake procedure is repeated". However,
>=C2=A0=C2=A0=C2=A0=C2=A0 even when
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> ICE is used, I do not find = any restriction about answerer not
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> changing fingerprint. So, e= ven without ICE restart answerer can
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> trigger a DTLS renegotiatio= n by changing its fingerprint.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> To conclude all this, IMO w= hether ICE is used or not, sending
>=C2=A0=C2=A0=C2=A0=C2=A0 actpass
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> for all new offers may be c= over all possible scenarios.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> That is also my conclusion base= d on the discussion so far.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> I also think the JSEP draft as = far as detailed out is correct,
>=C2=A0=C2=A0=C2=A0=C2=A0 but info
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> about how the implementation sh= ould behave for Subsequent answers is
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> missing. Text saying that the r= ole must be maintained (unless
>=C2=A0=C2=A0=C2=A0=C2=A0 there is
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> an ICE restart) should be put i= n there.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <Raju>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Hi Stefan,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Looks like, there is some misunders= tanding here.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Probably my fault in that case :)
>
>=C2=A0=C2=A0=C2=A0=C2=A0 > My conclusion is to include
>=C2=A0=C2=A0=C2=A0=C2=A0 > actpass, but not the previously negotiate= d role, in all subsequent offers,
>=C2=A0=C2=A0=C2=A0=C2=A0 > not just during ICE-restarts.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 I think that is what the JSEP draft says - and= my conclusion is that it
>=C2=A0=C2=A0=C2=A0=C2=A0 _is_ correct.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 My point was that the _answer_ should (when it= is a subsequent answer)
>=C2=A0=C2=A0=C2=A0=C2=A0 should say the same role as in previous answer= s (unless there is an ICE
>=C2=A0=C2=A0=C2=A0=C2=A0 restart).
>
> I agree the JSEP text should indicate that roles should stay the same.=
> We have had this as a TODO for a while:
> https://github.com/rtcweb-wg/jsep/issues/72

Great. I should have checked that out before.

=C2=A0


--001a11c1d370e6556305095e682c-- From nobody Wed Dec 3 22:55:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2221A88D0 for ; Wed, 3 Dec 2014 22:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vv_qbiDpdKec for ; Wed, 3 Dec 2014 22:55:26 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A7C01A88D1 for ; Wed, 3 Dec 2014 22:55:25 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-16-5480055be75d Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4A.68.04076.B5500845; Thu, 4 Dec 2014 07:55:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 07:55:23 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAHfyaaUAACD+YAAA3cSQP//9fwA///u34A= Date: Thu, 4 Dec 2014 06:55:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D577CB5@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE2BC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577322@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577B77@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D577CB5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM+JvjW40a0OIwYfPChZbpwpZNGy8wmox 48JUZou1/9rZHVg8Wp/tZfVYsKnUY8mSn0wet6YUBLBEcdmkpOZklqUW6dslcGVc33aatWDO caaK929uMDUwXtnH1MXIySEhYCLx5dcNNghbTOLCvfVANheHkMARRomp91azQDiLGSV+zLvD 2MXIwcEmYCHR/U8bpEFEQE3i4axdrCA1zAIPGCW+zHwNNlVYwFTi/dwjzBBFZhILT05ghLD9 JPo+r2IFsVkEVCQuvj8BVsMr4Cux598TqM2vuSUWL2sDa+AUCJS49ukaO4jNCHTe91NrwBYw C4hL3HoyH+oFAYkle84zQ9iiEi8f/2MFOVRCQEli2tY0iPJ8ics/N7JA7BKUODnzCcsERtFZ SCbNQlI2C0nZLKBJzAKaEut36UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0Vo2hxanFxbrqRkV5q UWZycXF+nl5easkmRmBUHtzy22oH48HnjocYBTgYlXh4Dc7VhwixJpYVV+YeYpTmYFES5114 bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbed03HvM4IPCxc8m3p7PmmamtKAl8kneaK jtvmoziLr2KCQEPg1VkyetfELIvMRdaZsNbfas8M1fc7tsZrT3rYaf894t2J+ZWSk/h02Qt2 rNpxafqE0xM+a08yfTPrR75Um+Ea1xPPkt+zK8t+2s05LTLGb9NLje2fCkyvKkxfP+HVFrZr PbuUWIozEg21mIuKEwHCjHmHqwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/II-fUR8pDGvlMCG1aIdH7-MpZRk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 06:55:30 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D577CB5ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmXZlIG1pc3NlZCB0aGF0LiBBd2Vzb21lISA6KQ0KDQpTbywgaWYgd2XigJlyZSBvayB3aXRo IHRoYXQgYXBwcm9hY2gsIHRoZW4gd2Ugc2hvdWxkIHVzZSBzaW1pbGFyIHRleHQgaW4gdGhlIFND VFAtU0RQIGRyYWZ0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBKdXN0aW4gVWJl cnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KU2VudDogNC4gam91bHVrdXV0YSAyMDE0 IDg6NTMNClRvOiBDaHJpc3RlciBIb2xtYmVyZw0KQ2M6IFN0ZWZhbiBIw6VrYW5zc29uIExLOyBN YWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUpOyBSb21hbiBTaHBvdW50OyBydGN3ZWJAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBKU0VQOiBXaHkgYWx3YXlzIG9mZmVyIGFjdHBhc3M/ DQoNCjU3NjMsIFMgNi42IHNlZW1zIHRvIGltcGx5IHRoYXQ6DQoNCiBOb3RlIHRoYXQgaWYgdGhl IGFjdGl2ZS9wYXNzaXZlIHN0YXR1cyBvZiB0aGUgZW5kcG9pbnRzIGNoYW5nZXMsIGEgbmV3DQog Y29ubmVjdGlvbiBNVVNUIGJlIGVzdGFibGlzaGVkLg0KDQoNCk9uIFdlZCwgRGVjIDMsIDIwMTQg YXQgMTA6MzAgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGks DQoNClNvLCBvbmUgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBzYXkgdGhhdCwgSUYgb25lICh0aGVy ZSBvZmZlcmVyIG9yIGFuc3dlcmVyKSBjaGFuZ2VzIHRoZSBwcmV2aW91c2x5IG5lZ290aWF0ZWQg cm9sZXMsIHRoZSBEVExTIGNvbm5lY3Rpb24gTVVTVCBiZSByZS1lc3RhYmxpc2hlZCDigJMgZXZl biBpZiB0aGUgdHJhbnNwb3J0IHBhcmFtZXRlcnMgZXRjIGFyZW7igJl0IGNoYW5nZWQuIEkgdGhp bmsgdGhhdCB3b3VsZCBiZSBhIHZlcnkgdXNlZnVsIGNsYXJpZmljYXRpb24uDQoNClJlZ2FyZHMs DQoNCkNocmlzdGVyDQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2ds ZS5jb208bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbT5dDQpTZW50OiA0LiBqb3VsdWt1dXRhIDIw MTQgNzo0OQ0KVG86IENocmlzdGVyIEhvbG1iZXJnDQpDYzogU3RlZmFuIEjDpWthbnNzb24gTEs7 IE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSk7IFJvbWFuIFNocG91bnQ7IHJ0Y3dlYkBpZXRm Lm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gSlNF UDogV2h5IGFsd2F5cyBvZmZlciBhY3RwYXNzPw0KDQpDdXJyZW50bHksIENocm9tZSBlcnJvcnMg b3V0IChpLmUuIHNldFJEIGZhaWxzKS4NCg0KSG93ZXZlciwgSSBzdXNwZWN0IHRoYXQgdGVhcmRv d24gb2YgdGhlIG9sZCBEVExTIGFzc29jaWF0aW9uIGFuZCBzZXR1cCBvZiBhIG5ldyBEVExTIGFz c29jaWF0aW9uIGlzIHRoZSBkZXNpcmVkIGJlaGF2aW9yLg0KDQpPbiBXZWQsIERlYyAzLCAyMDE0 IGF0IDg6MzQgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGks DQoNCklzc3VlICM3MiB0YWxrcyBhYm91dCBtYWludGFpbmluZyB0aGUgcHJldmlvdXNseSBuZWdv dGlhdGVkIHJvbGUgd2hlbiBhY3RwYXNzIGlzIHJlY2VpdmVkLiBJIHRoaW5rIHRoYXQgaXMgYSBn b29kIGFwcHJvYWNoLCBhbmQgY291bGQgYmUgdXNlZCBpbiBPZmZlci9BbnN3ZXIgdG9vLg0KDQpC VVQsIHdoYXQgZG9lcyB0aGUgYnJvd3NlciBkbyBpZiBlLmcuIHRoZSBwcmV2aW91cyByb2xlIGlz IHBhc3NpdmUgYW5kIGFjdGl2ZSBpcyByZWNlaXZlZD8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN Cg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmUNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpGcm9tOiBTdGVmYW4gSMOla2Fuc3NvbiBMSzxtYWlsdG86c3RlZmFuLmxrLmhha2Fu c3NvbkBlcmljc3Nvbi5jb20+DQpTZW50OiDigI4wMy/igI4xMi/igI4yMDE0IDE3OjQ4DQpUbzog SnVzdGluIFViZXJ0aTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPg0KQ2M6IE1ha2FyYWp1LCBN YXJpZGkgUmFqdSAoUmFqdSk8bWFpbHRvOlJhanUuTWFrYXJhanVAYWxjYXRlbC1sdWNlbnQuY29t PjsgQ2hyaXN0ZXIgSG9sbWJlcmc8bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bT47IFJvbWFuIFNocG91bnQ8bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPjsgcnRjd2ViQGlldGYu b3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gSlNFUDog V2h5IGFsd2F5cyBvZmZlciBhY3RwYXNzPw0KT24gMDEvMTIvMTQgMTg6MjYsIEp1c3RpbiBVYmVy dGkgd3JvdGU6DQo+DQo+DQo+IE9uIFN1biwgTm92IDMwLCAyMDE0IGF0IDc6MjYgQU0sIFN0ZWZh biBIw6VrYW5zc29uIExLDQo+IDxzdGVmYW4ubGsuaGFrYW5zc29uQGVyaWNzc29uLmNvbTxtYWls dG86c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5jb20+DQo+IDxtYWlsdG86c3RlZmFuLmxr Lmhha2Fuc3NvbkBlcmljc3Nvbi5jb20+PiB3cm90ZToNCj4NCj4gICAgIE9uIDMwLzExLzE0IDE2 OjA2LCBNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUpIHdyb3RlOg0KPiAgICAgID4+IE9uIDMw LzExLzE0IDE0OjUxLCBNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUpIHdyb3RlOg0KPiAgICAg ID4+Pj4gSGksDQo+ICAgICAgPj4+Pg0KPiAgICAgID4+Pj4+PiBSRkMgNzM0NSAoVURQVEwtRFRM Uykgc2F5cyB0aGUgZm9sbG93aW5nOg0KPiAgICAgID4+Pj4+Pg0KPiAgICAgID4+Pj4+PiAiT25j ZSBhbiBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UgaGFzIGJlZW4gY29tcGxldGVkLCBlaXRoZXINCj4g ICAgICA+Pj4+Pj4gZW5kcG9pbnQNCj4gICAgICA+Pj4+IE1BWQ0KPiAgICAgID4+Pj4+PiBzZW5k IGEgbmV3IG9mZmVyIGluIG9yZGVyIHRvIG1vZGlmeSB0aGUgc2Vzc2lvbi4gIFRoZQ0KPiAgICAg ID4+Pj4+PiBlbmRwb2ludHMNCj4gICAgICA+Pj4+IGNhbg0KPiAgICAgID4+Pj4+PiByZXVzZSB0 aGUgZXhpc3RpbmcgRFRMUyBhc3NvY2lhdGlvbiBpZiB0aGUga2V5IGZpbmdlcnByaW50DQo+ICAg ICAgPj4+Pj4+IHZhbHVlcw0KPiAgICAgID4+Pj4gYW5kDQo+ICAgICAgPj4+Pj4+IHRyYW5zcG9y dCBwYXJhbWV0ZXJzIGluZGljYXRlZCBieSBlYWNoIGVuZHBvaW50IGFyZSB1bmNoYW5nZWQuDQo+ ICAgICAgPj4+Pj4+IE90aGVyd2lzZSwgZm9sbG93aW5nIHRoZSBydWxlcyBmb3IgdGhlIGluaXRp YWwgb2ZmZXIvYW5zd2VyDQo+ICAgICAgPj4+PiBleGNoYW5nZSwNCj4gICAgICA+Pj4+Pj4gdGhl IGVuZHBvaW50cyBjYW4gbmVnb3RpYXRlIGFuZCBjcmVhdGUgYSBuZXcgRFRMUyBhc3NvY2lhdGlv bg0KPiAgICAgID4+Pj4+PiBhbmQsIG9uY2UgY3JlYXRlZCwgZGVsZXRlIHRoZSBwcmV2aW91cyBE VExTIGFzc29jaWF0aW9uLA0KPiAgICAgID4+Pj4+PiBmb2xsb3dpbmcgdGhlIHNhbWUgcnVsZXMg Zm9yIHRoZSBpbml0aWFsIG9mZmVyL2Fuc3dlciBleGNoYW5nZS4NCj4gICAgICA+Pj4+Pj4gRWFj aCBlbmRwb2ludCBuZWVkcyB0byBiZSBwcmVwYXJlZCB0byByZWNlaXZlIGRhdGEgb24gYm90aCB0 aGUNCj4gICAgICA+Pj4+Pj4gbmV3IGFuZCBvbGQgRFRMUyBhc3NvY2lhdGlvbnMgYXMgbG9uZyBh cyBib3RoIGFyZSBhbGl2ZS4iDQo+ICAgICAgPj4+Pj4+DQo+ICAgICAgPj4+Pj4+IFNvLCBJIGd1 ZXNzIHRoYXQgY2FuIGJlIHJlYWQgaW4gYSB3YXkgdGhhdCB0aGUgc2V0dXAgYXR0cmlidXRlDQo+ ICAgICAgPj4+Pj4+IGFzIHN1Y2gNCj4gICAgICA+Pj4+IGRvZXMgbm90IGltcGFjdCBwcmV2aW91 c2x5DQo+ICAgICAgPj4+Pj4+IG5lZ290aWF0ZWQgVExTIHJvbGVzIC0gdW5sZXNzIHRoZSBrZXkg ZmluZ2VycHJpbnQgdmFsdWVzIGFuZC9vcg0KPiAgICAgID4+Pj4+PiB0cmFuc3BvcnQNCj4gICAg ICA+Pj4+IHBhcmFtZXRlcnMgYXJlIG1vZGlmaWVkLg0KPiAgICAgID4+Pj4+Pg0KPiAgICAgID4+ Pj4+PiBUaGUgU0NUUC1TRFAgZHJhZnQgY3VycmVudGx5IHNheXMgdGhhdCBhIHN1YnNlcXVlbnQg b2ZmZXIgbXVzdA0KPiAgICAgID4+Pj4+PiBub3QgY2hhbmdlDQo+ICAgICAgPj4+PiB0aGUgcHJl dmlvdXNseSBuZWdvdGlhdGVkIHJvbGVzLiBCdXQsIEkgZ3Vlc3MNCj4gICAgICA+Pj4+Pj4gd2Ug Y291bGQgc2F5IHNvbWV0aGluZyBzaW1pbGFyIGFzIGluIFJGQyA3MzQ1Lg0KPiAgICAgID4+Pj4+ DQo+ICAgICAgPj4+Pj4gSSBoYXZlIHN0cnVnZ2xlZCB3aXRoIHRoaXMgbGFuZ3VhZ2UgcXVpdGUg YSBiaXQgZnJvbSB0aGUNCj4gICAgICA+Pj4+PiBpbXBsZW1lbnRhdGlvbg0KPiAgICAgID4+Pj4g cGVyc3BlY3RpdmUuIEkgdGhpbmsgd2UgbmVlZCB0byBleHBsaWNpdGx5IHN0YXRlDQo+ICAgICAg Pj4+Pj4gdGhhdCBlbmRwb2ludHMgTVVTVCByZXVzZSB0aGUgZXhpc3RpbmcgYXNzb2NpYXRpb24g aWYgdGhlIGtleQ0KPiAgICAgID4+Pj4+IGZpbmdlcnByaW50DQo+ICAgICAgPj4+PiB2YWx1ZXMg YW5kIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIGluZGljYXRlZA0KPiAgICAgID4+Pj4+IGJ5IGVhY2gg ZW5kcG9pbnQgYXJlIHVuY2hhbmdlZC4NCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+PiBXZSBjb3Vs ZCB0YWtlIHN1Y2ggZ2VuZXJhbCBhcHByb2FjaC4NCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+PiBI b3dldmVyLCBmb3IgJ1NDVFAvRFRMUycgKERUTFMgb3ZlciBTQ1RQKSwgSSBhc3N1bWUgdGhhdCB0 aGUgRFRMUw0KPiAgICAgID4+Pj4gY29ubmVjdGlvbiB3aWxsIGFsc28gYmUgcmUtZXN0YWJsaXNo ZWQgaWYgdGhlIHVuZGVybHlpbmcgU0NUUA0KPiAgICAgID4+Pj4gYXNzb2NpYXRpb24gaXMgcmUt IGVzdGFibGlzaGVkIC0gZXZlbiBpZiBubyB0cmFuc3BvcnQgcGFyYW1ldGVycw0KPiAgICAgID4+ Pj4gZXRjIGFyZSBjaGFuZ2VkLg0KPiAgICAgID4+Pj4NCj4gICAgICA+Pj4+IEFsc28sIFJGQyA2 MDgzIHNheXM6DQo+ICAgICAgPj4+Pg0KPiAgICAgID4+Pj4gIkVhY2ggRFRMUyBjb25uZWN0aW9u IE1VU1QgYmUgZXN0YWJsaXNoZWQgYW5kIHRlcm1pbmF0ZWQNCj4gICAgIHdpdGhpbiB0aGUNCj4g ICAgICA+Pj4+IHNhbWUgU0NUUCBhc3NvY2lhdGlvbi4iDQo+ICAgICAgPj4+Pg0KPiAgICAgID4+ Pj4NCj4gICAgICA+Pj4+PiBUaGUgd2F5IHRoaXMgbGFuZ3VhZ2UgcmVhZHMgdG8gbWUgaXMgdGhh dCBlbmRwb2ludHMgY2FuIHJldXNlIHRoZQ0KPiAgICAgID4+Pj4+IGV4aXN0aW5nDQo+ICAgICAg Pj4+PiBhc3NvY2lhdGlvbiBpZiB0aGV5IHdhbnQgdG8sIGJ1dCB0aGV5IGNhbiBjcmVhdGUgYSBu ZXcgb25lIGlmIHRoZXkNCj4gICAgICA+Pj4+IGRvbid0LiBBbHNvLCB3aGVuIHRoaXMgbmV3DQo+ ICAgICAgPj4+Pj4gYXNzb2NpYXRpb24gaXMgY3JlYXRlZCwgaXQgaXMgdW5jbGVhciBpZiBvbGQg c2V0dXAgcm9sZXMgTVVTVCBiZQ0KPiAgICAgID4+Pj4+IHByZXNlcnZlZA0KPiAgICAgID4+Pj4g b3IgaWYgdGhleSBNVVNUIGJlIHNlbGVjdGVkIGJhc2VkIG9uIHRoZSBjdXJyZW50IG9mZmVyL2Fu c3dlcg0KPiAgICAgID4+Pj4gZXhjaGFuZ2UuIEl0IHNlZW1zIHRoZSBjdXJyZW50DQo+ICAgICAg Pj4+Pj4gc3BlY2lmaWNhdGlvbiBsYW5ndWFnZSBpcyBub3Qgc3Ryb25nIG9yIGNsZWFyIGVub3Vn aCBvbiB0aGlzDQo+ICAgICAgPj4+Pj4gdG9waWMuDQo+ICAgICAgPj4+Pg0KPiAgICAgID4+Pj4g SW4gbXkgb3BpbmlvbiwgSUYgYSBuZXcgRFRMUyBjb25uZWN0aW9uIG5lZWRzIHRvIGJlIGVzdGFi bGlzaGVkDQo+ICAgICAgPj4+PiAoZm9yIHdoYXRldmVyIHJlYXNvbnMpLCB0aGUgY3VycmVudCBy b2xlcyBzaG91bGQgYmUgdXNlZC4NCj4gICAgICA+Pj4NCj4gICAgICA+Pj4gPFJhanU+IFdoZW4g SUNFIGlzIE5PVCB1c2VkLCBob3cgZG9lcyB0aGUgb2ZmZXJlciBrbm93IHRoYXQgdGhlDQo+ICAg ICAgPj4+IGFuc3dlcmVyIGRvZXMgbm90IGNoYW5nZSB0aGUgZmluZ2VycHJpbnQgYW5kL29yIHRy YW5zcG9ydA0KPiAgICAgcGFyYW1ldGVycz8NCj4gICAgICA+Pj4gSSBndWVzcyBpdCBkb2VzIG5v dCBrbm93LiBTbywgb2ZmZXJlciBoYXMgdG8gYmUgcHJlcGFyZWQgZm9yDQo+ICAgICBuZXcgRFRM Uw0KPiAgICAgID4+PiBhc3NvY2lhdGlvbiBieSBvZmZlcmluZyBhY3RwYXNzLiBXaGVuIElDRSBp cyB1c2VkLCB0aGUgYW5zd2VyZXINCj4gICAgIGNhbid0DQo+ICAgICAgPj4+IGNoYW5nZSB0cmFu c3BvcnQgcGFyYW1ldGVyIHVubGVzcyBvZmZlcmVyIGRvZXMgSUNFIHJlc3RhcnQgKHdoaWNoDQo+ ICAgICAgPj4+IGNoYW5nZXMgb2ZmZXJlciB0cmFuc3BvcnQgcGFyYW1ldGVycyk7IFJlZiBbMV0g aXMgdmVyeSBjbGVhciBvbg0KPiAgICAgdGhpcw0KPiAgICAgID4+PiBpbmRpY2F0aW5nICJEVExT IGhhbmRzaGFrZSBwcm9jZWR1cmUgaXMgcmVwZWF0ZWQiLiBIb3dldmVyLA0KPiAgICAgZXZlbiB3 aGVuDQo+ICAgICAgPj4+IElDRSBpcyB1c2VkLCBJIGRvIG5vdCBmaW5kIGFueSByZXN0cmljdGlv biBhYm91dCBhbnN3ZXJlciBub3QNCj4gICAgICA+Pj4gY2hhbmdpbmcgZmluZ2VycHJpbnQuIFNv LCBldmVuIHdpdGhvdXQgSUNFIHJlc3RhcnQgYW5zd2VyZXIgY2FuDQo+ICAgICAgPj4+IHRyaWdn ZXIgYSBEVExTIHJlbmVnb3RpYXRpb24gYnkgY2hhbmdpbmcgaXRzIGZpbmdlcnByaW50Lg0KPiAg ICAgID4+Pg0KPiAgICAgID4+PiBUbyBjb25jbHVkZSBhbGwgdGhpcywgSU1PIHdoZXRoZXIgSUNF IGlzIHVzZWQgb3Igbm90LCBzZW5kaW5nDQo+ICAgICBhY3RwYXNzDQo+ICAgICAgPj4+IGZvciBh bGwgbmV3IG9mZmVycyBtYXkgYmUgY292ZXIgYWxsIHBvc3NpYmxlIHNjZW5hcmlvcy4NCj4gICAg ICA+Pg0KPiAgICAgID4+IFRoYXQgaXMgYWxzbyBteSBjb25jbHVzaW9uIGJhc2VkIG9uIHRoZSBk aXNjdXNzaW9uIHNvIGZhci4NCj4gICAgICA+Pg0KPiAgICAgID4+IEkgYWxzbyB0aGluayB0aGUg SlNFUCBkcmFmdCBhcyBmYXIgYXMgZGV0YWlsZWQgb3V0IGlzIGNvcnJlY3QsDQo+ICAgICBidXQg aW5mbw0KPiAgICAgID4+IGFib3V0IGhvdyB0aGUgaW1wbGVtZW50YXRpb24gc2hvdWxkIGJlaGF2 ZSBmb3IgU3Vic2VxdWVudCBhbnN3ZXJzIGlzDQo+ICAgICAgPj4gbWlzc2luZy4gVGV4dCBzYXlp bmcgdGhhdCB0aGUgcm9sZSBtdXN0IGJlIG1haW50YWluZWQgKHVubGVzcw0KPiAgICAgdGhlcmUg aXMNCj4gICAgICA+PiBhbiBJQ0UgcmVzdGFydCkgc2hvdWxkIGJlIHB1dCBpbiB0aGVyZS4NCj4g ICAgICA+DQo+ICAgICAgPiA8UmFqdT4NCj4gICAgICA+IEhpIFN0ZWZhbiwNCj4gICAgICA+IExv b2tzIGxpa2UsIHRoZXJlIGlzIHNvbWUgbWlzdW5kZXJzdGFuZGluZyBoZXJlLg0KPg0KPiAgICAg UHJvYmFibHkgbXkgZmF1bHQgaW4gdGhhdCBjYXNlIDopDQo+DQo+ICAgICA+IE15IGNvbmNsdXNp b24gaXMgdG8gaW5jbHVkZQ0KPiAgICAgPiBhY3RwYXNzLCBidXQgbm90IHRoZSBwcmV2aW91c2x5 IG5lZ290aWF0ZWQgcm9sZSwgaW4gYWxsIHN1YnNlcXVlbnQgb2ZmZXJzLA0KPiAgICAgPiBub3Qg anVzdCBkdXJpbmcgSUNFLXJlc3RhcnRzLg0KPg0KPiAgICAgSSB0aGluayB0aGF0IGlzIHdoYXQg dGhlIEpTRVAgZHJhZnQgc2F5cyAtIGFuZCBteSBjb25jbHVzaW9uIGlzIHRoYXQgaXQNCj4gICAg IF9pc18gY29ycmVjdC4NCj4NCj4gICAgIE15IHBvaW50IHdhcyB0aGF0IHRoZSBfYW5zd2VyXyBz aG91bGQgKHdoZW4gaXQgaXMgYSBzdWJzZXF1ZW50IGFuc3dlcikNCj4gICAgIHNob3VsZCBzYXkg dGhlIHNhbWUgcm9sZSBhcyBpbiBwcmV2aW91cyBhbnN3ZXJzICh1bmxlc3MgdGhlcmUgaXMgYW4g SUNFDQo+ICAgICByZXN0YXJ0KS4NCj4NCj4gSSBhZ3JlZSB0aGUgSlNFUCB0ZXh0IHNob3VsZCBp bmRpY2F0ZSB0aGF0IHJvbGVzIHNob3VsZCBzdGF5IHRoZSBzYW1lLg0KPiBXZSBoYXZlIGhhZCB0 aGlzIGFzIGEgVE9ETyBmb3IgYSB3aGlsZToNCj4gaHR0cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13 Zy9qc2VwL2lzc3Vlcy83Mg0KDQpHcmVhdC4gSSBzaG91bGQgaGF2ZSBjaGVja2VkIHRoYXQgb3V0 IGJlZm9yZS4NCg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B1D577CB5ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNt Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBw dDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZdmUgbWlzc2Vk IHRoYXQuIEF3ZXNvbWUhIDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbywgaWYgd2XigJlyZSBvayB3aXRoIHRoYXQg YXBwcm9hY2gsIHRoZW4gd2Ugc2hvdWxkIHVzZSBzaW1pbGFyIHRleHQgaW4gdGhlIFNDVFAtU0RQ IGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anVi ZXJ0aUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDQuIGpvdWx1a3V1dGEgMjAxNCA4 OjUzPGJyPg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPkNjOjwvYj4gU3Rl ZmFuIEjDpWthbnNzb24gTEs7IE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSk7IFJvbWFuIFNo cG91bnQ7IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0g SlNFUDogV2h5IGFsd2F5cyBvZmZlciBhY3RwYXNzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjU3NjMsIFMgNi42IHNlZW1zIHRvIGltcGx5IHRoYXQ6PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Tm90ZSB0aGF0 IGlmIHRoZSBhY3RpdmUvcGFzc2l2ZSBzdGF0dXMgb2YgdGhlIGVuZHBvaW50cyBjaGFuZ2VzLCBh IG5ldzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7Y29ubmVjdGlvbiBNVVNUIGJlIGVzdGFibGlzaGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBEZWMg MywgMjAxNCBhdCAxMDozMCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0 bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28sIG9uZSBzdWdnZXN0aW9u IHdvdWxkIGJlIHRvIHNheSB0aGF0LCBJRiBvbmUgKHRoZXJlIG9mZmVyZXIgb3IgYW5zd2VyZXIp IGNoYW5nZXMgdGhlIHByZXZpb3VzbHkNCiBuZWdvdGlhdGVkIHJvbGVzLCB0aGUgRFRMUyBjb25u ZWN0aW9uIE1VU1QgYmUgcmUtZXN0YWJsaXNoZWQg4oCTIGV2ZW4gaWYgdGhlIHRyYW5zcG9ydCBw YXJhbWV0ZXJzIGV0YyBhcmVu4oCZdCBjaGFuZ2VkLiBJIHRoaW5rIHRoYXQgd291bGQgYmUgYSB2 ZXJ5IHVzZWZ1bCBjbGFyaWZpY2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBKdXN0aW4gVWJlcnRpIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmp1YmVydGlAZ29vZ2xl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmp1YmVydGlAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gNC4gam91bHVrdXV0YSAyMDE0IDc6NDk8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVy IEhvbG1iZXJnPGJyPg0KPGI+Q2M6PC9iPiBTdGVmYW4gSMOla2Fuc3NvbiBMSzsgTWFrYXJhanUs IE1hcmlkaSBSYWp1IChSYWp1KTsgUm9tYW4gU2hwb3VudDsgPGEgaHJlZj0ibWFpbHRvOnJ0Y3dl YkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KcnRjd2ViQGlldGYub3JnPC9hPjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBKU0VQOiBXaHkgYWx3YXlzIG9mZmVyIGFjdHBh c3M/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Q3VycmVudGx5LCBDaHJvbWUgZXJyb3JzIG91dCAoaS5lLiBzZXRSRCBmYWls cykuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SG93 ZXZlciwgSSBzdXNwZWN0IHRoYXQgdGVhcmRvd24gb2YgdGhlIG9sZCBEVExTIGFzc29jaWF0aW9u IGFuZCBzZXR1cCBvZiBhIG5ldyBEVExTIGFzc29jaWF0aW9uIGlzIHRoZSBkZXNpcmVkIGJlaGF2 aW9yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+T24gV2VkLCBEZWMgMywgMjAxNCBhdCA4OjM0IFBNLCBDaHJpc3RlciBIb2xtYmVyZyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSw8YnI+DQo8YnI+DQpJc3N1 ZSAjNzIgdGFsa3MgYWJvdXQgbWFpbnRhaW5pbmcgdGhlIHByZXZpb3VzbHkgbmVnb3RpYXRlZCBy b2xlIHdoZW4gYWN0cGFzcyBpcyByZWNlaXZlZC4gSSB0aGluayB0aGF0IGlzIGEgZ29vZCBhcHBy b2FjaCwgYW5kIGNvdWxkIGJlIHVzZWQgaW4gT2ZmZXIvQW5zd2VyIHRvby48YnI+DQo8YnI+DQpC VVQsIHdoYXQgZG9lcyB0aGUgYnJvd3NlciBkbyBpZiBlLmcuIHRoZSBwcmV2aW91cyByb2xlIGlz IHBhc3NpdmUgYW5kIGFjdGl2ZSBpcyByZWNlaXZlZD88YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4N Cjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmU8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1z b05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBz aXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOg0KPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpzdGVmYW4ubGsuaGFr YW5zc29uQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlN0ZWZhbiBIw6VrYW5zc29uIExL PC9hPjwvc3Bhbj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlbnQ6IDwv c3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAjjAzL+KAjjEyL+KAjjIw MTQgMTc6NDg8L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ubzog PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpq dWJlcnRpQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5KdXN0aW4gVWJlcnRpPC9hPjwvc3Bh bj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNjOiA8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOlJhanUuTWFrYXJhanVA YWxjYXRlbC1sdWNlbnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWFrYXJhanUsIE1hcmlkaSBSYWp1 IChSYWp1KTwvYT47DQo8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tIiB0YXJnZXQ9Il9ibGFuayI+Q2hyaXN0ZXIgSG9sbWJlcmc8L2E+Ow0KPGEgaHJlZj0ibWFp bHRvOnJvbWFuQHRlbHVyaXguY29tIiB0YXJnZXQ9Il9ibGFuayI+Um9tYW4gU2hwb3VudDwvYT47 IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnJ0Y3dl YkBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5TdWJqZWN0OiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZTog W3J0Y3dlYl0gSlNFUDogV2h5IGFsd2F5cyBvZmZlciBhY3RwYXNzPzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5PbiAwMS8xMi8xNCAxODoyNiwgSnVz dGluIFViZXJ0aSB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gU3VuLCBO b3YgMzAsIDIwMTQgYXQgNzoyNiBBTSwgU3RlZmFuIEjDpWthbnNzb24gTEs8YnI+DQomZ3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5jb20iIHRhcmdl dD0iX2JsYW5rIj5zdGVmYW4ubGsuaGFrYW5zc29uQGVyaWNzc29uLmNvbTwvYT48YnI+DQomZ3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5jb20iIHRh cmdldD0iX2JsYW5rIj5tYWlsdG86c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5jb208L2E+ Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgT24gMzAvMTEvMTQgMTY6MDYsIE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkgd3JvdGU6 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBPbiAzMC8x MS8xNCAxNDo1MSwgTWFrYXJhanUsIE1hcmlkaSBSYWp1IChSYWp1KSB3cm90ZTo8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgSGksPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgUkZDIDczNDUgKFVEUFRMLURUTFMpIHNheXMgdGhlIGZvbGxvd2luZzo8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7ICZxdW90O09uY2UgYW4gb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIGhhcyBiZWVuIGNvbXBsZXRl ZCwgZWl0aGVyPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgZW5kcG9pbnQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgTUFZPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VuZCBhIG5ldyBvZmZlciBp biBvcmRlciB0byBtb2RpZnkgdGhlIHNlc3Npb24uJm5ic3A7IFRoZTxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGVuZHBvaW50 czxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyBjYW48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyByZXVzZSB0aGUgZXhpc3RpbmcgRFRMUyBhc3NvY2lhdGlvbiBpZiB0aGUg a2V5IGZpbmdlcnByaW50PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdmFsdWVzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFuZDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRyYW5zcG9ydCBwYXJh bWV0ZXJzIGluZGljYXRlZCBieSBlYWNoIGVuZHBvaW50IGFyZSB1bmNoYW5nZWQuPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg T3RoZXJ3aXNlLCBmb2xsb3dpbmcgdGhlIHJ1bGVzIGZvciB0aGUgaW5pdGlhbCBvZmZlci9hbnN3 ZXI8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDsgZXhjaGFuZ2UsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIGVuZHBvaW50cyBjYW4gbmVnb3RpYXRlIGFuZCBjcmVh dGUgYSBuZXcgRFRMUyBhc3NvY2lhdGlvbjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFuZCwgb25jZSBjcmVhdGVkLCBkZWxl dGUgdGhlIHByZXZpb3VzIERUTFMgYXNzb2NpYXRpb24sPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZm9sbG93aW5nIHRoZSBz YW1lIHJ1bGVzIGZvciB0aGUgaW5pdGlhbCBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UuPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg RWFjaCBlbmRwb2ludCBuZWVkcyB0byBiZSBwcmVwYXJlZCB0byByZWNlaXZlIGRhdGEgb24gYm90 aCB0aGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBuZXcgYW5kIG9sZCBEVExTIGFzc29jaWF0aW9ucyBhcyBsb25nIGFzIGJv dGggYXJlIGFsaXZlLiZxdW90Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU28sIEkgZ3Vlc3MgdGhhdCBjYW4g YmUgcmVhZCBpbiBhIHdheSB0aGF0IHRoZSBzZXR1cCBhdHRyaWJ1dGU8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhcyBzdWNo PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 IGRvZXMgbm90IGltcGFjdCBwcmV2aW91c2x5PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbmVnb3RpYXRlZCBUTFMgcm9sZXMg LSB1bmxlc3MgdGhlIGtleSBmaW5nZXJwcmludCB2YWx1ZXMgYW5kL29yPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHJhbnNw b3J0PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7IHBhcmFtZXRlcnMgYXJlIG1vZGlmaWVkLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIFNDVFAtU0RQ IGRyYWZ0IGN1cnJlbnRseSBzYXlzIHRoYXQgYSBzdWJzZXF1ZW50IG9mZmVyIG11c3Q8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBub3QgY2hhbmdlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7IHRoZSBwcmV2aW91c2x5IG5lZ290aWF0ZWQgcm9sZXMuIEJ1dCwgSSBndWVz czxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHdlIGNvdWxkIHNheSBzb21ldGhpbmcgc2ltaWxhciBhcyBpbiBSRkMgNzM0NS48 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBJIGhhdmUgc3RydWdnbGVkIHdpdGggdGhpcyBsYW5ndWFnZSBxdWl0ZSBhIGJpdCBm cm9tIHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgaW1wbGVtZW50YXRpb248YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgcGVyc3BlY3RpdmUuIEkgdGhpbmsgd2UgbmVlZCB0 byBleHBsaWNpdGx5IHN0YXRlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGF0IGVuZHBvaW50cyBNVVNUIHJldXNlIHRoZSBleGlz dGluZyBhc3NvY2lhdGlvbiBpZiB0aGUga2V5PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmaW5nZXJwcmludDxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyB2YWx1ZXMgYW5kIHRy YW5zcG9ydCBwYXJhbWV0ZXJzIGluZGljYXRlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYnkgZWFjaCBlbmRwb2ludCBhcmUgdW5j aGFuZ2VkLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyBXZSBjb3VsZCB0YWtlIHN1Y2ggZ2VuZXJhbCBhcHByb2FjaC48YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgSG93ZXZlciwgZm9y ICdTQ1RQL0RUTFMnIChEVExTIG92ZXIgU0NUUCksIEkgYXNzdW1lIHRoYXQgdGhlIERUTFM8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgY29u bmVjdGlvbiB3aWxsIGFsc28gYmUgcmUtZXN0YWJsaXNoZWQgaWYgdGhlIHVuZGVybHlpbmcgU0NU UDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyBhc3NvY2lhdGlvbiBpcyByZS0gZXN0YWJsaXNoZWQgLSBldmVuIGlmIG5vIHRyYW5zcG9ydCBw YXJhbWV0ZXJzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7IGV0YyBhcmUgY2hhbmdlZC48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgQWxzbywgUkZDIDYwODMgc2F5czo8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7RWFj aCBEVExTIGNvbm5lY3Rpb24gTVVTVCBiZSBlc3RhYmxpc2hlZCBhbmQgdGVybWluYXRlZDxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2l0aGluIHRoZTxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBzYW1lIFNDVFAgYXNzb2Np YXRpb24uJnF1b3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgd2F5IHRoaXMgbGFuZ3VhZ2UgcmVhZHMgdG8gbWUgaXMgdGhh dCBlbmRwb2ludHMgY2FuIHJldXNlIHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZXhpc3Rpbmc8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgYXNzb2NpYXRpb24gaWYgdGhl eSB3YW50IHRvLCBidXQgdGhleSBjYW4gY3JlYXRlIGEgbmV3IG9uZSBpZiB0aGV5PGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IGRvbid0LiBB bHNvLCB3aGVuIHRoaXMgbmV3PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhc3NvY2lhdGlvbiBpcyBjcmVhdGVkLCBpdCBpcyB1bmNs ZWFyIGlmIG9sZCBzZXR1cCByb2xlcyBNVVNUIGJlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwcmVzZXJ2ZWQ8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgb3IgaWYgdGhleSBN VVNUIGJlIHNlbGVjdGVkIGJhc2VkIG9uIHRoZSBjdXJyZW50IG9mZmVyL2Fuc3dlcjxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBleGNoYW5n ZS4gSXQgc2VlbXMgdGhlIGN1cnJlbnQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNwZWNpZmljYXRpb24gbGFuZ3VhZ2UgaXMgbm90 IHN0cm9uZyBvciBjbGVhciBlbm91Z2ggb24gdGhpczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG9waWMuPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IEluIG15IG9waW5pb24s IElGIGEgbmV3IERUTFMgY29ubmVjdGlvbiBuZWVkcyB0byBiZSBlc3RhYmxpc2hlZDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyAoZm9yIHdo YXRldmVyIHJlYXNvbnMpLCB0aGUgY3VycmVudCByb2xlcyBzaG91bGQgYmUgdXNlZC48YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7ICZsdDtSYWp1Jmd0OyBX aGVuIElDRSBpcyBOT1QgdXNlZCwgaG93IGRvZXMgdGhlIG9mZmVyZXIga25vdyB0aGF0IHRoZTxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IGFuc3dl cmVyIGRvZXMgbm90IGNoYW5nZSB0aGUgZmluZ2VycHJpbnQgYW5kL29yIHRyYW5zcG9ydDxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGFyYW1ldGVycz88YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBJIGd1ZXNzIGl0IGRvZXMgbm90 IGtub3cuIFNvLCBvZmZlcmVyIGhhcyB0byBiZSBwcmVwYXJlZCBmb3I8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5ldyBEVExTPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgYXNzb2NpYXRpb24gYnkgb2ZmZXJpbmcgYWN0cGFzcy4g V2hlbiBJQ0UgaXMgdXNlZCwgdGhlIGFuc3dlcmVyPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBjYW4ndDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZndDsmZ3Q7IGNoYW5nZSB0cmFuc3BvcnQgcGFyYW1ldGVyIHVubGVzcyBvZmZlcmVyIGRvZXMg SUNFIHJlc3RhcnQgKHdoaWNoPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jmd0OyZndDsgY2hhbmdlcyBvZmZlcmVyIHRyYW5zcG9ydCBwYXJhbWV0ZXJzKTsgUmVm IFsxXSBpcyB2ZXJ5IGNsZWFyIG9uPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0 aGlzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsg aW5kaWNhdGluZyAmcXVvdDtEVExTIGhhbmRzaGFrZSBwcm9jZWR1cmUgaXMgcmVwZWF0ZWQmcXVv dDsuIEhvd2V2ZXIsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBldmVuIHdoZW48 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBJQ0Ug aXMgdXNlZCwgSSBkbyBub3QgZmluZCBhbnkgcmVzdHJpY3Rpb24gYWJvdXQgYW5zd2VyZXIgbm90 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgY2hh bmdpbmcgZmluZ2VycHJpbnQuIFNvLCBldmVuIHdpdGhvdXQgSUNFIHJlc3RhcnQgYW5zd2VyZXIg Y2FuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsg dHJpZ2dlciBhIERUTFMgcmVuZWdvdGlhdGlvbiBieSBjaGFuZ2luZyBpdHMgZmluZ2VycHJpbnQu PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBUbyBjb25j bHVkZSBhbGwgdGhpcywgSU1PIHdoZXRoZXIgSUNFIGlzIHVzZWQgb3Igbm90LCBzZW5kaW5nPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhY3RwYXNzPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgZm9yIGFsbCBuZXcgb2ZmZXJzIG1h eSBiZSBjb3ZlciBhbGwgcG9zc2libGUgc2NlbmFyaW9zLjxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7IFRoYXQgaXMgYWxzbyBteSBjb25jbHVzaW9uIGJhc2VkIG9uIHRo ZSBkaXNjdXNzaW9uIHNvIGZhci48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyBJIGFsc28gdGhpbmsgdGhlIEpTRVAgZHJhZnQgYXMgZmFyIGFzIGRldGFpbGVkIG91dCBp cyBjb3JyZWN0LDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnV0IGluZm88YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IGFib3V0IGhvdyB0 aGUgaW1wbGVtZW50YXRpb24gc2hvdWxkIGJlaGF2ZSBmb3IgU3Vic2VxdWVudCBhbnN3ZXJzIGlz PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBtaXNzaW5n LiBUZXh0IHNheWluZyB0aGF0IHRoZSByb2xlIG11c3QgYmUgbWFpbnRhaW5lZCAodW5sZXNzPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGVyZSBpczxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgYW4gSUNFIHJlc3RhcnQpIHNob3VsZCBi ZSBwdXQgaW4gdGhlcmUuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZsdDtSYWp1 Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBIaSBTdGVm YW4sPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IExvb2tzIGxp a2UsIHRoZXJlIGlzIHNvbWUgbWlzdW5kZXJzdGFuZGluZyBoZXJlLjxicj4NCiZndDs8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByb2JhYmx5IG15IGZhdWx0IGluIHRoYXQgY2Fz ZSA6KTxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgTXkg Y29uY2x1c2lvbiBpcyB0byBpbmNsdWRlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7IGFjdHBhc3MsIGJ1dCBub3QgdGhlIHByZXZpb3VzbHkgbmVnb3RpYXRlZCByb2xlLCBp biBhbGwgc3Vic2VxdWVudCBvZmZlcnMsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7IG5vdCBqdXN0IGR1cmluZyBJQ0UtcmVzdGFydHMuPGJyPg0KJmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSB0aGluayB0aGF0IGlzIHdoYXQgdGhlIEpTRVAgZHJh ZnQgc2F5cyAtIGFuZCBteSBjb25jbHVzaW9uIGlzIHRoYXQgaXQ8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IF9pc18gY29ycmVjdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBNeSBwb2ludCB3YXMgdGhhdCB0aGUgX2Fuc3dlcl8gc2hvdWxkICh3 aGVuIGl0IGlzIGEgc3Vic2VxdWVudCBhbnN3ZXIpPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBzaG91bGQgc2F5IHRoZSBzYW1lIHJvbGUgYXMgaW4gcHJldmlvdXMgYW5zd2VycyAo dW5sZXNzIHRoZXJlIGlzIGFuIElDRTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg cmVzdGFydCkuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBhZ3JlZSB0aGUgSlNFUCB0ZXh0IHNob3Vs ZCBpbmRpY2F0ZSB0aGF0IHJvbGVzIHNob3VsZCBzdGF5IHRoZSBzYW1lLjxicj4NCiZndDsgV2Ug aGF2ZSBoYWQgdGhpcyBhcyBhIFRPRE8gZm9yIGEgd2hpbGU6PGJyPg0KJmd0OyA8YSBocmVmPSJo dHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAvaXNzdWVzLzcyIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13Zy9qc2VwL2lzc3Vlcy83MjwvYT48YnI+DQo8 YnI+DQpHcmVhdC4gSSBzaG91bGQgaGF2ZSBjaGVja2VkIHRoYXQgb3V0IGJlZm9yZS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_7594FB04B1934943A5C02806D1A2204B1D577CB5ESESSMB209erics_-- From nobody Thu Dec 4 04:26:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63C31A0248 for ; Thu, 4 Dec 2014 04:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjOIXcCfLqdY for ; Thu, 4 Dec 2014 04:26:45 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 49F971A0371 for ; Thu, 4 Dec 2014 04:26:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 965BC7C35B0 for ; Thu, 4 Dec 2014 13:26:27 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5WKBcheiKlW for ; Thu, 4 Dec 2014 13:26:17 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:a53a:eb60:5dc7:d291]) by mork.alvestrand.no (Postfix) with ESMTPSA id 1D8537C3580 for ; Thu, 4 Dec 2014 13:26:17 +0100 (CET) Message-ID: <548052E7.1050007@alvestrand.no> Date: Thu, 04 Dec 2014 13:26:15 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F60A8.3080302@alvestrand.no> <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com> <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net> <547FA924.3000504@mozilla.com> <92D0D52F3A63344CA478CF12DB0648AADF35455C@XMB111CNC.rim.net> In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF35455C@XMB111CNC.rim.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rF6QkJdtzcgY-suCq0nyyZ3tmt4 Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 12:26:47 -0000 On 12/04/2014 03:10 AM, Gaelle Martin-Cocher wrote: > There was a single hum for the three categories (browser, non-browser, compatible endpoints), right? > > That makes a lot of sense for non-browser entities that are in fact WebRTC-compatible enpoints (apps, or gateways or else) to push the burden on the browser vendors as those entities will need to interact with browsers. Hence "hum"... > > I think it would make a lot of sense to have different "hums" or questions for the two different categories. > That will bring clarity on what the "non-browser" yet WebRTC endpoint is, versus what the WebRTC-compatible endpoint is (let aside gateways). > It is not clear to me that we would have had the same results for each category if there was two (or three) different questions. It is not clear that the questions are independent. In fact, it is pretty clear to me that some participants who were willing to go with this package deal were quite unwilling to commit to all the pieces of the package if they were presented one at a time, and they had to answer the question not knowing how all the other pieces came out. I think this is a textbook case of a "package deal". From nobody Thu Dec 4 05:42:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0141AD38A for ; Thu, 4 Dec 2014 05:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxsx_Af_fOyc for ; Thu, 4 Dec 2014 05:42:43 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA9E1A8976 for ; Thu, 4 Dec 2014 05:42:42 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-44-548064d03dde Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 4C.62.29772.0D460845; Thu, 4 Dec 2014 14:42:40 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 14:42:38 +0100 From: Christer Holmberg To: Christer Holmberg , Justin Uberti Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAHfyaaUAACD+YAAA3cSQP//9fwA///u34D//2vgsA== Date: Thu, 4 Dec 2014 13:42:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D578C4D@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE2BC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577322@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577B77@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577CB5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D577CB5@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D578C4DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3RvdCSkOIwdSNYhZbpwpZrP3Xzu7A 5LFgU6nHkiU/mQKYorhsUlJzMstSi/TtErgy1h+7yljwbSpzxZLZQg2Ma7qZuxg5OSQETCQW P1rEAmGLSVy4t54NxBYSOMIoceoBH4S9mFHi94nMLkYODjYBC4nuf9ogYRGBGIlffXcYQWxm AXWJO4vPsYPYwgKmEu/nHmGGqDGTWHhyAiOEHSax4kkXWJxFQEXi3NJJYPW8Ar4Su142AsW5 gFat55G49f4pWIJTwE9i9bsPYM2MQLd9P7WGCWKZuMStJ/OZIG4WkFiy5zzUL6ISLx//YwW5 U0JASWLa1jSI8nyJs4/uM0PsEpQ4OfMJywRG0VlIJs1CUjYLSdksoEnMApoS63fpQ5QoSkzp fsgOYWtItM6Zy44svoCRfRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYJwd3PLbYAfjy+eO hxgFOBiVeHgNz9WHCLEmlhVX5h5ilOZgURLnXXhuXrCQQHpiSWp2ampBalF8UWlOavEhRiYO TqkGxu5T2ldXLTXVzzXOrJA1CYvPd5taY2FiW8U3UUI/cmXpPTFxVqelTOt5yw45XWebY6Zi /t1UonKmW5Tjx709fc9WrimOP//306H1+rs+vf4/8YKWl6WBBP/fGfLm6yt3fcmdLu4xX2XX Y41QLoULq9aIyM5NUA1Z0H08Q3StsEfHxLe1ipJ3lViKMxINtZiLihMBfaAlTZQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YzRWPlmQdIL8gFHlDrZAdrIMlaQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 13:42:48 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D578C4DESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBhYm91dCB0aGUgZm9sbG93aW5nIHRleHQ6DQoNCg0KOC4zLjIuICBUTFMgUm9sZSBEZXRl cm1pbmF0aW9uDQoNCiAgIElmIHRoZSBtLSBsaW5lIHByb3RvIGZpZWxkIHZhbHVlIGlzICdTQ1RQ L0RUTFMnIG9yICdEVExTL1NDVFAnLCB0aGUNCiAgIFNEUCBzZXR1cCBhdHRyaWJ1dGUgW1JGQzQx NDVdIGlzIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSAnYWN0aXZlLw0KICAgcGFzc2l2ZScgc3RhdHVz IG9mIHRoZSBvZmZlcmVyIGFuZCBhbnN3ZXJlci4gIFRoZSAnYWN0aXZlL3Bhc3NpdmUnDQogICBz dGF0dXMgd2lsbCBiZSB1c2VkIHRvIGRldGVybWluZSB0aGUgVExTIHJvbGVzLCBmb2xsb3dpbmcg dGhlDQogICBwcm9jZWR1cmVzIGluIFtSRkM0NTcyXSAodGhlICdhY3RpdmUnIGVuZHBvaW50IHdp bGwgdGFrZSB0aGUgVExTIGNsaWVudA0KICAgcm9sZSkuDQoNCiAgIE9uY2UgYSBEVExTIGNvbm5l Y3Rpb24gaGFzIGJlZW4gZXN0YWJsaXNoZWQsIGlmIHRoZSAnYWN0aXZlL3Bhc3NpdmUnDQogICBz dGF0dXMgb2YgdGhlIGVuZHBvaW50cyBjaGFuZ2UgZHVyaW5nIGEgc2Vzc2lvbiwgYSBuZXcgRFRM Uw0KICAgY29ubmVjdGlvbiBNVVNUIGJlIGVzdGFibGlzaGVkLiAgVGhlcmVmb3JlLCBlbmRwb2lu dHMgU0hPVUxEIE5PVA0KICAgY2hhbmdlIHRoZSDigJhhY3RpdmUvcGFzc2l2ZeKAmSBzdGF0dXMg aW4gc3Vic2VxdWVudCBvZmZlcnMgYW5kIGFuc3dlcnMsDQogICB1bmxlc3MgdGhleSB3YW50IHRv IGVzdGFibGlzaCBhIG5ldyBEVExTIGNvbm5lY3Rpb24gKGluIHdoaWNoIGNhc2UNCiAgIHRoZSBu ZXcgJ2FjdGl2ZS9wYXNzaXZlJyBzdGF0dXMgb2YgdGhlIG9mZmVyZXIgYW5kIGFuc3dlcmVyIHdp bGwgYmUNCiAgIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBUTFMgcm9sZXMgYXNzb2NpYXRlZCB3aXRo IHRoZSBuZXcgRFRMUw0KICAgY29ubmVjdGlvbikuDQoNCiAgIE5PVEU6IFRoZSBwcm9jZWR1cmUg YWJvdmUgaXMgaWRlbnRpY2FsIHRvIHRoZSBvbmUgZGVmaW5lZCBmb3IgU1JUUC0NCiAgIERUTFMg aW4gW1JGQzU3NjNdLg0KDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJvbTogcnRjd2Vi IFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RlciBI b2xtYmVyZw0KU2VudDogNC4gam91bHVrdXV0YSAyMDE0IDg6NTUNClRvOiBKdXN0aW4gVWJlcnRp DQpDYzogcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gSlNFUDogV2h5IGFs d2F5cyBvZmZlciBhY3RwYXNzPw0KDQpJ4oCZdmUgbWlzc2VkIHRoYXQuIEF3ZXNvbWUhIDopDQoN ClNvLCBpZiB3ZeKAmXJlIG9rIHdpdGggdGhhdCBhcHByb2FjaCwgdGhlbiB3ZSBzaG91bGQgdXNl IHNpbWlsYXIgdGV4dCBpbiB0aGUgU0NUUC1TRFAgZHJhZnQuDQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQpT ZW50OiA0LiBqb3VsdWt1dXRhIDIwMTQgODo1Mw0KVG86IENocmlzdGVyIEhvbG1iZXJnDQpDYzog U3RlZmFuIEjDpWthbnNzb24gTEs7IE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSk7IFJvbWFu IFNocG91bnQ7IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtydGN3ZWJdIEpTRVA6IFdoeSBhbHdheXMgb2ZmZXIgYWN0cGFzcz8NCg0KNTc2Mywg UyA2LjYgc2VlbXMgdG8gaW1wbHkgdGhhdDoNCg0KIE5vdGUgdGhhdCBpZiB0aGUgYWN0aXZlL3Bh c3NpdmUgc3RhdHVzIG9mIHRoZSBlbmRwb2ludHMgY2hhbmdlcywgYSBuZXcNCiBjb25uZWN0aW9u IE1VU1QgYmUgZXN0YWJsaXNoZWQuDQoNCg0KT24gV2VkLCBEZWMgMywgMjAxNCBhdCAxMDozMCBQ TSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KU28sIG9u ZSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRvIHNheSB0aGF0LCBJRiBvbmUgKHRoZXJlIG9mZmVyZXIg b3IgYW5zd2VyZXIpIGNoYW5nZXMgdGhlIHByZXZpb3VzbHkgbmVnb3RpYXRlZCByb2xlcywgdGhl IERUTFMgY29ubmVjdGlvbiBNVVNUIGJlIHJlLWVzdGFibGlzaGVkIOKAkyBldmVuIGlmIHRoZSB0 cmFuc3BvcnQgcGFyYW1ldGVycyBldGMgYXJlbuKAmXQgY2hhbmdlZC4gSSB0aGluayB0aGF0IHdv dWxkIGJlIGEgdmVyeSB1c2VmdWwgY2xhcmlmaWNhdGlvbi4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KRnJvbTogSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbTxtYWls dG86anViZXJ0aUBnb29nbGUuY29tPl0NClNlbnQ6IDQuIGpvdWx1a3V1dGEgMjAxNCA3OjQ5DQpU bzogQ2hyaXN0ZXIgSG9sbWJlcmcNCkNjOiBTdGVmYW4gSMOla2Fuc3NvbiBMSzsgTWFrYXJhanUs IE1hcmlkaSBSYWp1IChSYWp1KTsgUm9tYW4gU2hwb3VudDsgcnRjd2ViQGlldGYub3JnPG1haWx0 bzpydGN3ZWJAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBKU0VQOiBXaHkgYWx3 YXlzIG9mZmVyIGFjdHBhc3M/DQoNCkN1cnJlbnRseSwgQ2hyb21lIGVycm9ycyBvdXQgKGkuZS4g c2V0UkQgZmFpbHMpLg0KDQpIb3dldmVyLCBJIHN1c3BlY3QgdGhhdCB0ZWFyZG93biBvZiB0aGUg b2xkIERUTFMgYXNzb2NpYXRpb24gYW5kIHNldHVwIG9mIGEgbmV3IERUTFMgYXNzb2NpYXRpb24g aXMgdGhlIGRlc2lyZWQgYmVoYXZpb3IuDQoNCk9uIFdlZCwgRGVjIDMsIDIwMTQgYXQgODozNCBQ TSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KSXNzdWUg IzcyIHRhbGtzIGFib3V0IG1haW50YWluaW5nIHRoZSBwcmV2aW91c2x5IG5lZ290aWF0ZWQgcm9s ZSB3aGVuIGFjdHBhc3MgaXMgcmVjZWl2ZWQuIEkgdGhpbmsgdGhhdCBpcyBhIGdvb2QgYXBwcm9h Y2gsIGFuZCBjb3VsZCBiZSB1c2VkIGluIE9mZmVyL0Fuc3dlciB0b28uDQoNCkJVVCwgd2hhdCBk b2VzIHRoZSBicm93c2VyIGRvIGlmIGUuZy4gdGhlIHByZXZpb3VzIHJvbGUgaXMgcGFzc2l2ZSBh bmQgYWN0aXZlIGlzIHJlY2VpdmVkPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpTZW50IGZy b20gbXkgV2luZG93cyBQaG9uZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IFN0ZWZhbiBIw6VrYW5zc29uIExLPG1haWx0bzpzdGVmYW4ubGsuaGFrYW5zc29uQGVyaWNz c29uLmNvbT4NClNlbnQ6IOKAjjAzL+KAjjEyL+KAjjIwMTQgMTc6NDgNClRvOiBKdXN0aW4gVWJl cnRpPG1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20+DQpDYzogTWFrYXJhanUsIE1hcmlkaSBSYWp1 IChSYWp1KTxtYWlsdG86UmFqdS5NYWthcmFqdUBhbGNhdGVsLWx1Y2VudC5jb20+OyBDaHJpc3Rl ciBIb2xtYmVyZzxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgUm9tYW4g U2hwb3VudDxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+OyBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBKU0VQOiBXaHkgYWx3YXlz IG9mZmVyIGFjdHBhc3M/DQpPbiAwMS8xMi8xNCAxODoyNiwgSnVzdGluIFViZXJ0aSB3cm90ZToN Cj4NCj4NCj4gT24gU3VuLCBOb3YgMzAsIDIwMTQgYXQgNzoyNiBBTSwgU3RlZmFuIEjDpWthbnNz b24gTEsNCj4gPHN0ZWZhbi5say5oYWthbnNzb25AZXJpY3Nzb24uY29tPG1haWx0bzpzdGVmYW4u bGsuaGFrYW5zc29uQGVyaWNzc29uLmNvbT4NCj4gPG1haWx0bzpzdGVmYW4ubGsuaGFrYW5zc29u QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KPg0KPiAgICAgT24gMzAvMTEvMTQgMTY6MDYsIE1ha2Fy YWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkgd3JvdGU6DQo+ICAgICAgPj4gT24gMzAvMTEvMTQgMTQ6 NTEsIE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkgd3JvdGU6DQo+ICAgICAgPj4+PiBIaSwN Cj4gICAgICA+Pj4+DQo+ICAgICAgPj4+Pj4+IFJGQyA3MzQ1IChVRFBUTC1EVExTKSBzYXlzIHRo ZSBmb2xsb3dpbmc6DQo+ICAgICAgPj4+Pj4+DQo+ICAgICAgPj4+Pj4+ICJPbmNlIGFuIG9mZmVy L2Fuc3dlciBleGNoYW5nZSBoYXMgYmVlbiBjb21wbGV0ZWQsIGVpdGhlcg0KPiAgICAgID4+Pj4+ PiBlbmRwb2ludA0KPiAgICAgID4+Pj4gTUFZDQo+ICAgICAgPj4+Pj4+IHNlbmQgYSBuZXcgb2Zm ZXIgaW4gb3JkZXIgdG8gbW9kaWZ5IHRoZSBzZXNzaW9uLiAgVGhlDQo+ICAgICAgPj4+Pj4+IGVu ZHBvaW50cw0KPiAgICAgID4+Pj4gY2FuDQo+ICAgICAgPj4+Pj4+IHJldXNlIHRoZSBleGlzdGlu ZyBEVExTIGFzc29jaWF0aW9uIGlmIHRoZSBrZXkgZmluZ2VycHJpbnQNCj4gICAgICA+Pj4+Pj4g dmFsdWVzDQo+ICAgICAgPj4+PiBhbmQNCj4gICAgICA+Pj4+Pj4gdHJhbnNwb3J0IHBhcmFtZXRl cnMgaW5kaWNhdGVkIGJ5IGVhY2ggZW5kcG9pbnQgYXJlIHVuY2hhbmdlZC4NCj4gICAgICA+Pj4+ Pj4gT3RoZXJ3aXNlLCBmb2xsb3dpbmcgdGhlIHJ1bGVzIGZvciB0aGUgaW5pdGlhbCBvZmZlci9h bnN3ZXINCj4gICAgICA+Pj4+IGV4Y2hhbmdlLA0KPiAgICAgID4+Pj4+PiB0aGUgZW5kcG9pbnRz IGNhbiBuZWdvdGlhdGUgYW5kIGNyZWF0ZSBhIG5ldyBEVExTIGFzc29jaWF0aW9uDQo+ICAgICAg Pj4+Pj4+IGFuZCwgb25jZSBjcmVhdGVkLCBkZWxldGUgdGhlIHByZXZpb3VzIERUTFMgYXNzb2Np YXRpb24sDQo+ICAgICAgPj4+Pj4+IGZvbGxvd2luZyB0aGUgc2FtZSBydWxlcyBmb3IgdGhlIGlu aXRpYWwgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlLg0KPiAgICAgID4+Pj4+PiBFYWNoIGVuZHBvaW50 IG5lZWRzIHRvIGJlIHByZXBhcmVkIHRvIHJlY2VpdmUgZGF0YSBvbiBib3RoIHRoZQ0KPiAgICAg ID4+Pj4+PiBuZXcgYW5kIG9sZCBEVExTIGFzc29jaWF0aW9ucyBhcyBsb25nIGFzIGJvdGggYXJl IGFsaXZlLiINCj4gICAgICA+Pj4+Pj4NCj4gICAgICA+Pj4+Pj4gU28sIEkgZ3Vlc3MgdGhhdCBj YW4gYmUgcmVhZCBpbiBhIHdheSB0aGF0IHRoZSBzZXR1cCBhdHRyaWJ1dGUNCj4gICAgICA+Pj4+ Pj4gYXMgc3VjaA0KPiAgICAgID4+Pj4gZG9lcyBub3QgaW1wYWN0IHByZXZpb3VzbHkNCj4gICAg ICA+Pj4+Pj4gbmVnb3RpYXRlZCBUTFMgcm9sZXMgLSB1bmxlc3MgdGhlIGtleSBmaW5nZXJwcmlu dCB2YWx1ZXMgYW5kL29yDQo+ICAgICAgPj4+Pj4+IHRyYW5zcG9ydA0KPiAgICAgID4+Pj4gcGFy YW1ldGVycyBhcmUgbW9kaWZpZWQuDQo+ICAgICAgPj4+Pj4+DQo+ICAgICAgPj4+Pj4+IFRoZSBT Q1RQLVNEUCBkcmFmdCBjdXJyZW50bHkgc2F5cyB0aGF0IGEgc3Vic2VxdWVudCBvZmZlciBtdXN0 DQo+ICAgICAgPj4+Pj4+IG5vdCBjaGFuZ2UNCj4gICAgICA+Pj4+IHRoZSBwcmV2aW91c2x5IG5l Z290aWF0ZWQgcm9sZXMuIEJ1dCwgSSBndWVzcw0KPiAgICAgID4+Pj4+PiB3ZSBjb3VsZCBzYXkg c29tZXRoaW5nIHNpbWlsYXIgYXMgaW4gUkZDIDczNDUuDQo+ICAgICAgPj4+Pj4NCj4gICAgICA+ Pj4+PiBJIGhhdmUgc3RydWdnbGVkIHdpdGggdGhpcyBsYW5ndWFnZSBxdWl0ZSBhIGJpdCBmcm9t IHRoZQ0KPiAgICAgID4+Pj4+IGltcGxlbWVudGF0aW9uDQo+ICAgICAgPj4+PiBwZXJzcGVjdGl2 ZS4gSSB0aGluayB3ZSBuZWVkIHRvIGV4cGxpY2l0bHkgc3RhdGUNCj4gICAgICA+Pj4+PiB0aGF0 IGVuZHBvaW50cyBNVVNUIHJldXNlIHRoZSBleGlzdGluZyBhc3NvY2lhdGlvbiBpZiB0aGUga2V5 DQo+ICAgICAgPj4+Pj4gZmluZ2VycHJpbnQNCj4gICAgICA+Pj4+IHZhbHVlcyBhbmQgdHJhbnNw b3J0IHBhcmFtZXRlcnMgaW5kaWNhdGVkDQo+ICAgICAgPj4+Pj4gYnkgZWFjaCBlbmRwb2ludCBh cmUgdW5jaGFuZ2VkLg0KPiAgICAgID4+Pj4NCj4gICAgICA+Pj4+IFdlIGNvdWxkIHRha2Ugc3Vj aCBnZW5lcmFsIGFwcHJvYWNoLg0KPiAgICAgID4+Pj4NCj4gICAgICA+Pj4+IEhvd2V2ZXIsIGZv ciAnU0NUUC9EVExTJyAoRFRMUyBvdmVyIFNDVFApLCBJIGFzc3VtZSB0aGF0IHRoZSBEVExTDQo+ ICAgICAgPj4+PiBjb25uZWN0aW9uIHdpbGwgYWxzbyBiZSByZS1lc3RhYmxpc2hlZCBpZiB0aGUg dW5kZXJseWluZyBTQ1RQDQo+ICAgICAgPj4+PiBhc3NvY2lhdGlvbiBpcyByZS0gZXN0YWJsaXNo ZWQgLSBldmVuIGlmIG5vIHRyYW5zcG9ydCBwYXJhbWV0ZXJzDQo+ICAgICAgPj4+PiBldGMgYXJl IGNoYW5nZWQuDQo+ICAgICAgPj4+Pg0KPiAgICAgID4+Pj4gQWxzbywgUkZDIDYwODMgc2F5czoN Cj4gICAgICA+Pj4+DQo+ICAgICAgPj4+PiAiRWFjaCBEVExTIGNvbm5lY3Rpb24gTVVTVCBiZSBl c3RhYmxpc2hlZCBhbmQgdGVybWluYXRlZA0KPiAgICAgd2l0aGluIHRoZQ0KPiAgICAgID4+Pj4g c2FtZSBTQ1RQIGFzc29jaWF0aW9uLiINCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+Pg0KPiAgICAg ID4+Pj4+IFRoZSB3YXkgdGhpcyBsYW5ndWFnZSByZWFkcyB0byBtZSBpcyB0aGF0IGVuZHBvaW50 cyBjYW4gcmV1c2UgdGhlDQo+ICAgICAgPj4+Pj4gZXhpc3RpbmcNCj4gICAgICA+Pj4+IGFzc29j aWF0aW9uIGlmIHRoZXkgd2FudCB0bywgYnV0IHRoZXkgY2FuIGNyZWF0ZSBhIG5ldyBvbmUgaWYg dGhleQ0KPiAgICAgID4+Pj4gZG9uJ3QuIEFsc28sIHdoZW4gdGhpcyBuZXcNCj4gICAgICA+Pj4+ PiBhc3NvY2lhdGlvbiBpcyBjcmVhdGVkLCBpdCBpcyB1bmNsZWFyIGlmIG9sZCBzZXR1cCByb2xl cyBNVVNUIGJlDQo+ICAgICAgPj4+Pj4gcHJlc2VydmVkDQo+ICAgICAgPj4+PiBvciBpZiB0aGV5 IE1VU1QgYmUgc2VsZWN0ZWQgYmFzZWQgb24gdGhlIGN1cnJlbnQgb2ZmZXIvYW5zd2VyDQo+ICAg ICAgPj4+PiBleGNoYW5nZS4gSXQgc2VlbXMgdGhlIGN1cnJlbnQNCj4gICAgICA+Pj4+PiBzcGVj aWZpY2F0aW9uIGxhbmd1YWdlIGlzIG5vdCBzdHJvbmcgb3IgY2xlYXIgZW5vdWdoIG9uIHRoaXMN Cj4gICAgICA+Pj4+PiB0b3BpYy4NCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+PiBJbiBteSBvcGlu aW9uLCBJRiBhIG5ldyBEVExTIGNvbm5lY3Rpb24gbmVlZHMgdG8gYmUgZXN0YWJsaXNoZWQNCj4g ICAgICA+Pj4+IChmb3Igd2hhdGV2ZXIgcmVhc29ucyksIHRoZSBjdXJyZW50IHJvbGVzIHNob3Vs ZCBiZSB1c2VkLg0KPiAgICAgID4+Pg0KPiAgICAgID4+PiA8UmFqdT4gV2hlbiBJQ0UgaXMgTk9U IHVzZWQsIGhvdyBkb2VzIHRoZSBvZmZlcmVyIGtub3cgdGhhdCB0aGUNCj4gICAgICA+Pj4gYW5z d2VyZXIgZG9lcyBub3QgY2hhbmdlIHRoZSBmaW5nZXJwcmludCBhbmQvb3IgdHJhbnNwb3J0DQo+ ICAgICBwYXJhbWV0ZXJzPw0KPiAgICAgID4+PiBJIGd1ZXNzIGl0IGRvZXMgbm90IGtub3cuIFNv LCBvZmZlcmVyIGhhcyB0byBiZSBwcmVwYXJlZCBmb3INCj4gICAgIG5ldyBEVExTDQo+ICAgICAg Pj4+IGFzc29jaWF0aW9uIGJ5IG9mZmVyaW5nIGFjdHBhc3MuIFdoZW4gSUNFIGlzIHVzZWQsIHRo ZSBhbnN3ZXJlcg0KPiAgICAgY2FuJ3QNCj4gICAgICA+Pj4gY2hhbmdlIHRyYW5zcG9ydCBwYXJh bWV0ZXIgdW5sZXNzIG9mZmVyZXIgZG9lcyBJQ0UgcmVzdGFydCAod2hpY2gNCj4gICAgICA+Pj4g Y2hhbmdlcyBvZmZlcmVyIHRyYW5zcG9ydCBwYXJhbWV0ZXJzKTsgUmVmIFsxXSBpcyB2ZXJ5IGNs ZWFyIG9uDQo+ICAgICB0aGlzDQo+ICAgICAgPj4+IGluZGljYXRpbmcgIkRUTFMgaGFuZHNoYWtl IHByb2NlZHVyZSBpcyByZXBlYXRlZCIuIEhvd2V2ZXIsDQo+ICAgICBldmVuIHdoZW4NCj4gICAg ICA+Pj4gSUNFIGlzIHVzZWQsIEkgZG8gbm90IGZpbmQgYW55IHJlc3RyaWN0aW9uIGFib3V0IGFu c3dlcmVyIG5vdA0KPiAgICAgID4+PiBjaGFuZ2luZyBmaW5nZXJwcmludC4gU28sIGV2ZW4gd2l0 aG91dCBJQ0UgcmVzdGFydCBhbnN3ZXJlciBjYW4NCj4gICAgICA+Pj4gdHJpZ2dlciBhIERUTFMg cmVuZWdvdGlhdGlvbiBieSBjaGFuZ2luZyBpdHMgZmluZ2VycHJpbnQuDQo+ICAgICAgPj4+DQo+ ICAgICAgPj4+IFRvIGNvbmNsdWRlIGFsbCB0aGlzLCBJTU8gd2hldGhlciBJQ0UgaXMgdXNlZCBv ciBub3QsIHNlbmRpbmcNCj4gICAgIGFjdHBhc3MNCj4gICAgICA+Pj4gZm9yIGFsbCBuZXcgb2Zm ZXJzIG1heSBiZSBjb3ZlciBhbGwgcG9zc2libGUgc2NlbmFyaW9zLg0KPiAgICAgID4+DQo+ICAg ICAgPj4gVGhhdCBpcyBhbHNvIG15IGNvbmNsdXNpb24gYmFzZWQgb24gdGhlIGRpc2N1c3Npb24g c28gZmFyLg0KPiAgICAgID4+DQo+ICAgICAgPj4gSSBhbHNvIHRoaW5rIHRoZSBKU0VQIGRyYWZ0 IGFzIGZhciBhcyBkZXRhaWxlZCBvdXQgaXMgY29ycmVjdCwNCj4gICAgIGJ1dCBpbmZvDQo+ICAg ICAgPj4gYWJvdXQgaG93IHRoZSBpbXBsZW1lbnRhdGlvbiBzaG91bGQgYmVoYXZlIGZvciBTdWJz ZXF1ZW50IGFuc3dlcnMgaXMNCj4gICAgICA+PiBtaXNzaW5nLiBUZXh0IHNheWluZyB0aGF0IHRo ZSByb2xlIG11c3QgYmUgbWFpbnRhaW5lZCAodW5sZXNzDQo+ICAgICB0aGVyZSBpcw0KPiAgICAg ID4+IGFuIElDRSByZXN0YXJ0KSBzaG91bGQgYmUgcHV0IGluIHRoZXJlLg0KPiAgICAgID4NCj4g ICAgICA+IDxSYWp1Pg0KPiAgICAgID4gSGkgU3RlZmFuLA0KPiAgICAgID4gTG9va3MgbGlrZSwg dGhlcmUgaXMgc29tZSBtaXN1bmRlcnN0YW5kaW5nIGhlcmUuDQo+DQo+ICAgICBQcm9iYWJseSBt eSBmYXVsdCBpbiB0aGF0IGNhc2UgOikNCj4NCj4gICAgID4gTXkgY29uY2x1c2lvbiBpcyB0byBp bmNsdWRlDQo+ICAgICA+IGFjdHBhc3MsIGJ1dCBub3QgdGhlIHByZXZpb3VzbHkgbmVnb3RpYXRl ZCByb2xlLCBpbiBhbGwgc3Vic2VxdWVudCBvZmZlcnMsDQo+ICAgICA+IG5vdCBqdXN0IGR1cmlu ZyBJQ0UtcmVzdGFydHMuDQo+DQo+ICAgICBJIHRoaW5rIHRoYXQgaXMgd2hhdCB0aGUgSlNFUCBk cmFmdCBzYXlzIC0gYW5kIG15IGNvbmNsdXNpb24gaXMgdGhhdCBpdA0KPiAgICAgX2lzXyBjb3Jy ZWN0Lg0KPg0KPiAgICAgTXkgcG9pbnQgd2FzIHRoYXQgdGhlIF9hbnN3ZXJfIHNob3VsZCAod2hl biBpdCBpcyBhIHN1YnNlcXVlbnQgYW5zd2VyKQ0KPiAgICAgc2hvdWxkIHNheSB0aGUgc2FtZSBy b2xlIGFzIGluIHByZXZpb3VzIGFuc3dlcnMgKHVubGVzcyB0aGVyZSBpcyBhbiBJQ0UNCj4gICAg IHJlc3RhcnQpLg0KPg0KPiBJIGFncmVlIHRoZSBKU0VQIHRleHQgc2hvdWxkIGluZGljYXRlIHRo YXQgcm9sZXMgc2hvdWxkIHN0YXkgdGhlIHNhbWUuDQo+IFdlIGhhdmUgaGFkIHRoaXMgYXMgYSBU T0RPIGZvciBhIHdoaWxlOg0KPiBodHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAvaXNz dWVzLzcyDQoNCkdyZWF0LiBJIHNob3VsZCBoYXZlIGNoZWNrZWQgdGhhdCBvdXQgYmVmb3JlLg0K DQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D578C4DESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNt Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K cC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ V2hhdCBhYm91dCB0aGUgZm9sbG93aW5nIHRleHQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+OC4zLjIuJm5ic3A7 IFRMUyBSb2xlIERldGVybWluYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBJZiB0aGUgbS0gbGluZSBwcm90 byBmaWVsZCB2YWx1ZSBpcyAnU0NUUC9EVExTJyBvciAnRFRMUy9TQ1RQJywgdGhlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyBTRFAgc2V0dXAgYXR0cmlidXRlIFtSRkM0MTQ1XSBpcyB1c2VkIHRvIGRldGVybWluZSB0aGUg J2FjdGl2ZS88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IHBhc3NpdmUnIHN0YXR1cyBvZiB0aGUgb2ZmZXJlciBhbmQgYW5z d2VyZXIuJm5ic3A7IFRoZSAnYWN0aXZlL3Bhc3NpdmUnPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBzdGF0dXMgd2lsbCBi ZSB1c2VkIHRvIGRldGVybWluZSB0aGUgVExTIHJvbGVzLCBmb2xsb3dpbmcgdGhlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyBwcm9jZWR1cmVzIGluIFtSRkM0NTcyXSAodGhlICdhY3RpdmUnIGVuZHBvaW50IHdpbGwgdGFr ZSB0aGUgVExTIGNsaWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcm9sZSkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgT25jZSBhIERU TFMgY29ubmVjdGlvbiBoYXMgYmVlbiBlc3RhYmxpc2hlZCwgaWYgdGhlICdhY3RpdmUvcGFzc2l2 ZSc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IHN0YXR1cyBvZiB0aGUgZW5kcG9pbnRzIGNoYW5nZSBkdXJpbmcgYSBzZXNz aW9uLCBhIG5ldyBEVExTPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBjb25uZWN0aW9uIE1VU1QgYmUgZXN0YWJsaXNoZWQu Jm5ic3A7IFRoZXJlZm9yZSwgZW5kcG9pbnRzIFNIT1VMRCBOT1Q8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGNoYW5nZSB0 aGUg4oCYYWN0aXZlL3Bhc3NpdmXigJkgc3RhdHVzIGluIHN1YnNlcXVlbnQgb2ZmZXJzIGFuZCBh bnN3ZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgdW5sZXNzIHRoZXkgd2FudCB0byBlc3RhYmxpc2ggYSBuZXcgRFRM UyBjb25uZWN0aW9uIChpbiB3aGljaCBjYXNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0aGUgbmV3ICdhY3RpdmUvcGFz c2l2ZScgc3RhdHVzIG9mIHRoZSBvZmZlcmVyIGFuZCBhbnN3ZXJlciB3aWxsIGJlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyB1c2VkIHRvIGRldGVybWluZSB0aGUgVExTIHJvbGVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgbmV3 IERUTFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IGNvbm5lY3Rpb24pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IE5PVEU6IFRoZSBwcm9j ZWR1cmUgYWJvdmUgaXMgaWRlbnRpY2FsIHRvIHRoZSBvbmUgZGVmaW5lZCBmb3IgU1JUUC08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IERUTFMgaW4gW1JGQzU3NjNdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgW21haWx0 bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0ZXIg SG9sbWJlcmc8YnI+DQo8Yj5TZW50OjwvYj4gNC4gam91bHVrdXV0YSAyMDE0IDg6NTU8YnI+DQo8 Yj5Ubzo8L2I+IEp1c3RpbiBVYmVydGk8YnI+DQo8Yj5DYzo8L2I+IHJ0Y3dlYkBpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gSlNFUDogV2h5IGFsd2F5cyBvZmZlciBh Y3RwYXNzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZdmUgbWlzc2VkIHRo YXQuIEF3ZXNvbWUhIDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbywgaWYgd2XigJlyZSBvayB3aXRoIHRoYXQgYXBw cm9hY2gsIHRoZW4gd2Ugc2hvdWxkIHVzZSBzaW1pbGFyIHRleHQgaW4gdGhlIFNDVFAtU0RQIGRy YWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4gVWJlcnRpIFs8YSBocmVmPSJtYWls dG86anViZXJ0aUBnb29nbGUuY29tIj5tYWlsdG86anViZXJ0aUBnb29nbGUuY29tPC9hPl0NCjxi cj4NCjxiPlNlbnQ6PC9iPiA0LiBqb3VsdWt1dXRhIDIwMTQgODo1Mzxicj4NCjxiPlRvOjwvYj4g Q2hyaXN0ZXIgSG9sbWJlcmc8YnI+DQo8Yj5DYzo8L2I+IFN0ZWZhbiBIw6VrYW5zc29uIExLOyBN YWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUpOyBSb21hbiBTaHBvdW50OyA8YSBocmVmPSJtYWls dG86cnRjd2ViQGlldGYub3JnIj4NCnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtydGN3ZWJdIEpTRVA6IFdoeSBhbHdheXMgb2ZmZXIgYWN0cGFzcz88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj41NzYzLCBTIDYuNiBzZWVtcyB0byBpbXBs eSB0aGF0OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwO05vdGUgdGhhdCBpZiB0aGUgYWN0aXZlL3Bhc3NpdmUgc3RhdHVzIG9mIHRoZSBl bmRwb2ludHMgY2hhbmdlcywgYSBuZXc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO2Nvbm5lY3Rpb24gTVVTVCBiZSBlc3RhYmxpc2hlZC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIFdlZCwgRGVjIDMsIDIwMTQgYXQgMTA6MzAgUE0sIENocmlzdGVyIEhvbG1iZXJn ICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJn ZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlNvLCBvbmUgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBzYXkgdGhhdCwgSUYgb25lICh0aGVyZSBv ZmZlcmVyIG9yIGFuc3dlcmVyKSBjaGFuZ2VzIHRoZSBwcmV2aW91c2x5DQogbmVnb3RpYXRlZCBy b2xlcywgdGhlIERUTFMgY29ubmVjdGlvbiBNVVNUIGJlIHJlLWVzdGFibGlzaGVkIOKAkyBldmVu IGlmIHRoZSB0cmFuc3BvcnQgcGFyYW1ldGVycyBldGMgYXJlbuKAmXQgY2hhbmdlZC4gSSB0aGlu ayB0aGF0IHdvdWxkIGJlIGEgdmVyeSB1c2VmdWwgY2xhcmlmaWNhdGlvbi48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSnVzdGluIFViZXJ0aSBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpqdWJlcnRpQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5qdWJlcnRpQGdvb2dsZS5j b208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDQuIGpvdWx1a3V1dGEgMjAxNCA3OjQ5PGJyPg0K PGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPkNjOjwvYj4gU3RlZmFuIEjDpWth bnNzb24gTEs7IE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSk7IFJvbWFuIFNocG91bnQ7IDxh IGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnJ0Y3dlYkBp ZXRmLm9yZzwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gSlNFUDogV2h5 IGFsd2F5cyBvZmZlciBhY3RwYXNzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkN1cnJlbnRseSwgQ2hyb21lIGVycm9ycyBv dXQgKGkuZS4gc2V0UkQgZmFpbHMpLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkhvd2V2ZXIsIEkgc3VzcGVjdCB0aGF0IHRlYXJkb3duIG9mIHRoZSBv bGQgRFRMUyBhc3NvY2lhdGlvbiBhbmQgc2V0dXAgb2YgYSBuZXcgRFRMUyBhc3NvY2lhdGlvbiBp cyB0aGUgZGVzaXJlZCBiZWhhdmlvci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgRGVjIDMsIDIwMTQgYXQgODozNCBQTSwg Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ SGksPGJyPg0KPGJyPg0KSXNzdWUgIzcyIHRhbGtzIGFib3V0IG1haW50YWluaW5nIHRoZSBwcmV2 aW91c2x5IG5lZ290aWF0ZWQgcm9sZSB3aGVuIGFjdHBhc3MgaXMgcmVjZWl2ZWQuIEkgdGhpbmsg dGhhdCBpcyBhIGdvb2QgYXBwcm9hY2gsIGFuZCBjb3VsZCBiZSB1c2VkIGluIE9mZmVyL0Fuc3dl ciB0b28uPGJyPg0KPGJyPg0KQlVULCB3aGF0IGRvZXMgdGhlIGJyb3dzZXIgZG8gaWYgZS5nLiB0 aGUgcHJldmlvdXMgcm9sZSBpcyBwYXNzaXZlIGFuZCBhY3RpdmUgaXMgcmVjZWl2ZWQ/PGJyPg0K PGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpDaHJpc3Rlcjxicj4NCjxicj4NClNlbnQgZnJvbSBt eSBXaW5kb3dzIFBob25lPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFs aWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJt YWlsdG86c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5T dGVmYW4gSMOla2Fuc3NvbiBMSzwvYT48L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5TZW50OiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij7igI4wMy/igI4xMi/igI4yMDE0IDE3OjQ4PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+VG86IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+SnVz dGluIFViZXJ0aTwvYT48L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5DYzogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1h aWx0bzpSYWp1Lk1ha2FyYWp1QGFsY2F0ZWwtbHVjZW50LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1h a2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSk8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkNocmlzdGVyIEhvbG1iZXJn PC9hPjsNCjxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsi PlJvbWFuIFNocG91bnQ8L2E+OyA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+DQpydGN3ZWJAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3ViamVjdDogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+UmU6IFtydGN3ZWJdIEpTRVA6IFdoeSBhbHdheXMgb2ZmZXIgYWN0cGFz cz88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+T24g MDEvMTIvMTQgMTg6MjYsIEp1c3RpbiBVYmVydGkgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IE9uIFN1biwgTm92IDMwLCAyMDE0IGF0IDc6MjYgQU0sIFN0ZWZhbiBIw6VrYW5z c29uIExLPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZWZhbi5say5oYWthbnNzb25A ZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nv bi5jb208L2E+PGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZWZhbi5say5oYWthbnNz b25AZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnN0ZWZhbi5say5oYWthbnNz b25AZXJpY3Nzb24uY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIDMwLzExLzE0IDE2OjA2LCBNYWthcmFqdSwgTWFyaWRp IFJhanUgKFJhanUpIHdyb3RlOjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyZndDsgT24gMzAvMTEvMTQgMTQ6NTEsIE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFq dSkgd3JvdGU6PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7IEhpLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJGQyA3MzQ1IChVRFBUTC1EVExTKSBzYXlzIHRoZSBmb2xs b3dpbmc6PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmcXVvdDtPbmNlIGFuIG9mZmVyL2Fuc3dlciBleGNoYW5n ZSBoYXMgYmVlbiBjb21wbGV0ZWQsIGVpdGhlcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGVuZHBvaW50PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IE1BWTxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHNlbmQgYSBuZXcgb2ZmZXIgaW4gb3JkZXIgdG8gbW9kaWZ5IHRoZSBzZXNzaW9uLiZuYnNwOyBU aGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBlbmRwb2ludHM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsgY2FuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmV1c2UgdGhlIGV4aXN0aW5nIERUTFMg YXNzb2NpYXRpb24gaWYgdGhlIGtleSBmaW5nZXJwcmludDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHZhbHVlczxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBhbmQ8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyB0cmFuc3BvcnQgcGFyYW1ldGVycyBpbmRpY2F0ZWQgYnkgZWFjaCBlbmRwb2ludCBhcmUg dW5jaGFuZ2VkLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IE90aGVyd2lzZSwgZm9sbG93aW5nIHRoZSBydWxlcyBmb3IgdGhl IGluaXRpYWwgb2ZmZXIvYW5zd2VyPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IGV4Y2hhbmdlLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBlbmRwb2ludHMgY2Fu IG5lZ290aWF0ZSBhbmQgY3JlYXRlIGEgbmV3IERUTFMgYXNzb2NpYXRpb248YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbmQs IG9uY2UgY3JlYXRlZCwgZGVsZXRlIHRoZSBwcmV2aW91cyBEVExTIGFzc29jaWF0aW9uLDxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGZvbGxvd2luZyB0aGUgc2FtZSBydWxlcyBmb3IgdGhlIGluaXRpYWwgb2ZmZXIvYW5zd2Vy IGV4Y2hhbmdlLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IEVhY2ggZW5kcG9pbnQgbmVlZHMgdG8gYmUgcHJlcGFyZWQgdG8g cmVjZWl2ZSBkYXRhIG9uIGJvdGggdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbmV3IGFuZCBvbGQgRFRMUyBhc3NvY2lh dGlvbnMgYXMgbG9uZyBhcyBib3RoIGFyZSBhbGl2ZS4mcXVvdDs8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNv LCBJIGd1ZXNzIHRoYXQgY2FuIGJlIHJlYWQgaW4gYSB3YXkgdGhhdCB0aGUgc2V0dXAgYXR0cmli dXRlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgYXMgc3VjaDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyBkb2VzIG5vdCBpbXBhY3QgcHJldmlvdXNseTxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG5l Z290aWF0ZWQgVExTIHJvbGVzIC0gdW5sZXNzIHRoZSBrZXkgZmluZ2VycHJpbnQgdmFsdWVzIGFu ZC9vcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHRyYW5zcG9ydDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBwYXJhbWV0ZXJzIGFyZSBtb2RpZmllZC48YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFRoZSBTQ1RQLVNEUCBkcmFmdCBjdXJyZW50bHkgc2F5cyB0aGF0IGEgc3Vic2VxdWVu dCBvZmZlciBtdXN0PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbm90IGNoYW5nZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyB0aGUgcHJldmlvdXNseSBuZWdvdGlhdGVk IHJvbGVzLiBCdXQsIEkgZ3Vlc3M8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3ZSBjb3VsZCBzYXkgc29tZXRoaW5nIHNpbWls YXIgYXMgaW4gUkZDIDczNDUuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBoYXZlIHN0cnVnZ2xlZCB3aXRoIHRoaXMgbGFu Z3VhZ2UgcXVpdGUgYSBiaXQgZnJvbSB0aGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGltcGxlbWVudGF0aW9uPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IHBlcnNwZWN0aXZl LiBJIHRoaW5rIHdlIG5lZWQgdG8gZXhwbGljaXRseSBzdGF0ZTxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCBlbmRwb2ludHMg TVVTVCByZXVzZSB0aGUgZXhpc3RpbmcgYXNzb2NpYXRpb24gaWYgdGhlIGtleTxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZmluZ2Vy cHJpbnQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsgdmFsdWVzIGFuZCB0cmFuc3BvcnQgcGFyYW1ldGVycyBpbmRpY2F0ZWQ8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGJ5IGVh Y2ggZW5kcG9pbnQgYXJlIHVuY2hhbmdlZC48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgV2UgY291bGQgdGFrZSBzdWNoIGdlbmVyYWwgYXBw cm9hY2guPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7IEhvd2V2ZXIsIGZvciAnU0NUUC9EVExTJyAoRFRMUyBvdmVyIFNDVFApLCBJIGFzc3Vt ZSB0aGF0IHRoZSBEVExTPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7IGNvbm5lY3Rpb24gd2lsbCBhbHNvIGJlIHJlLWVzdGFibGlzaGVkIGlm IHRoZSB1bmRlcmx5aW5nIFNDVFA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsgYXNzb2NpYXRpb24gaXMgcmUtIGVzdGFibGlzaGVkIC0gZXZl biBpZiBubyB0cmFuc3BvcnQgcGFyYW1ldGVyczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBldGMgYXJlIGNoYW5nZWQuPGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IEFsc28sIFJGQyA2 MDgzIHNheXM6PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7ICZxdW90O0VhY2ggRFRMUyBjb25uZWN0aW9uIE1VU1QgYmUgZXN0YWJsaXNoZWQg YW5kIHRlcm1pbmF0ZWQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdpdGhpbiB0 aGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDsgc2FtZSBTQ1RQIGFzc29jaWF0aW9uLiZxdW90Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIHdheSB0aGlzIGxhbmd1YWdl IHJlYWRzIHRvIG1lIGlzIHRoYXQgZW5kcG9pbnRzIGNhbiByZXVzZSB0aGU8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGV4aXN0aW5n PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 IGFzc29jaWF0aW9uIGlmIHRoZXkgd2FudCB0bywgYnV0IHRoZXkgY2FuIGNyZWF0ZSBhIG5ldyBv bmUgaWYgdGhleTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyBkb24ndC4gQWxzbywgd2hlbiB0aGlzIG5ldzxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXNzb2NpYXRpb24gaXMg Y3JlYXRlZCwgaXQgaXMgdW5jbGVhciBpZiBvbGQgc2V0dXAgcm9sZXMgTVVTVCBiZTxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcHJl c2VydmVkPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7IG9yIGlmIHRoZXkgTVVTVCBiZSBzZWxlY3RlZCBiYXNlZCBvbiB0aGUgY3VycmVudCBv ZmZlci9hbnN3ZXI8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsgZXhjaGFuZ2UuIEl0IHNlZW1zIHRoZSBjdXJyZW50PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzcGVjaWZpY2F0 aW9uIGxhbmd1YWdlIGlzIG5vdCBzdHJvbmcgb3IgY2xlYXIgZW5vdWdoIG9uIHRoaXM8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRv cGljLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyBJbiBteSBvcGluaW9uLCBJRiBhIG5ldyBEVExTIGNvbm5lY3Rpb24gbmVlZHMgdG8gYmUg ZXN0YWJsaXNoZWQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsgKGZvciB3aGF0ZXZlciByZWFzb25zKSwgdGhlIGN1cnJlbnQgcm9sZXMgc2hv dWxkIGJlIHVzZWQuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyAmbHQ7UmFqdSZndDsgV2hlbiBJQ0UgaXMgTk9UIHVzZWQsIGhvdyBkb2VzIHRoZSBvZmZl cmVyIGtub3cgdGhhdCB0aGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyBhbnN3ZXJlciBkb2VzIG5vdCBjaGFuZ2UgdGhlIGZpbmdlcnByaW50IGFu ZC9vciB0cmFuc3BvcnQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhcmFtZXRl cnM/PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsg SSBndWVzcyBpdCBkb2VzIG5vdCBrbm93LiBTbywgb2ZmZXJlciBoYXMgdG8gYmUgcHJlcGFyZWQg Zm9yPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBuZXcgRFRMUzxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IGFzc29jaWF0aW9uIGJ5 IG9mZmVyaW5nIGFjdHBhc3MuIFdoZW4gSUNFIGlzIHVzZWQsIHRoZSBhbnN3ZXJlcjxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2FuJ3Q8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBjaGFuZ2UgdHJhbnNwb3J0IHBhcmFtZXRlciB1 bmxlc3Mgb2ZmZXJlciBkb2VzIElDRSByZXN0YXJ0ICh3aGljaDxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IGNoYW5nZXMgb2ZmZXJlciB0cmFuc3Bv cnQgcGFyYW1ldGVycyk7IFJlZiBbMV0gaXMgdmVyeSBjbGVhciBvbjxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgdGhpczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7IGluZGljYXRpbmcgJnF1b3Q7RFRMUyBoYW5kc2hha2UgcHJvY2Vk dXJlIGlzIHJlcGVhdGVkJnF1b3Q7LiBIb3dldmVyLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgZXZlbiB3aGVuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jmd0OyZndDsgSUNFIGlzIHVzZWQsIEkgZG8gbm90IGZpbmQgYW55IHJlc3RyaWN0aW9u IGFib3V0IGFuc3dlcmVyIG5vdDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyZndDsmZ3Q7IGNoYW5naW5nIGZpbmdlcnByaW50LiBTbywgZXZlbiB3aXRob3V0IElD RSByZXN0YXJ0IGFuc3dlcmVyIGNhbjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7IHRyaWdnZXIgYSBEVExTIHJlbmVnb3RpYXRpb24gYnkgY2hhbmdp bmcgaXRzIGZpbmdlcnByaW50Ljxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OyZndDsgVG8gY29uY2x1ZGUgYWxsIHRoaXMsIElNTyB3aGV0aGVyIElDRSBpcyB1c2Vk IG9yIG5vdCwgc2VuZGluZzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWN0cGFz czxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IGZv ciBhbGwgbmV3IG9mZmVycyBtYXkgYmUgY292ZXIgYWxsIHBvc3NpYmxlIHNjZW5hcmlvcy48YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBUaGF0IGlzIGFsc28gbXkgY29u Y2x1c2lvbiBiYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbiBzbyBmYXIuPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgSSBhbHNvIHRoaW5rIHRoZSBKU0VQIGRyYWZ0IGFzIGZh ciBhcyBkZXRhaWxlZCBvdXQgaXMgY29ycmVjdCw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGJ1dCBpbmZvPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OyBhYm91dCBob3cgdGhlIGltcGxlbWVudGF0aW9uIHNob3VsZCBiZWhhdmUgZm9yIFN1 YnNlcXVlbnQgYW5zd2VycyBpczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyZndDsgbWlzc2luZy4gVGV4dCBzYXlpbmcgdGhhdCB0aGUgcm9sZSBtdXN0IGJlIG1h aW50YWluZWQgKHVubGVzczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlcmUg aXM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IGFuIElD RSByZXN0YXJ0KSBzaG91bGQgYmUgcHV0IGluIHRoZXJlLjxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyAmbHQ7UmFqdSZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgSGkgU3RlZmFuLDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyBMb29rcyBsaWtlLCB0aGVyZSBpcyBzb21lIG1pc3VuZGVyc3RhbmRpbmcgaGVy ZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQcm9iYWJseSBt eSBmYXVsdCBpbiB0aGF0IGNhc2UgOik8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7IE15IGNvbmNsdXNpb24gaXMgdG8gaW5jbHVkZTxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBhY3RwYXNzLCBidXQgbm90IHRoZSBwcmV2aW91c2x5 IG5lZ290aWF0ZWQgcm9sZSwgaW4gYWxsIHN1YnNlcXVlbnQgb2ZmZXJzLDxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBub3QganVzdCBkdXJpbmcgSUNFLXJlc3RhcnRzLjxi cj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgdGhpbmsgdGhhdCBp cyB3aGF0IHRoZSBKU0VQIGRyYWZ0IHNheXMgLSBhbmQgbXkgY29uY2x1c2lvbiBpcyB0aGF0IGl0 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBfaXNfIGNvcnJlY3QuPGJyPg0KJmd0 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTXkgcG9pbnQgd2FzIHRoYXQgdGhl IF9hbnN3ZXJfIHNob3VsZCAod2hlbiBpdCBpcyBhIHN1YnNlcXVlbnQgYW5zd2VyKTxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2hvdWxkIHNheSB0aGUgc2FtZSByb2xlIGFzIGlu IHByZXZpb3VzIGFuc3dlcnMgKHVubGVzcyB0aGVyZSBpcyBhbiBJQ0U8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc3RhcnQpLjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgYWdyZWUg dGhlIEpTRVAgdGV4dCBzaG91bGQgaW5kaWNhdGUgdGhhdCByb2xlcyBzaG91bGQgc3RheSB0aGUg c2FtZS48YnI+DQomZ3Q7IFdlIGhhdmUgaGFkIHRoaXMgYXMgYSBUT0RPIGZvciBhIHdoaWxlOjxi cj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13Zy9qc2VwL2lzc3Vl cy83MiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cvanNlcC9p c3N1ZXMvNzI8L2E+PGJyPg0KPGJyPg0KR3JlYXQuIEkgc2hvdWxkIGhhdmUgY2hlY2tlZCB0aGF0 IG91dCBiZWZvcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D578C4DESESSMB209erics_-- From nobody Thu Dec 4 05:57:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC061AD390 for ; Thu, 4 Dec 2014 05:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRWU6cpZqiun for ; Thu, 4 Dec 2014 05:57:45 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA881A1B10 for ; Thu, 4 Dec 2014 05:57:44 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-9d-5480685683ad Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C5.1C.04231.65860845; Thu, 4 Dec 2014 14:57:43 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 14:57:42 +0100 From: =?utf-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= To: Christer Holmberg , Justin Uberti Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JA== Date: Thu, 4 Dec 2014 13:57:42 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D0EE9AC@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE2BC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577322@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577B77@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577CB5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D578C4D@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvjW54RkOIwYlfzBZbpwpZrP3Xzu7A 5LFgU6nHkiU/mQKYorhsUlJzMstSi/TtErgy+tb/Zi7YlFnxf/p09gbGG2ldjJwcEgImEr8n 7GGFsMUkLtxbz9bFyMUhJHCEUeLInU+MEM5iRomW/w+YQKrYBIIlLsxsA7NFBGIkfvXdYQSx mQXUJe4sPscOYgsLmEpMurgMqsZMYuHJCYwQtp7EzS8XWEBsFgEViebH/8BsXgFfiY239zFD LPvMI9G24wozSIIR6KTvp9YwQSwQl7j1ZD4TxKkCEkv2nGeGsEUlXj7+B/WCosTV6cuBajiA 6jUl1u/Sh2hVlJjS/ZAdYpegxMmZT1gmMIrOQjJ1FkLHLCQds5B0LGBkWcUoWpxaXJybbmSs l1qUmVxcnJ+nl5dasokRGCMHt/zW3cG4+rXjIUYBDkYlHl6Dc/UhQqyJZcWVuYcYpTlYlMR5 F52bFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMW1zdHAD85V7bPeFN26VZQzRODfF6Jvy LYFFTz59On3n2MTdQY/FWT2fmd327mk7wLVTpDzjl/5q6SmnZ2xbL7nypvxu7e/JGQr2qR7T q5MvMOSe5n7no29jusoioKL58xGHB38jlugnl4gnny9e9OstSy/3f7mFRWkvQ+eUs/UtrtqZ teFxnRJLcUaioRZzUXEiAGT6cvxyAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/T72jL4jS0VTW0KTBNTErJgJVsVk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 13:57:48 -0000 T24gMDQvMTIvMTQgMTQ6NDMsIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOgo+IFdoYXQgYWJvdXQg dGhlIGZvbGxvd2luZyB0ZXh0Ogo+Cj4gOC4zLjIuICBUTFMgUm9sZSBEZXRlcm1pbmF0aW9uCj4K PiAgICAgSWYgdGhlIG0tIGxpbmUgcHJvdG8gZmllbGQgdmFsdWUgaXMgJ1NDVFAvRFRMUycgb3Ig J0RUTFMvU0NUUCcsIHRoZQo+Cj4gICAgIFNEUCBzZXR1cCBhdHRyaWJ1dGUgW1JGQzQxNDVdIGlz IHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSAnYWN0aXZlLwo+Cj4gICAgIHBhc3NpdmUnIHN0YXR1cyBv ZiB0aGUgb2ZmZXJlciBhbmQgYW5zd2VyZXIuICBUaGUgJ2FjdGl2ZS9wYXNzaXZlJwo+Cj4gICAg IHN0YXR1cyB3aWxsIGJlIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBUTFMgcm9sZXMsIGZvbGxvd2lu ZyB0aGUKPgo+ICAgICBwcm9jZWR1cmVzIGluIFtSRkM0NTcyXSAodGhlICdhY3RpdmUnIGVuZHBv aW50IHdpbGwgdGFrZSB0aGUgVExTIGNsaWVudAo+Cj4gICAgIHJvbGUpLgo+Cj4gICAgIE9uY2Ug YSBEVExTIGNvbm5lY3Rpb24gaGFzIGJlZW4gZXN0YWJsaXNoZWQsIGlmIHRoZSAnYWN0aXZlL3Bh c3NpdmUnCj4KPiAgICAgc3RhdHVzIG9mIHRoZSBlbmRwb2ludHMgY2hhbmdlIGR1cmluZyBhIHNl c3Npb24sIGEgbmV3IERUTFMKPgo+ICAgICBjb25uZWN0aW9uIE1VU1QgYmUgZXN0YWJsaXNoZWQu ICBUaGVyZWZvcmUsIGVuZHBvaW50cyBTSE9VTEQgTk9UCj4KPiAgICAgY2hhbmdlIHRoZSDigJhh Y3RpdmUvcGFzc2l2ZeKAmSBzdGF0dXMgaW4gc3Vic2VxdWVudCBvZmZlcnMgYW5kIGFuc3dlcnMs CgpEaWQgbm90IHRoZSBkaXNjdXNzaW9uIChmb3IgcnRjd2ViKSBjb25jbHVkZSB0aGF0IHN1YnNl cXVlbnQgb2ZmZXJzIApzaG91bGQgb2ZmZXIgYWN0cGFzcywgYnV0IHRoYXQgc3Vic2VxdWVudCBh bnN3ZXJzIG11c3Qgc2F5IHRoZSBzYW1lIGFzIAp0aGUgcHJldmlvdXMgYW5zd2VyPwoKPgo+ICAg ICB1bmxlc3MgdGhleSB3YW50IHRvIGVzdGFibGlzaCBhIG5ldyBEVExTIGNvbm5lY3Rpb24gKGlu IHdoaWNoIGNhc2UKPgo+ICAgICB0aGUgbmV3ICdhY3RpdmUvcGFzc2l2ZScgc3RhdHVzIG9mIHRo ZSBvZmZlcmVyIGFuZCBhbnN3ZXJlciB3aWxsIGJlCj4KPiAgICAgdXNlZCB0byBkZXRlcm1pbmUg dGhlIFRMUyByb2xlcyBhc3NvY2lhdGVkIHdpdGggdGhlIG5ldyBEVExTCj4KPiAgICAgY29ubmVj dGlvbikuCj4KPiAgICAgTk9URTogVGhlIHByb2NlZHVyZSBhYm92ZSBpcyBpZGVudGljYWwgdG8g dGhlIG9uZSBkZWZpbmVkIGZvciBTUlRQLQo+Cj4gICAgIERUTFMgaW4gW1JGQzU3NjNdLgo+Cj4g UmVnYXJkcywKPgo+IENocmlzdGVyCj4KPiAqRnJvbToqcnRjd2ViIFttYWlsdG86cnRjd2ViLWJv dW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKkNocmlzdGVyCj4gSG9sbWJlcmcKPiAqU2Vu dDoqIDQuIGpvdWx1a3V1dGEgMjAxNCA4OjU1Cj4gKlRvOiogSnVzdGluIFViZXJ0aQo+ICpDYzoq IHJ0Y3dlYkBpZXRmLm9yZwo+ICpTdWJqZWN0OiogUmU6IFtydGN3ZWJdIEpTRVA6IFdoeSBhbHdh eXMgb2ZmZXIgYWN0cGFzcz8KPgo+IEnigJl2ZSBtaXNzZWQgdGhhdC4gQXdlc29tZSEgOikKPgo+ IFNvLCBpZiB3ZeKAmXJlIG9rIHdpdGggdGhhdCBhcHByb2FjaCwgdGhlbiB3ZSBzaG91bGQgdXNl IHNpbWlsYXIgdGV4dCBpbgo+IHRoZSBTQ1RQLVNEUCBkcmFmdC4KPgo+IFJlZ2FyZHMsCj4KPiBD aHJpc3Rlcgo+Cj4gKkZyb206Kkp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5j b21dCj4gKlNlbnQ6KiA0LiBqb3VsdWt1dXRhIDIwMTQgODo1Mwo+ICpUbzoqIENocmlzdGVyIEhv bG1iZXJnCj4gKkNjOiogU3RlZmFuIEjDpWthbnNzb24gTEs7IE1ha2FyYWp1LCBNYXJpZGkgUmFq dSAoUmFqdSk7IFJvbWFuIFNocG91bnQ7Cj4gcnRjd2ViQGlldGYub3JnIDxtYWlsdG86cnRjd2Vi QGlldGYub3JnPgo+ICpTdWJqZWN0OiogUmU6IFtydGN3ZWJdIEpTRVA6IFdoeSBhbHdheXMgb2Zm ZXIgYWN0cGFzcz8KPgo+IDU3NjMsIFMgNi42IHNlZW1zIHRvIGltcGx5IHRoYXQ6Cj4KPiAgIE5v dGUgdGhhdCBpZiB0aGUgYWN0aXZlL3Bhc3NpdmUgc3RhdHVzIG9mIHRoZSBlbmRwb2ludHMgY2hh bmdlcywgYSBuZXcKPgo+ICAgY29ubmVjdGlvbiBNVVNUIGJlIGVzdGFibGlzaGVkLgo+Cj4gT24g V2VkLCBEZWMgMywgMjAxNCBhdCAxMDozMCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcKPiA8Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIDxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPj4KPiB3cm90ZToKPgo+IEhpLAo+Cj4gU28sIG9uZSBzdWdnZXN0aW9uIHdvdWxkIGJl IHRvIHNheSB0aGF0LCBJRiBvbmUgKHRoZXJlIG9mZmVyZXIgb3IKPiBhbnN3ZXJlcikgY2hhbmdl cyB0aGUgcHJldmlvdXNseSBuZWdvdGlhdGVkIHJvbGVzLCB0aGUgRFRMUyBjb25uZWN0aW9uCj4g TVVTVCBiZSByZS1lc3RhYmxpc2hlZCDigJMgZXZlbiBpZiB0aGUgdHJhbnNwb3J0IHBhcmFtZXRl cnMgZXRjIGFyZW7igJl0Cj4gY2hhbmdlZC4gSSB0aGluayB0aGF0IHdvdWxkIGJlIGEgdmVyeSB1 c2VmdWwgY2xhcmlmaWNhdGlvbi4KPgo+IFJlZ2FyZHMsCj4KPiBDaHJpc3Rlcgo+Cj4gKkZyb206 Kkp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20KPiA8bWFpbHRvOmp1YmVy dGlAZ29vZ2xlLmNvbT5dCj4gKlNlbnQ6KiA0LiBqb3VsdWt1dXRhIDIwMTQgNzo0OQo+ICpUbzoq IENocmlzdGVyIEhvbG1iZXJnCj4gKkNjOiogU3RlZmFuIEjDpWthbnNzb24gTEs7IE1ha2FyYWp1 LCBNYXJpZGkgUmFqdSAoUmFqdSk7IFJvbWFuIFNocG91bnQ7Cj4gcnRjd2ViQGlldGYub3JnIDxt YWlsdG86cnRjd2ViQGlldGYub3JnPgo+Cj4KPiAqU3ViamVjdDoqIFJlOiBbcnRjd2ViXSBKU0VQ OiBXaHkgYWx3YXlzIG9mZmVyIGFjdHBhc3M/Cj4KPiBDdXJyZW50bHksIENocm9tZSBlcnJvcnMg b3V0IChpLmUuIHNldFJEIGZhaWxzKS4KPgo+IEhvd2V2ZXIsIEkgc3VzcGVjdCB0aGF0IHRlYXJk b3duIG9mIHRoZSBvbGQgRFRMUyBhc3NvY2lhdGlvbiBhbmQgc2V0dXAKPiBvZiBhIG5ldyBEVExT IGFzc29jaWF0aW9uIGlzIHRoZSBkZXNpcmVkIGJlaGF2aW9yLgo+Cj4gT24gV2VkLCBEZWMgMywg MjAxNCBhdCA4OjM0IFBNLCBDaHJpc3RlciBIb2xtYmVyZwo+IDxjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20gPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+Pgo+IHdy b3RlOgo+Cj4gSGksCj4KPiBJc3N1ZSAjNzIgdGFsa3MgYWJvdXQgbWFpbnRhaW5pbmcgdGhlIHBy ZXZpb3VzbHkgbmVnb3RpYXRlZCByb2xlIHdoZW4KPiBhY3RwYXNzIGlzIHJlY2VpdmVkLiBJIHRo aW5rIHRoYXQgaXMgYSBnb29kIGFwcHJvYWNoLCBhbmQgY291bGQgYmUgdXNlZAo+IGluIE9mZmVy L0Fuc3dlciB0b28uCj4KPiBCVVQsIHdoYXQgZG9lcyB0aGUgYnJvd3NlciBkbyBpZiBlLmcuIHRo ZSBwcmV2aW91cyByb2xlIGlzIHBhc3NpdmUgYW5kCj4gYWN0aXZlIGlzIHJlY2VpdmVkPwo+Cj4g UmVnYXJkcywKPgo+IENocmlzdGVyCj4KPiBTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZQo+Cj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCj4KPiAqRnJvbTogKlN0ZWZhbiBIw6VrYW5zc29uIExLIDxtYWlsdG86 c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5jb20+Cj4gKlNlbnQ6ICrigI4wMy/igI4xMi/i gI4yMDE0IDE3OjQ4Cj4gKlRvOiAqSnVzdGluIFViZXJ0aSA8bWFpbHRvOmp1YmVydGlAZ29vZ2xl LmNvbT4KPiAqQ2M6ICpNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUpCj4gPG1haWx0bzpSYWp1 Lk1ha2FyYWp1QGFsY2F0ZWwtbHVjZW50LmNvbT47IENocmlzdGVyIEhvbG1iZXJnCj4gPG1haWx0 bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBSb21hbiBTaHBvdW50Cj4gPG1haWx0 bzpyb21hbkB0ZWx1cml4LmNvbT47IHJ0Y3dlYkBpZXRmLm9yZyA8bWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZz4KPiAqU3ViamVjdDogKlJlOiBbcnRjd2ViXSBKU0VQOiBXaHkgYWx3YXlzIG9mZmVyIGFj dHBhc3M/Cj4KPiBPbiAwMS8xMi8xNCAxODoyNiwgSnVzdGluIFViZXJ0aSB3cm90ZToKPj4KPj4K Pj4gT24gU3VuLCBOb3YgMzAsIDIwMTQgYXQgNzoyNiBBTSwgU3RlZmFuIEjDpWthbnNzb24gTEsK Pj4gPHN0ZWZhbi5say5oYWthbnNzb25AZXJpY3Nzb24uY29tIDxtYWlsdG86c3RlZmFuLmxrLmhh a2Fuc3NvbkBlcmljc3Nvbi5jb20+Cj4+IDxtYWlsdG86c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmlj c3Nvbi5jb20+PiB3cm90ZToKPj4KPj4gICAgIE9uIDMwLzExLzE0IDE2OjA2LCBNYWthcmFqdSwg TWFyaWRpIFJhanUgKFJhanUpIHdyb3RlOgo+PiAgICAgID4+IE9uIDMwLzExLzE0IDE0OjUxLCBN YWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUpIHdyb3RlOgo+PiAgICAgID4+Pj4gSGksCj4+ICAg ICAgPj4+Pgo+PiAgICAgID4+Pj4+PiBSRkMgNzM0NSAoVURQVEwtRFRMUykgc2F5cyB0aGUgZm9s bG93aW5nOgo+PiAgICAgID4+Pj4+Pgo+PiAgICAgID4+Pj4+PiAiT25jZSBhbiBvZmZlci9hbnN3 ZXIgZXhjaGFuZ2UgaGFzIGJlZW4gY29tcGxldGVkLCBlaXRoZXIKPj4gICAgICA+Pj4+Pj4gZW5k cG9pbnQKPj4gICAgICA+Pj4+IE1BWQo+PiAgICAgID4+Pj4+PiBzZW5kIGEgbmV3IG9mZmVyIGlu IG9yZGVyIHRvIG1vZGlmeSB0aGUgc2Vzc2lvbi4gIFRoZQo+PiAgICAgID4+Pj4+PiBlbmRwb2lu dHMKPj4gICAgICA+Pj4+IGNhbgo+PiAgICAgID4+Pj4+PiByZXVzZSB0aGUgZXhpc3RpbmcgRFRM UyBhc3NvY2lhdGlvbiBpZiB0aGUga2V5IGZpbmdlcnByaW50Cj4+ICAgICAgPj4+Pj4+IHZhbHVl cwo+PiAgICAgID4+Pj4gYW5kCj4+ICAgICAgPj4+Pj4+IHRyYW5zcG9ydCBwYXJhbWV0ZXJzIGlu ZGljYXRlZCBieSBlYWNoIGVuZHBvaW50IGFyZSB1bmNoYW5nZWQuCj4+ICAgICAgPj4+Pj4+IE90 aGVyd2lzZSwgZm9sbG93aW5nIHRoZSBydWxlcyBmb3IgdGhlIGluaXRpYWwgb2ZmZXIvYW5zd2Vy Cj4+ICAgICAgPj4+PiBleGNoYW5nZSwKPj4gICAgICA+Pj4+Pj4gdGhlIGVuZHBvaW50cyBjYW4g bmVnb3RpYXRlIGFuZCBjcmVhdGUgYSBuZXcgRFRMUyBhc3NvY2lhdGlvbgo+PiAgICAgID4+Pj4+ PiBhbmQsIG9uY2UgY3JlYXRlZCwgZGVsZXRlIHRoZSBwcmV2aW91cyBEVExTIGFzc29jaWF0aW9u LAo+PiAgICAgID4+Pj4+PiBmb2xsb3dpbmcgdGhlIHNhbWUgcnVsZXMgZm9yIHRoZSBpbml0aWFs IG9mZmVyL2Fuc3dlciBleGNoYW5nZS4KPj4gICAgICA+Pj4+Pj4gRWFjaCBlbmRwb2ludCBuZWVk cyB0byBiZSBwcmVwYXJlZCB0byByZWNlaXZlIGRhdGEgb24gYm90aCB0aGUKPj4gICAgICA+Pj4+ Pj4gbmV3IGFuZCBvbGQgRFRMUyBhc3NvY2lhdGlvbnMgYXMgbG9uZyBhcyBib3RoIGFyZSBhbGl2 ZS4iCj4+ICAgICAgPj4+Pj4+Cj4+ICAgICAgPj4+Pj4+IFNvLCBJIGd1ZXNzIHRoYXQgY2FuIGJl IHJlYWQgaW4gYSB3YXkgdGhhdCB0aGUgc2V0dXAgYXR0cmlidXRlCj4+ICAgICAgPj4+Pj4+IGFz IHN1Y2gKPj4gICAgICA+Pj4+IGRvZXMgbm90IGltcGFjdCBwcmV2aW91c2x5Cj4+ICAgICAgPj4+ Pj4+IG5lZ290aWF0ZWQgVExTIHJvbGVzIC0gdW5sZXNzIHRoZSBrZXkgZmluZ2VycHJpbnQgdmFs dWVzIGFuZC9vcgo+PiAgICAgID4+Pj4+PiB0cmFuc3BvcnQKPj4gICAgICA+Pj4+IHBhcmFtZXRl cnMgYXJlIG1vZGlmaWVkLgo+PiAgICAgID4+Pj4+Pgo+PiAgICAgID4+Pj4+PiBUaGUgU0NUUC1T RFAgZHJhZnQgY3VycmVudGx5IHNheXMgdGhhdCBhIHN1YnNlcXVlbnQgb2ZmZXIgbXVzdAo+PiAg ICAgID4+Pj4+PiBub3QgY2hhbmdlCj4+ICAgICAgPj4+PiB0aGUgcHJldmlvdXNseSBuZWdvdGlh dGVkIHJvbGVzLiBCdXQsIEkgZ3Vlc3MKPj4gICAgICA+Pj4+Pj4gd2UgY291bGQgc2F5IHNvbWV0 aGluZyBzaW1pbGFyIGFzIGluIFJGQyA3MzQ1Lgo+PiAgICAgID4+Pj4+Cj4+ICAgICAgPj4+Pj4g SSBoYXZlIHN0cnVnZ2xlZCB3aXRoIHRoaXMgbGFuZ3VhZ2UgcXVpdGUgYSBiaXQgZnJvbSB0aGUK Pj4gICAgICA+Pj4+PiBpbXBsZW1lbnRhdGlvbgo+PiAgICAgID4+Pj4gcGVyc3BlY3RpdmUuIEkg dGhpbmsgd2UgbmVlZCB0byBleHBsaWNpdGx5IHN0YXRlCj4+ICAgICAgPj4+Pj4gdGhhdCBlbmRw b2ludHMgTVVTVCByZXVzZSB0aGUgZXhpc3RpbmcgYXNzb2NpYXRpb24gaWYgdGhlIGtleQo+PiAg ICAgID4+Pj4+IGZpbmdlcnByaW50Cj4+ICAgICAgPj4+PiB2YWx1ZXMgYW5kIHRyYW5zcG9ydCBw YXJhbWV0ZXJzIGluZGljYXRlZAo+PiAgICAgID4+Pj4+IGJ5IGVhY2ggZW5kcG9pbnQgYXJlIHVu Y2hhbmdlZC4KPj4gICAgICA+Pj4+Cj4+ICAgICAgPj4+PiBXZSBjb3VsZCB0YWtlIHN1Y2ggZ2Vu ZXJhbCBhcHByb2FjaC4KPj4gICAgICA+Pj4+Cj4+ICAgICAgPj4+PiBIb3dldmVyLCBmb3IgJ1ND VFAvRFRMUycgKERUTFMgb3ZlciBTQ1RQKSwgSSBhc3N1bWUgdGhhdCB0aGUgRFRMUwo+PiAgICAg ID4+Pj4gY29ubmVjdGlvbiB3aWxsIGFsc28gYmUgcmUtZXN0YWJsaXNoZWQgaWYgdGhlIHVuZGVy bHlpbmcgU0NUUAo+PiAgICAgID4+Pj4gYXNzb2NpYXRpb24gaXMgcmUtIGVzdGFibGlzaGVkIC0g ZXZlbiBpZiBubyB0cmFuc3BvcnQgcGFyYW1ldGVycwo+PiAgICAgID4+Pj4gZXRjIGFyZSBjaGFu Z2VkLgo+PiAgICAgID4+Pj4KPj4gICAgICA+Pj4+IEFsc28sIFJGQyA2MDgzIHNheXM6Cj4+ICAg ICAgPj4+Pgo+PiAgICAgID4+Pj4gIkVhY2ggRFRMUyBjb25uZWN0aW9uIE1VU1QgYmUgZXN0YWJs aXNoZWQgYW5kIHRlcm1pbmF0ZWQKPj4gICAgIHdpdGhpbiB0aGUKPj4gICAgICA+Pj4+IHNhbWUg U0NUUCBhc3NvY2lhdGlvbi4iCj4+ICAgICAgPj4+Pgo+PiAgICAgID4+Pj4KPj4gICAgICA+Pj4+ PiBUaGUgd2F5IHRoaXMgbGFuZ3VhZ2UgcmVhZHMgdG8gbWUgaXMgdGhhdCBlbmRwb2ludHMgY2Fu IHJldXNlIHRoZQo+PiAgICAgID4+Pj4+IGV4aXN0aW5nCj4+ICAgICAgPj4+PiBhc3NvY2lhdGlv biBpZiB0aGV5IHdhbnQgdG8sIGJ1dCB0aGV5IGNhbiBjcmVhdGUgYSBuZXcgb25lIGlmIHRoZXkK Pj4gICAgICA+Pj4+IGRvbid0LiBBbHNvLCB3aGVuIHRoaXMgbmV3Cj4+ICAgICAgPj4+Pj4gYXNz b2NpYXRpb24gaXMgY3JlYXRlZCwgaXQgaXMgdW5jbGVhciBpZiBvbGQgc2V0dXAgcm9sZXMgTVVT VCBiZQo+PiAgICAgID4+Pj4+IHByZXNlcnZlZAo+PiAgICAgID4+Pj4gb3IgaWYgdGhleSBNVVNU IGJlIHNlbGVjdGVkIGJhc2VkIG9uIHRoZSBjdXJyZW50IG9mZmVyL2Fuc3dlcgo+PiAgICAgID4+ Pj4gZXhjaGFuZ2UuIEl0IHNlZW1zIHRoZSBjdXJyZW50Cj4+ICAgICAgPj4+Pj4gc3BlY2lmaWNh dGlvbiBsYW5ndWFnZSBpcyBub3Qgc3Ryb25nIG9yIGNsZWFyIGVub3VnaCBvbiB0aGlzCj4+ICAg ICAgPj4+Pj4gdG9waWMuCj4+ICAgICAgPj4+Pgo+PiAgICAgID4+Pj4gSW4gbXkgb3Bpbmlvbiwg SUYgYSBuZXcgRFRMUyBjb25uZWN0aW9uIG5lZWRzIHRvIGJlIGVzdGFibGlzaGVkCj4+ICAgICAg Pj4+PiAoZm9yIHdoYXRldmVyIHJlYXNvbnMpLCB0aGUgY3VycmVudCByb2xlcyBzaG91bGQgYmUg dXNlZC4KPj4gICAgICA+Pj4KPj4gICAgICA+Pj4gPFJhanU+IFdoZW4gSUNFIGlzIE5PVCB1c2Vk LCBob3cgZG9lcyB0aGUgb2ZmZXJlciBrbm93IHRoYXQgdGhlCj4+ICAgICAgPj4+IGFuc3dlcmVy IGRvZXMgbm90IGNoYW5nZSB0aGUgZmluZ2VycHJpbnQgYW5kL29yIHRyYW5zcG9ydAo+PiAgICAg cGFyYW1ldGVycz8KPj4gICAgICA+Pj4gSSBndWVzcyBpdCBkb2VzIG5vdCBrbm93LiBTbywgb2Zm ZXJlciBoYXMgdG8gYmUgcHJlcGFyZWQgZm9yCj4+ICAgICBuZXcgRFRMUwo+PiAgICAgID4+PiBh c3NvY2lhdGlvbiBieSBvZmZlcmluZyBhY3RwYXNzLiBXaGVuIElDRSBpcyB1c2VkLCB0aGUgYW5z d2VyZXIKPj4gICAgIGNhbid0Cj4+ICAgICAgPj4+IGNoYW5nZSB0cmFuc3BvcnQgcGFyYW1ldGVy IHVubGVzcyBvZmZlcmVyIGRvZXMgSUNFIHJlc3RhcnQgKHdoaWNoCj4+ICAgICAgPj4+IGNoYW5n ZXMgb2ZmZXJlciB0cmFuc3BvcnQgcGFyYW1ldGVycyk7IFJlZiBbMV0gaXMgdmVyeSBjbGVhciBv bgo+PiAgICAgdGhpcwo+PiAgICAgID4+PiBpbmRpY2F0aW5nICJEVExTIGhhbmRzaGFrZSBwcm9j ZWR1cmUgaXMgcmVwZWF0ZWQiLiBIb3dldmVyLAo+PiAgICAgZXZlbiB3aGVuCj4+ICAgICAgPj4+ IElDRSBpcyB1c2VkLCBJIGRvIG5vdCBmaW5kIGFueSByZXN0cmljdGlvbiBhYm91dCBhbnN3ZXJl ciBub3QKPj4gICAgICA+Pj4gY2hhbmdpbmcgZmluZ2VycHJpbnQuIFNvLCBldmVuIHdpdGhvdXQg SUNFIHJlc3RhcnQgYW5zd2VyZXIgY2FuCj4+ICAgICAgPj4+IHRyaWdnZXIgYSBEVExTIHJlbmVn b3RpYXRpb24gYnkgY2hhbmdpbmcgaXRzIGZpbmdlcnByaW50Lgo+PiAgICAgID4+Pgo+PiAgICAg ID4+PiBUbyBjb25jbHVkZSBhbGwgdGhpcywgSU1PIHdoZXRoZXIgSUNFIGlzIHVzZWQgb3Igbm90 LCBzZW5kaW5nCj4+ICAgICBhY3RwYXNzCj4+ICAgICAgPj4+IGZvciBhbGwgbmV3IG9mZmVycyBt YXkgYmUgY292ZXIgYWxsIHBvc3NpYmxlIHNjZW5hcmlvcy4KPj4gICAgICA+Pgo+PiAgICAgID4+ IFRoYXQgaXMgYWxzbyBteSBjb25jbHVzaW9uIGJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uIHNvIGZh ci4KPj4gICAgICA+Pgo+PiAgICAgID4+IEkgYWxzbyB0aGluayB0aGUgSlNFUCBkcmFmdCBhcyBm YXIgYXMgZGV0YWlsZWQgb3V0IGlzIGNvcnJlY3QsCj4+ICAgICBidXQgaW5mbwo+PiAgICAgID4+ IGFib3V0IGhvdyB0aGUgaW1wbGVtZW50YXRpb24gc2hvdWxkIGJlaGF2ZSBmb3IgU3Vic2VxdWVu dCBhbnN3ZXJzIGlzCj4+ICAgICAgPj4gbWlzc2luZy4gVGV4dCBzYXlpbmcgdGhhdCB0aGUgcm9s ZSBtdXN0IGJlIG1haW50YWluZWQgKHVubGVzcwo+PiAgICAgdGhlcmUgaXMKPj4gICAgICA+PiBh biBJQ0UgcmVzdGFydCkgc2hvdWxkIGJlIHB1dCBpbiB0aGVyZS4KPj4gICAgICA+Cj4+ICAgICAg PiA8UmFqdT4KPj4gICAgICA+IEhpIFN0ZWZhbiwKPj4gICAgICA+IExvb2tzIGxpa2UsIHRoZXJl IGlzIHNvbWUgbWlzdW5kZXJzdGFuZGluZyBoZXJlLgo+Pgo+PiAgICAgUHJvYmFibHkgbXkgZmF1 bHQgaW4gdGhhdCBjYXNlIDopCj4+Cj4+ICAgICA+IE15IGNvbmNsdXNpb24gaXMgdG8gaW5jbHVk ZQo+PiAgICAgPiBhY3RwYXNzLCBidXQgbm90IHRoZSBwcmV2aW91c2x5IG5lZ290aWF0ZWQgcm9s ZSwgaW4gYWxsIHN1YnNlcXVlbnQgb2ZmZXJzLAo+PiAgICAgPiBub3QganVzdCBkdXJpbmcgSUNF LXJlc3RhcnRzLgo+Pgo+PiAgICAgSSB0aGluayB0aGF0IGlzIHdoYXQgdGhlIEpTRVAgZHJhZnQg c2F5cyAtIGFuZCBteSBjb25jbHVzaW9uIGlzIHRoYXQgaXQKPj4gICAgIF9pc18gY29ycmVjdC4K Pj4KPj4gICAgIE15IHBvaW50IHdhcyB0aGF0IHRoZSBfYW5zd2VyXyBzaG91bGQgKHdoZW4gaXQg aXMgYSBzdWJzZXF1ZW50IGFuc3dlcikKPj4gICAgIHNob3VsZCBzYXkgdGhlIHNhbWUgcm9sZSBh cyBpbiBwcmV2aW91cyBhbnN3ZXJzICh1bmxlc3MgdGhlcmUgaXMgYW4gSUNFCj4+ICAgICByZXN0 YXJ0KS4KPj4KPj4gSSBhZ3JlZSB0aGUgSlNFUCB0ZXh0IHNob3VsZCBpbmRpY2F0ZSB0aGF0IHJv bGVzIHNob3VsZCBzdGF5IHRoZSBzYW1lLgo+PiBXZSBoYXZlIGhhZCB0aGlzIGFzIGEgVE9ETyBm b3IgYSB3aGlsZToKPj5odHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAvaXNzdWVzLzcy Cj4KPiBHcmVhdC4gSSBzaG91bGQgaGF2ZSBjaGVja2VkIHRoYXQgb3V0IGJlZm9yZS4KPgoK From nobody Thu Dec 4 06:08:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F9A1A1ADF for ; Thu, 4 Dec 2014 06:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFMS3rku8z5m for ; Thu, 4 Dec 2014 06:08:06 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D92B1AD384 for ; Thu, 4 Dec 2014 06:08:06 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-51-54806ac480e6 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 46.29.24955.4CA60845; Thu, 4 Dec 2014 15:08:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 15:08:04 +0100 From: Christer Holmberg To: =?utf-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= , Justin Uberti Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAHzoxGA Date: Thu, 4 Dec 2014 14:08:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D578E30@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE2BC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577322@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577B77@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577CB5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D578C4D@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE9AC@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0EE9AC@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+Jvje6RrIYQg0+35Sy2ThWyWPuvnd2B yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlvLj/na3gGm/F1U/r2BoYV/B2MXJySAiYSGxY 0skCYYtJXLi3ng3EFhI4wigx+XlyFyMXkL2YUaJtzifWLkYODjYBC4nuf9ogNSICpRIHFoGE OTmYBdQl7iw+xw5iCwuYSryfe4QZosZMYuHJCYwQtpHE19VLweazCKhIbJ67HKyeV8BX4tnH GSwQu7bzSszrvMMEkuAU8JPYf/wOWBEj0HHfT61hglgmLnHryXwmiKMFJJbsOc8MYYtKvHz8 D+xOCQEliWlb00BMZgFNifW79CE6FSWmdD+EWisocXLmE5YJjGKzkAydhdAxC0nHLCQdCxhZ VjGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIERs3BLb9VdzBefuN4iFGAg1GJh9fgXH2IEGti WXFl7iFGaQ4WJXHehefmBQsJpCeWpGanphakFsUXleakFh9iZOLglGpgZFz2Kd2J5VOn9Pb6 ia/5BZwLr/xaN09pw4947k33nlhduf9oH1PRp8U6UpfOXj/KunzPwzpXJhv5z2Z3luxpmuC2 tNPar0Kzd3XUBZHZsqqKHuntFS+eWvapNbAaPud7WJrsf5/f7XWz31H9+2fq4gwtvaTsuKUt XVYvcfnJdrZsecLNLJHfSizFGYmGWsxFxYkAljaGIXsCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/J0y8LIwtEzZHly5Tf761-mvEgw4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 14:08:24 -0000 SGksDQoNCj4+IFdoYXQgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0Og0KPj4NCj4+IDguMy4yLiAg VExTIFJvbGUgRGV0ZXJtaW5hdGlvbg0KPj4NCj4+ICAgICBJZiB0aGUgbS0gbGluZSBwcm90byBm aWVsZCB2YWx1ZSBpcyAnU0NUUC9EVExTJyBvciAnRFRMUy9TQ1RQJywgDQo+PiAgICAgdGhlIFNE UCBzZXR1cCBhdHRyaWJ1dGUgW1JGQzQxNDVdIGlzIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSAnYWN0 aXZlLw0KPj4gICAgIHBhc3NpdmUnIHN0YXR1cyBvZiB0aGUgb2ZmZXJlciBhbmQgYW5zd2VyZXIu ICBUaGUgJ2FjdGl2ZS9wYXNzaXZlJw0KPj4gICAgIHN0YXR1cyB3aWxsIGJlIHVzZWQgdG8gZGV0 ZXJtaW5lIHRoZSBUTFMgcm9sZXMsIGZvbGxvd2luZyB0aGUNCj4+ICAgICBwcm9jZWR1cmVzIGlu IFtSRkM0NTcyXSAodGhlICdhY3RpdmUnIGVuZHBvaW50IHdpbGwgdGFrZSB0aGUgVExTIA0KPj4g ICAgIGNsaWVudCByb2xlKS4NCj4+DQo+PiAgICAgT25jZSBhIERUTFMgY29ubmVjdGlvbiBoYXMg YmVlbiBlc3RhYmxpc2hlZCwgaWYgdGhlICdhY3RpdmUvcGFzc2l2ZScNCj4+ICAgICBzdGF0dXMg b2YgdGhlIGVuZHBvaW50cyBjaGFuZ2UgZHVyaW5nIGEgc2Vzc2lvbiwgYSBuZXcgRFRMUw0KPj4g ICAgIGNvbm5lY3Rpb24gTVVTVCBiZSBlc3RhYmxpc2hlZC4gIFRoZXJlZm9yZSwgZW5kcG9pbnRz IFNIT1VMRCBOT1QNCj4+ICAgICBjaGFuZ2UgdGhlIOKAmGFjdGl2ZS9wYXNzaXZl4oCZIHN0YXR1 cyBpbiBzdWJzZXF1ZW50IG9mZmVycyBhbmQgYW5zd2VycywNCj4NCj4gRGlkIG5vdCB0aGUgZGlz Y3Vzc2lvbiAoZm9yIHJ0Y3dlYikgY29uY2x1ZGUgdGhhdCBzdWJzZXF1ZW50IG9mZmVycyBzaG91 bGQgb2ZmZXIgYWN0cGFzcywgYnV0IHRoYXQgc3Vic2VxdWVudCBhbnN3ZXJzIG11c3Qgc2F5IHRo ZSBzYW1lIGFzIHRoZSBwcmV2aW91cyBhbnN3ZXI/DQoNCkluIHRoZSBPZmZlci9BbnN3ZXIgc2Vj dGlvbiwgSSBjYW4gZGVmaW5lIG1vcmUgZGV0YWlscyByZWdhcmRpbmcgdGhlIHZhbHVlcyAoYWN0 cGFzcyBldGMpIHRvIHVzZS4NCg0KQlVULCB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSB3YW50 IHRvIGFsbG93IHRoZSBlbmRwb2ludHMgdG8gdHJpZ2dlciBhIG5ldyBEVExTIGNvbm5lY3Rpb24g YnkgY2hhbmdpbmcgdGhlIGFjdGl2ZS9wYXNzaXZlIHN0YXR1cyBvciBub3QuIFRoZSB0ZXh0IGFi b3ZlIHNheXMgU0hPVUxEIE5PVCBjaGFuZ2UgdGhlIGFjdGl2ZS9wYXNzaXZlIHN0YXR1cy4NCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Thu Dec 4 06:43:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435D21AD3B3 for ; Thu, 4 Dec 2014 06:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alAG9_fAbrqh for ; Thu, 4 Dec 2014 06:43:02 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824F61AD3AD for ; Thu, 4 Dec 2014 06:43:01 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-be-548072f3335a Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 46.CA.04076.3F270845; Thu, 4 Dec 2014 15:42:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 15:42:59 +0100 From: =?Windows-1252?Q?Stefan_H=E5kansson_LK?= To: Christer Holmberg , Justin Uberti Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JA== Date: Thu, 4 Dec 2014 14:42:58 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D0EEA4E@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE2BC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577322@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577B77@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577CB5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D578C4D@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE9AC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D578E30@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje7nooYQg/cnFS22ThWyWPuvnd2B yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlnN17jKXgHHvF6bctTA2Mi9i6GDk5JARMJM5O 7mSEsMUkLtxbDxTn4hASOMIo8frqNHYIZzGjxMcly4CqODjYBIIlmv66gTSICMRI/Oq7A9bM LKAucWfxOXYQW1jAVGLSxWVMEDVmEgtPTmCEsPUkbn65wAJiswioSBy72Axm8wr4Suz7f5AJ YtdvXonOL7+YQRKMQBd9P7WGCWKBuMStJ/OZIC4VkFiy5zwzhC0q8fLxP1aQ2yQEFCWW98tB lBtIvD83nxnC1pZYtvA1M8QuQYmTM5+wTGAUnYVk6iwkLbOQtMxC0rKAkWUVo2hxanFxbrqR kV5qUWZycXF+nl5easkmRmCMHNzy22oH48HnjocYBTgYlXh4Dc7VhwixJpYVV+YeYpTmYFES 5114bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsZ1Qmd5Sz/nGolc31T2qLSmaT1LvUmM 9CqZBd4a3Tl/pBZ5mmwov91SvpLxQiuf7hXlwr+z+1bvbmeW2F63Wtj2/o0b7f/OTntlH6P6 VuXXRIMLiWFeKj/Edyk+9U22OvfwxWrpAzHXr8yw+tyj5xESMTvjzBrRqSzfPvcfzJ34/3Td 3Alxf8SUWIozEg21mIuKEwE4czsWcgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/yu-HrP3n4c92rfgOLsfYuDtUOo0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 14:43:04 -0000 On 04/12/14 15:08, Christer Holmberg wrote:=0A= > Hi,=0A= =0A= >>> Once a DTLS connection has been established, if the=0A= >>> 'active/passive' status of the endpoints change during a session,=0A= >>> a new DTLS connection MUST be established. Therefore, endpoints=0A= >>> SHOULD NOT change the =91active/passive=92 status in subsequent=0A= >>> offers and answers,=0A= >>=0A= >> Did not the discussion (for rtcweb) conclude that subsequent offers=0A= >> should offer actpass, but that subsequent answers must say the same=0A= >> as the previous answer?=0A= >=0A= > In the Offer/Answer section, I can define more details regarding the=0A= > values (actpass etc) to use.=0A= >=0A= > BUT, the question is whether we want to allow the endpoints to=0A= > trigger a new DTLS connection by changing the active/passive status=0A= > or not. The text above says SHOULD NOT change the active/passive=0A= > status.=0A= =0A= OK, makes sense to me.=0A= =0A= =0A= From nobody Thu Dec 4 06:51:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391541AD3BB for ; Thu, 4 Dec 2014 06:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGxscxLjwhEJ for ; Thu, 4 Dec 2014 06:51:53 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id A00C41A1B10 for ; Thu, 4 Dec 2014 06:51:52 -0800 (PST) Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail07.adl2.internode.on.net with ESMTP; 05 Dec 2014 01:21:51 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 27644FFEE9 for ; Fri, 5 Dec 2014 01:21:39 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YICSjDMqFLVg for ; Fri, 5 Dec 2014 01:21:38 +1030 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id B9943FF88C for ; Fri, 5 Dec 2014 01:21:38 +1030 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id AE47780470; Fri, 5 Dec 2014 01:21:38 +1030 (ACDT) Date: Fri, 5 Dec 2014 01:21:38 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141204145138.GH10449@hex.shelbyville.oz> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/z6aHw3s1nEC2fCuZ0c6l1BV7m9s Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 14:51:55 -0000 On Wed, Dec 03, 2014 at 10:33:04AM -0800, David Singer wrote: > > Consider finally: a small company for whom WebRTC is important. > > Let’s look at the choices: > > 1. Follow the mandate, implement VP8, and risk a ruinous lawsuit from Nokia. > > 2. Reject the mandate, do not implement VP8, and be formally therefore not conformant and therefore not in receipt of a license from company X; risk a ruinous lawsuit from X. > > 3. Do not implement WebRTC, and risk a ruinous loss of relevance. This seems more like a hypothetical small strawman than a situation that any *real* small company has expressed to this group. Your concern for small operators is heartwarming, but I think if you consult the list archives to see what such people have actually said for themselves, the only ruinous legal barrier that Nokia appears to have them worried about is the IPR it holds on H.264 that is outside the pool MPEG-LA operates, with no clear guarantee of its terms. And we *still* don't have an IPR statement from them about this. How many times should we need to ask them to respect the IETF process? Fear of VP8 here would appear to be directly proportional to something much simpler than what you claim. If someone would like to graph "Number of H.264 patents held" vs "Fear of VP8 being MTI", I think you'll find the real correlation that you're grasping for here to be fairly obvious. hth! Ron From nobody Thu Dec 4 07:01:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82021AD404 for ; Thu, 4 Dec 2014 07:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovFUs0UH5yrC for ; Thu, 4 Dec 2014 07:00:56 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id 4941B1AD40E for ; Thu, 4 Dec 2014 07:00:55 -0800 (PST) Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail07.adl2.internode.on.net with ESMTP; 05 Dec 2014 01:30:54 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 16968FFE27 for ; Fri, 5 Dec 2014 01:30:42 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hq1dVGAkaICr for ; Fri, 5 Dec 2014 01:30:41 +1030 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 4FFE0FF88C for ; Fri, 5 Dec 2014 01:30:41 +1030 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 35DCE80470; Fri, 5 Dec 2014 01:30:41 +1030 (ACDT) Date: Fri, 5 Dec 2014 01:30:41 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141204150041.GI10449@hex.shelbyville.oz> References: <547511DB.5050100@nostrum.com> <547FC4FD.2050300@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <547FC4FD.2050300@andyet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hk9rX9dVf7m7xqVuVeI9FrjWEc8 Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 15:01:02 -0000 Hi Peter, On Wed, Dec 03, 2014 at 07:20:45PM -0700, Peter Saint-Andre - &yet wrote: > On 11/25/14, 4:33 PM, Adam Roach wrote: > >I've updated the draft-ietf-rtcweb-video based on the minutes from > >Hawaii. Now that we have a clear path to success, I'd like to get the > >document finalized and published as quickly as possible. This means I > >need your feedback on the remaining open issues (1, 4, and 5, below). If > >you are CCed on this mail, it's because you took an action item in > >Hawaii, and I'm waiting to hear back from you. > > > >New version: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ > >Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-video-03.txt > > I have concerns about the future-oriented text: > > To promote the use of non-royalty bearing video codecs, > participants in the RTCWEB working group, and any successor > working groups in the IETF, intend to monitor the evolving > licensing landscape as it pertains to the two mandatory-to- > implement codecs. If compelling evidence arises that one of the > codecs is available for use on a royalty-free basis, the working > group plans to revisit the question of which codecs are required > for Non-Browsers, with the intention being that the royalty-free > codec will remain mandatory to implement, and the other will > become optional. > > The if-clause in the last sentence establishes a trigger for revisiting the > combination of VP8 and H.264 as MTI video codecs. But is that the only > possible trigger? If so, I think the document is misguided. > > The ideal solution to the video codec problem would be for the IETF > community to create a truly unencumbered video codec, as it has already done > for audio with the Opus codec. If the IETF (or some other standards > development organization) were to develop such a codec, then I think that > would be a sufficient trigger for revisiting the recommendations in this > document, no matter what happens with the royalty-free status of VP8 and > H.264. > > I would strongly prefer that the document contain text recognizing that > possibility. > > Furthermore, this text about WebRTC Browsers sends the wrong message, I > think: > > These provisions apply to WebRTC Non-Browsers only. There is no > plan to revisit the codecs required for WebRTC Browsers. > > Certainly there is no active plan at this time to revisit the MTI codec > issue (after all, we're still *visiting* the issue for the first time), but > that's immaterial to the question of when it might be appropriate to do so. > The current text reads as if there are no conditions under which the MTI > codec issue would ever be revisited, and that's just wrong. > > (A smaller but not insignificant issue is that the document talks about "the > RTCWEB working group", "any successor working groups in the IETF", and "the > working group" interchangeably. Yet can this document establish plans for > successor working groups, or even future incarnations of the RTCWEB working > group? Any plans related to future efforts will be set by WG consensus or > IETF consensus, not for all time by this document.) > > IMHO we need to either pull out the future-oriented text entirely (which has > its own problems) or significantly improve it. I would be happy to propose > text for the latter. I'd definitely be interested in seeing proposals from you to improve upon these things. It seemed premature to explore this until we had some sense of whether this kind of compromise could fly at all, but now that it seems it can, I think these are important details for us to clarify as best we can. Thanks! Ron From nobody Thu Dec 4 07:15:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A81C1AD40D for ; Thu, 4 Dec 2014 07:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEt9oHwRiutX for ; Thu, 4 Dec 2014 07:15:38 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D551AD40E for ; Thu, 4 Dec 2014 07:15:32 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 24D5787EEEC94; Thu, 4 Dec 2014 15:15:28 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id sB4FFKhc022933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 10:15:28 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 10:15:23 -0500 From: "Makaraju, Maridi Raju (Raju)" To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= , Christer Holmberg , Justin Uberti Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAH1cz+A Date: Thu, 4 Dec 2014 15:15:23 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE2BC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577322@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577B77@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577CB5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D578C4D@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE9AC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D578E30@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EEA4E@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0EEA4E@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rehYSCEAGYbVJB303rMx6gppBVs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 15:15:42 -0000 > >>> Once a DTLS connection has been established, if the > >>> 'active/passive' status of the endpoints change during a session, > >>> a new DTLS connection MUST be established. Therefore, endpoints > >>> SHOULD NOT change the 'active/passive' status in subsequent > >>> offers and answers, > >> > >> Did not the discussion (for rtcweb) conclude that subsequent offers > >> should offer actpass, but that subsequent answers must say the same > >> as the previous answer? > > > > In the Offer/Answer section, I can define more details regarding the > > values (actpass etc) to use. > > > > BUT, the question is whether we want to allow the endpoints to > > trigger a new DTLS connection by changing the active/passive status > > or not. The text above says SHOULD NOT change the active/passive > > status. >=20 > OK, makes sense to me. I am ok with it as well. The strength "SHOULD NOT" seems intentional and I think that is right; so i= t is still allowed but not recommended. May be obvious, but please be sure to mention that, independent of last off= er/answer direction, new offerer SHOULD include actpass and answerer SHOULD= answer with previously negotiated role. BR Raju From nobody Thu Dec 4 07:43:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21821AD3FF for ; Thu, 4 Dec 2014 07:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D06bnhLeHn2X for ; Thu, 4 Dec 2014 07:43:39 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 092841AD460 for ; Thu, 4 Dec 2014 07:43:38 -0800 (PST) Received: from smtp-pop.rim.net (HELO XCT103CNC.rim.net) ([10.65.161.203]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 04 Dec 2014 10:43:29 -0500 Received: from XCT115CNC.rim.net (10.65.161.215) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.3.210.2; Thu, 4 Dec 2014 10:43:29 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT115CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Thu, 4 Dec 2014 10:43:28 -0500 From: Andrew Allen To: Silvia Pfeiffer Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) Thread-Index: AQHQDyew2za5sQikUES+QP80tOoCX5x+9/iA//+wzeqAAI+4gIAAW0zh Date: Thu, 4 Dec 2014 15:43:28 +0000 Message-ID: <20141204154326.5955730.32803.3228@blackberry.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com>, In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_201412041543265955730328033228blackberrycom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Yuc-x6OCrQIi4HVoe07yyn-RDHw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 15:43:44 -0000 --_000_201412041543265955730328033228blackberrycom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Silvia I think the risk for small companies is if they suddenly have a successful = product and have revenue that they then become a target. Plenty of cash flo= w to go after without the experience and resources to fight off the lawsuit= . My point was the fact that small companies may have implemented VP8 without= yet becoming engaged in a lawsuit does not prove that VP8 is RF. Andrew Sent from my BlackBerry 10 smartphone. From: Silvia Pfeiffer Sent: Wednesday, December 3, 2014 23:17 To: Andrew Allen Cc: David Singer; rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, st= ill, sorry) Indeed, that's why I said point 1. in David's list doesn't make sense, sinc= e he's talking about a small company getting sued by Nokia. S. On Thu, Dec 4, 2014 at 12:42 PM, Andrew Allen > wrote: Silvia It is not usually the small companies that get sued in patent cases. Its c= ompanies with assets and significant revenues that get the lawsuits. Nobody sues the penniless! - thats like suing the homeless! Andrew Sent from my BlackBerry 10 smartphone. From: Silvia Pfeiffer Sent: Wednesday, December 3, 2014 19:28 To: David Singer Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, st= ill, sorry) On Thu, Dec 4, 2014 at 5:33 AM, David Singer > wrote: > As I understand it, the recent face to face meeting decided to draft the = requirement that WebRTC browsers be required to implement both VP8 and H.26= 4, and get feedback on this, on the list. > > This is some feedback. > > > > I=92d like to point out that this could easily place companies in an impo= ssible position. > > Consider: it is not uncommon for IPR owners to grant a license (often fre= e) only to =91conforming implementations=92. (A common rationale is that th= ey want to use their IPR to bring convergence and interoperability to the i= ndustry). Let=92s hypothesize that this happens, now or in future, from Co= mpany X, for some IPR in the WebRTC specifications. > > Consider also: we have an =93unwilling to license=94 statement from Nokia= on VP8, on the formal record (and including a long list of patents). > > Consider finally: a small company for whom WebRTC is important. > > > > Let=92s look at the choices: > > 1. Follow the mandate, implement VP8, and risk a ruinous lawsuit from No= kia. > > 2. Reject the mandate, do not implement VP8, and be formally therefore n= ot conformant and therefore not in receipt of a license from company X; ris= k a ruinous lawsuit from X. > > 3. Do not implement WebRTC, and risk a ruinous loss of relevance. I don't see the risk of 1. having changed because of the IETF's statement. Plenty of small companies are already doing 1. and have had to risk getting sued by Nokia at this point in time already. In fact, it's a risk that small companies always have to deal with since there is so much patented technology around that you invariable will step on something. I doubt very much that the IETF's decision has any impact on small business' risk in that space at all. > I do not think that the IETF should be placing anyone into the position o= f having three extremely unpalatable choices. For a small company in the WebRTC space, 3. is a non-choice. 2. Is more of a business decision than an IP decision - which market are you trying to address? Are you trying to be interoperable with (current) browsers - then implement VP8. Are you trying to be interoperable with legacy devices - then implement H.264 (and probably even H.263). If you are trying to argue for a large company, the situation changes. However, as a large company, you tend to have an existing portfolio of patents. You're already playing the game of patents. As long as your hypothetical "IPR owners to grant a license only to =91conforming implementations=92" doesn't happen, you are free to choose 2. and avoid Nokia. As for the threat in your option 2. - I can only see Google with IPR around VP8. Now, Google's IPR statement on WebM codecs, which includes VP8 and VP9 currently states: "Google hereby grants to you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license" http://www.webmproject.org/license/additional/ The word "perpetual" implies (to my non-lawyer eyes) that they can't suddenly change this to mean "only if you are conformant to the standard". So you can't be referring to such a risk associated with VP8 being created by Google. I don't know which other company you would want to be afraid of for your hypothetical threat in 2. Could you clarify? Best Regards, Silvia. > (Yes, I am aware that #2 is =91unlikely=92, but one day someone will deci= de that the =93only to conformant implementations=94 clause needs to be rea= l and enforced, and will do this; our hypothetical small company might pref= er not to be the example case.) > > (I use a small company as the example, because for them the risk is bankr= uptcy, but of course no-one likes to step into the path of trouble even if = they have the resources to weather it.) > > Dave Singer > > singer@mac.com > > David Singer > Manager, Software Standards, Apple Inc. > > _______________________________________________ > 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 --_000_201412041543265955730328033228blackberrycom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Silvia
Sent from my BlackBerry 10 smartphone.
From: Silvia Pfeiffer
Sent: Wednesday, December 3, 2014 23:17
To: Andrew Allen
Cc: David Singer; rtcweb@ietf.org
Subject: Re: [rtcweb] Finishing up the Video Codec document, MT= I (again, still, sorry)

Indeed, that's why I said point 1. in David's list doesn't make sense,= since he's talking about a small company getting sued by Nokia.
S.

On Thu, Dec 4, 2014 at 12:42 PM, Andrew Allen <aallen@black= berry.com> wrote:
Sent from my BlackBerry 10 smartphone.
From: Silvia Pfeiffer
Sent: Wednesday, December 3, 2014 19:28
To: David Singer
Subject: Re: [rtcweb] Finishing up the Video Codec document, MT= I (again, still, sorry)

On Thu, Dec 4, 2014 at 5:33 AM, David Singer <singer@apple.com> wrote:
> As I understand it, the recent face to face meeting decided to draft t= he requirement that WebRTC browsers be required to implement both VP8 and H= .264, and get feedback on this, on the list.
>
> This is some feedback.
>
>
>
> I=92d like to point out that this could easily place companies in an i= mpossible position.
>
> Consider: it is not uncommon for IPR owners to grant a license (often = free) only to =91conforming implementations=92. (A common rationale is that= they want to use their IPR to bring convergence and interoperability to th= e industry).  Let=92s hypothesize that this happens, now or in future, from Company X, for some IPR in the WebRTC spec= ifications.
>
> Consider also: we have an =93unwilling to license=94 statement from No= kia on VP8, on the formal record (and including a long list of patents). >
> Consider finally: a small company for whom WebRTC is important.
>
>
>
> Let=92s look at the choices:
>
> 1.  Follow the mandate, implement VP8, and risk a ruinous lawsuit= from Nokia.
>
> 2.  Reject the mandate, do not implement VP8, and be formally the= refore not conformant and therefore not in receipt of a license from compan= y X; risk a ruinous lawsuit from X.
>
> 3.  Do not implement WebRTC, and risk a ruinous loss of relevance= .


I don't see the risk of 1. having changed because of the IETF's
statement. Plenty of small companies are already doing 1. and have had
to risk getting sued by Nokia at this point in time already. In fact,
it's a risk that small companies always have to deal with since there
is so much patented technology around that you invariable will step on
something. I doubt very much that the IETF's decision has any impact
on small business' risk in that space at all.


> I do not think that the IETF should be placing anyone into the positio= n of having three extremely unpalatable choices.

For a small company in the WebRTC space, 3. is a non-choice. 2. Is
more of a business decision than an IP decision - which market are you
trying to address? Are you trying to be interoperable with (current)
browsers - then implement VP8. Are you trying to be interoperable with
legacy devices - then implement H.264 (and probably even H.263).

If you are trying to argue for a large company, the situation changes.
However, as a large company, you tend to have an existing portfolio of
patents. You're already playing the game of patents. As long as your
hypothetical "IPR owners to grant a license only to =91conforming
implementations=92" doesn't happen, you are free to choose 2. and avoi= d
Nokia.

As for the threat in your option 2. - I can only see Google with IPR
around VP8. Now, Google's IPR statement on WebM codecs, which includes
VP8 and VP9 currently states: "Google hereby grants to you a
perpetual, worldwide, non-exclusive, no-charge, royalty-free,
irrevocable (except as stated in this section) patent license"
http://www.webmproject.org/license/additional/
The word "perpetual" implies (to my non-lawyer eyes) that they ca= n't
suddenly change this to mean "only if you are conformant to the
standard". So you can't be referring to such a risk associated with VP8 being created by Google. I don't know which other company you
would want to be afraid of for your hypothetical threat in 2. Could
you clarify?


Best Regards,
Silvia.


> (Yes, I am aware that #2 is =91unlikely=92, but one day someone will d= ecide that the =93only to conformant implementations=94 clause needs to be = real and enforced, and will do this; our hypothetical small company might p= refer not to be the example case.)
>
> (I use a small company as the example, because for them the risk is ba= nkruptcy, but of course no-one likes to step into the path of trouble even = if they have the resources to weather it.)
>
> Dave Singer
>
> singer@mac.com=
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
> _______________________________________________
> 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

--_000_201412041543265955730328033228blackberrycom_-- From nobody Thu Dec 4 07:43:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F211AD3FF for ; Thu, 4 Dec 2014 07:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ltQTIO4IBoy for ; Thu, 4 Dec 2014 07:43:42 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id AA60B1AD44B for ; Thu, 4 Dec 2014 07:43:39 -0800 (PST) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 04 Dec 2014 10:43:34 -0500 Received: from XCT113CNC.rim.net (10.65.161.213) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.210.2; Thu, 4 Dec 2014 10:43:34 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT113CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Thu, 4 Dec 2014 10:43:33 -0500 From: Andrew Allen To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) Thread-Index: AdAP2Q8o2za5sQikUES+QP80tOoCXw== Date: Thu, 4 Dec 2014 15:43:33 +0000 Message-ID: <20141204154332.5955730.14347.3231@blackberry.com> Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_201412041543325955730143473231blackberrycom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/e8495TFnNj46k6rtL3D7u5As1Vg Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 15:43:46 -0000 --_000_201412041543325955730143473231blackberrycom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A Harald To me you seem to be saying this was a very un IETF like political decision= structured to gather enough votes to pass rather than one based on the usu= al technical merits of each proposal. Andrew Sent from my BlackBerry 10 smartphone. From: Harald Alvestrand Sent: Thursday, December 4, 2014 06:26 To: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, st= ill, sorry) On 12/04/2014 03:10 AM, Gaelle Martin-Cocher wrote: > There was a single hum for the three categories (browser, non-browser, co= mpatible endpoints), right? > > That makes a lot of sense for non-browser entities that are in fact WebRT= C-compatible enpoints (apps, or gateways or else) to push the burden on the= browser vendors as those entities will need to interact with browsers. Hen= ce "hum"... > > I think it would make a lot of sense to have different "hums" or question= s for the two different categories. > That will bring clarity on what the "non-browser" yet WebRTC endpoint is,= versus what the WebRTC-compatible endpoint is (let aside gateways). > It is not clear to me that we would have had the same results for each ca= tegory if there was two (or three) different questions. It is not clear that the questions are independent. In fact, it is pretty clear to me that some participants who were willing to go with this package deal were quite unwilling to commit to all the pieces of the package if they were presented one at a time, and they had to answer the question not knowing how all the other pieces came out. I think this is a textbook case of a "package deal". _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_201412041543325955730143473231blackberrycom_ Content-Type: text/html; charset="us-ascii" Content-ID: <48C895BDCE5C5A48AA7213D6C10B1861@rim.com> Content-Transfer-Encoding: quoted-printable
A
Harald

To me you seem to be saying this was a very un IETF like political decision= structured to gather enough votes to pass rather than one based on the usu= al technical merits of each proposal. 

Andrew

Sent from my BlackBerry 10 smartphone.
From: Harald Alvestrand
Sent: Thursday, December 4, 2014 06:26
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Finishing up the Video Codec document, MT= I (again, still, sorry)

On 12/04/2014 03:10 AM, Gaelle Mart= in-Cocher wrote:
> There was a single hum for the three categories (browser, non-browser,= compatible endpoints), right?
>
> That makes a lot of sense for non-browser entities that are in fact We= bRTC-compatible enpoints (apps, or gateways or else) to push the burden on = the browser vendors as those entities will need to interact with browsers. = Hence "hum"...
>
> I think it would make a lot of sense to have different "hums"= ; or questions for the two different categories.
> That will bring clarity on what the "non-browser" yet WebRTC= endpoint is, versus what the WebRTC-compatible endpoint is (let aside gate= ways).
> It is not clear to me that we would have had the same results for each= category if there was two (or three) different questions.

It is not clear that the questions are independent.

In fact, it is pretty clear to me that some participants who were
willing to go with this package deal were quite unwilling to commit to
all the pieces of the package if they were presented one at a time, and they had to answer the question not knowing how all the other pieces
came out.

I think this is a textbook case of a "package deal".

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--_000_201412041543325955730143473231blackberrycom_-- From nobody Thu Dec 4 07:46:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F6E1AD455 for ; Thu, 4 Dec 2014 07:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_fdjgVDeQ4y for ; Thu, 4 Dec 2014 07:46:29 -0800 (PST) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3031AD475 for ; Thu, 4 Dec 2014 07:45:30 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id rd18so15979614iec.29 for ; Thu, 04 Dec 2014 07:45:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TjlgO5L2szIHEh9y+YikgEAddaYWROfJ1UBeMjcCvr4=; b=c90LpuR4lpHz0NHmU/Dlga0jV0u008G+sqW18hVmnwiMaopKFlRK0xaCwm6kIdWUI1 9clLJdFJhX3T7BUgOag6ny7p1s5uQGq4TXBsnDXP4EYxJ9GO9EZ27h0O1oylWHSSR5lb UckEcW2MvXAghdRU4bb5Vu75X7yncJAS9emDTj3CAInpg9OJiNXqdk5/f9BzhXmkQb7l IBW4FkXphXjYfQAyF7tDY6Z77ESgx5I+/xrEeyvUKZyRwBbp1t78DZm2T+YonAMTbyf2 /1jxs3+qi6BMOJpSdF8qJSiJY25myn84FNf5SkOu0fJiSo3CqTnY7u4pvcSJ4X6dHcsA CN1w== X-Gm-Message-State: ALoCoQnNBE0XypJuidpmR9LdkKf4bL2qsijyUvWX0vWyKLJN68dyql3v+q4hMnhbKydmLiHTbK5U X-Received: by 10.50.50.196 with SMTP id e4mr54535099igo.26.1417707929900; Thu, 04 Dec 2014 07:45:29 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id n36sm2791643ioe.4.2014.12.04.07.45.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 07:45:29 -0800 (PST) Message-ID: <54808198.7030207@andyet.net> Date: Thu, 04 Dec 2014 08:45:28 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ron , rtcweb@ietf.org References: <547511DB.5050100@nostrum.com> <547FC4FD.2050300@andyet.net> <20141204150041.GI10449@hex.shelbyville.oz> In-Reply-To: <20141204150041.GI10449@hex.shelbyville.oz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_nS2uLiPnur6u7JvRY1c0xsIKz0 Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 15:46:32 -0000 On 12/4/14, 8:00 AM, Ron wrote: > > Hi Peter, > > On Wed, Dec 03, 2014 at 07:20:45PM -0700, Peter Saint-Andre - &yet wrote: >> On 11/25/14, 4:33 PM, Adam Roach wrote: >>> I've updated the draft-ietf-rtcweb-video based on the minutes from >>> Hawaii. Now that we have a clear path to success, I'd like to get the >>> document finalized and published as quickly as possible. This means I >>> need your feedback on the remaining open issues (1, 4, and 5, below). If >>> you are CCed on this mail, it's because you took an action item in >>> Hawaii, and I'm waiting to hear back from you. >>> >>> New version: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ >>> Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-video-03.txt >> >> I have concerns about the future-oriented text: >> >> To promote the use of non-royalty bearing video codecs, >> participants in the RTCWEB working group, and any successor >> working groups in the IETF, intend to monitor the evolving >> licensing landscape as it pertains to the two mandatory-to- >> implement codecs. If compelling evidence arises that one of the >> codecs is available for use on a royalty-free basis, the working >> group plans to revisit the question of which codecs are required >> for Non-Browsers, with the intention being that the royalty-free >> codec will remain mandatory to implement, and the other will >> become optional. >> >> The if-clause in the last sentence establishes a trigger for revisiting the >> combination of VP8 and H.264 as MTI video codecs. But is that the only >> possible trigger? If so, I think the document is misguided. >> >> The ideal solution to the video codec problem would be for the IETF >> community to create a truly unencumbered video codec, as it has already done >> for audio with the Opus codec. If the IETF (or some other standards >> development organization) were to develop such a codec, then I think that >> would be a sufficient trigger for revisiting the recommendations in this >> document, no matter what happens with the royalty-free status of VP8 and >> H.264. >> >> I would strongly prefer that the document contain text recognizing that >> possibility. >> >> Furthermore, this text about WebRTC Browsers sends the wrong message, I >> think: >> >> These provisions apply to WebRTC Non-Browsers only. There is no >> plan to revisit the codecs required for WebRTC Browsers. >> >> Certainly there is no active plan at this time to revisit the MTI codec >> issue (after all, we're still *visiting* the issue for the first time), but >> that's immaterial to the question of when it might be appropriate to do so. >> The current text reads as if there are no conditions under which the MTI >> codec issue would ever be revisited, and that's just wrong. >> >> (A smaller but not insignificant issue is that the document talks about "the >> RTCWEB working group", "any successor working groups in the IETF", and "the >> working group" interchangeably. Yet can this document establish plans for >> successor working groups, or even future incarnations of the RTCWEB working >> group? Any plans related to future efforts will be set by WG consensus or >> IETF consensus, not for all time by this document.) >> >> IMHO we need to either pull out the future-oriented text entirely (which has >> its own problems) or significantly improve it. I would be happy to propose >> text for the latter. > > I'd definitely be interested in seeing proposals from you to improve > upon these things. It seemed premature to explore this until we had > some sense of whether this kind of compromise could fly at all, but > now that it seems it can, I think these are important details for us > to clarify as best we can. OK, I'll get to work. :-) Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Dec 4 07:51:37 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF79C1AD44B for ; Thu, 4 Dec 2014 07:51:34 -0800 (PST) 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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlxFznas7_Kc for ; Thu, 4 Dec 2014 07:51:30 -0800 (PST) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A191AD471 for ; Thu, 4 Dec 2014 07:50:23 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id hn15so18922816igb.1 for ; Thu, 04 Dec 2014 07:50:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=LyNeDnGiDPyUUFu52xTo4FfJNX4PZwi4YAVpnofHFdY=; b=aFO+6zrYWlPJDXe5ykztZbvQekGo5a0sLFTVsPnEFslXDyEIkQEe10wAldGYLWQHFW etY32+QFQSQoiKN1Hn4XV6ZJJ27cHw8BYua0g18vneMVFraoBOzjgjRV9zNwgdP+bYBR m087ky3Wv+t3g3nhEUAaKLniif/qWqEyOEloK32TWJ9YZFeCGQWpNpT0zYF82tb+BRJX Q7GLgZYN6Y1XXp6h954ioR4tuJHe3Y1dtMMlyL0+woRUvJDL/TlJV8MZ4xuIe0iUoxAY KqMq+m8UZy5elUxtFOsbuStOYFQ1W319upi+ZYpJ3Q4IM+6UNKyemT2s3IBgAHUzQMIq Exrg== X-Gm-Message-State: ALoCoQk73iu1ZrKXQL8rGZUZYJYdrV1NxO+Q4AOpCNMVA2iRGY3ZRcW/vfnXDvGdACY+lkYCO4gB X-Received: by 10.50.109.136 with SMTP id hs8mr14105099igb.46.1417708223099; Thu, 04 Dec 2014 07:50:23 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id n36sm2798036ioe.4.2014.12.04.07.50.20 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Dec 2014 07:50:22 -0800 (PST) Message-ID: <54808294.80802@bbs.darktech.org> Date: Thu, 04 Dec 2014 10:49:40 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com>, <20141204154326.5955730.32803.3228@blackberry.com> In-Reply-To: <20141204154326.5955730.32803.3228@blackberry.com> Content-Type: multipart/alternative; boundary="------------010200030300090306070300" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7Qz37eZ7K0CvVSA64QDCVqqdT14 Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 15:51:34 -0000 This is a multi-part message in MIME format. --------------010200030300090306070300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Andrew, This discussion is kind of silly. We should be investing as much energy into disproving Nokia's IP claim as they have invested into proving it is valid: none at all. The fact that they haven't provided a shred of evidence after repeated public inquiries will be used against them in a court of law, should it ever come up. Gili On 04/12/2014 10:43 AM, Andrew Allen wrote: > Silvia > > I think the risk for small companies is if they suddenly have a > successful product and have revenue that they then become a target. > Plenty of cash flow to go after without the experience and resources > to fight off the lawsuit. > > My point was the fact that small companies may have implemented VP8 > without yet becoming engaged in a lawsuit does not prove that VP8 is RF. > > Andrew > > Sent from my BlackBerry 10 smartphone. > *From: *Silvia Pfeiffer > *Sent: *Wednesday, December 3, 2014 23:17 > *To: *Andrew Allen > *Cc: *David Singer; rtcweb@ietf.org > *Subject: *Re: [rtcweb] Finishing up the Video Codec document, MTI > (again, still, sorry) > > > Indeed, that's why I said point 1. in David's list doesn't make sense, > since he's talking about a small company getting sued by Nokia. > S. > > On Thu, Dec 4, 2014 at 12:42 PM, Andrew Allen > wrote: > > Silvia > > It is not usually the small companies that get sued in patent > cases. Its companies with assets and significant revenues that get > the lawsuits. > > Nobody sues the penniless! - thats like suing the homeless! > > Andrew > > Sent from my BlackBerry 10 smartphone. > *From: *Silvia Pfeiffer > *Sent: *Wednesday, December 3, 2014 19:28 > *To: *David Singer > *Cc: *rtcweb@ietf.org > *Subject: *Re: [rtcweb] Finishing up the Video Codec document, MTI > (again, still, sorry) > > > On Thu, Dec 4, 2014 at 5:33 AM, David Singer > wrote: > > As I understand it, the recent face to face meeting decided to > draft the requirement that WebRTC browsers be required to > implement both VP8 and H.264, and get feedback on this, on the list. > > > > This is some feedback. > > > > > > > > I’d like to point out that this could easily place companies in > an impossible position. > > > > Consider: it is not uncommon for IPR owners to grant a license > (often free) only to ‘conforming implementations’. (A common > rationale is that they want to use their IPR to bring convergence > and interoperability to the industry). Let’s hypothesize that > this happens, now or in future, from Company X, for some IPR in > the WebRTC specifications. > > > > Consider also: we have an “unwilling to license” statement from > Nokia on VP8, on the formal record (and including a long list of > patents). > > > > Consider finally: a small company for whom WebRTC is important. > > > > > > > > Let’s look at the choices: > > > > 1. Follow the mandate, implement VP8, and risk a ruinous > lawsuit from Nokia. > > > > 2. Reject the mandate, do not implement VP8, and be formally > therefore not conformant and therefore not in receipt of a license > from company X; risk a ruinous lawsuit from X. > > > > 3. Do not implement WebRTC, and risk a ruinous loss of relevance. > > > I don't see the risk of 1. having changed because of the IETF's > statement. Plenty of small companies are already doing 1. and have had > to risk getting sued by Nokia at this point in time already. In fact, > it's a risk that small companies always have to deal with since there > is so much patented technology around that you invariable will step on > something. I doubt very much that the IETF's decision has any impact > on small business' risk in that space at all. > > > > I do not think that the IETF should be placing anyone into the > position of having three extremely unpalatable choices. > > For a small company in the WebRTC space, 3. is a non-choice. 2. Is > more of a business decision than an IP decision - which market are you > trying to address? Are you trying to be interoperable with (current) > browsers - then implement VP8. Are you trying to be interoperable with > legacy devices - then implement H.264 (and probably even H.263). > > If you are trying to argue for a large company, the situation changes. > However, as a large company, you tend to have an existing portfolio of > patents. You're already playing the game of patents. As long as your > hypothetical "IPR owners to grant a license only to ‘conforming > implementations’" doesn't happen, you are free to choose 2. and avoid > Nokia. > > As for the threat in your option 2. - I can only see Google with IPR > around VP8. Now, Google's IPR statement on WebM codecs, which includes > VP8 and VP9 currently states: "Google hereby grants to you a > perpetual, worldwide, non-exclusive, no-charge, royalty-free, > irrevocable (except as stated in this section) patent license" > http://www.webmproject.org/license/additional/ > The word "perpetual" implies (to my non-lawyer eyes) that they can't > suddenly change this to mean "only if you are conformant to the > standard". So you can't be referring to such a risk associated with > VP8 being created by Google. I don't know which other company you > would want to be afraid of for your hypothetical threat in 2. Could > you clarify? > > > Best Regards, > Silvia. > > > > (Yes, I am aware that #2 is ‘unlikely’, but one day someone will > decide that the “only to conformant implementations” clause needs > to be real and enforced, and will do this; our hypothetical small > company might prefer not to be the example case.) > > > > (I use a small company as the example, because for them the risk > is bankruptcy, but of course no-one likes to step into the path of > trouble even if they have the resources to weather it.) > > > > Dave Singer > > > > singer@mac.com > > > > David Singer > > Manager, Software Standards, Apple Inc. > > > > _______________________________________________ > > 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 > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------010200030300090306070300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Andrew,

This discussion is kind of silly. We should be investing as much energy into disproving Nokia's IP claim as they have invested into proving it is valid: none at all. The fact that they haven't provided a shred of evidence after repeated public inquiries will be used against them in a court of law, should it ever come up.

Gili

On 04/12/2014 10:43 AM, Andrew Allen wrote:
Silvia

I think the risk for small companies is if they suddenly have a successful product and have revenue that they then become a target. Plenty of cash flow to go after without the experience and resources to fight off the lawsuit.

My point was the fact that small companies may have implemented VP8 without yet becoming engaged in a lawsuit does not prove  that VP8 is RF.

Andrew

Sent from my BlackBerry 10 smartphone.
From: Silvia Pfeiffer
Sent: Wednesday, December 3, 2014 23:17
To: Andrew Allen
Cc: David Singer; rtcweb@ietf.org
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

Indeed, that's why I said point 1. in David's list doesn't make sense, since he's talking about a small company getting sued by Nokia.
S.

On Thu, Dec 4, 2014 at 12:42 PM, Andrew Allen <aallen@blackberry.com> wrote:
Silvia

It  is not usually the small companies that get sued in patent cases. Its companies with assets and significant revenues that get the lawsuits.

Nobody sues the  penniless! - thats like suing the homeless!

Andrew

Sent from my BlackBerry 10 smartphone.
From: Silvia Pfeiffer
Sent: Wednesday, December 3, 2014 19:28
To: David Singer
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

On Thu, Dec 4, 2014 at 5:33 AM, David Singer <singer@apple.com> wrote:
> As I understand it, the recent face to face meeting decided to draft the requirement that WebRTC browsers be required to implement both VP8 and H.264, and get feedback on this, on the list.
>
> This is some feedback.
>
>
>
> I’d like to point out that this could easily place companies in an impossible position.
>
> Consider: it is not uncommon for IPR owners to grant a license (often free) only to ‘conforming implementations’. (A common rationale is that they want to use their IPR to bring convergence and interoperability to the industry).  Let’s hypothesize that this happens, now or in future, from Company X, for some IPR in the WebRTC specifications.
>
> Consider also: we have an “unwilling to license” statement from Nokia on VP8, on the formal record (and including a long list of patents).
>
> Consider finally: a small company for whom WebRTC is important.
>
>
>
> Let’s look at the choices:
>
> 1.  Follow the mandate, implement VP8, and risk a ruinous lawsuit from Nokia.
>
> 2.  Reject the mandate, do not implement VP8, and be formally therefore not conformant and therefore not in receipt of a license from company X; risk a ruinous lawsuit from X.
>
> 3.  Do not implement WebRTC, and risk a ruinous loss of relevance.


I don't see the risk of 1. having changed because of the IETF's
statement. Plenty of small companies are already doing 1. and have had
to risk getting sued by Nokia at this point in time already. In fact,
it's a risk that small companies always have to deal with since there
is so much patented technology around that you invariable will step on
something. I doubt very much that the IETF's decision has any impact
on small business' risk in that space at all.


> I do not think that the IETF should be placing anyone into the position of having three extremely unpalatable choices.

For a small company in the WebRTC space, 3. is a non-choice. 2. Is
more of a business decision than an IP decision - which market are you
trying to address? Are you trying to be interoperable with (current)
browsers - then implement VP8. Are you trying to be interoperable with
legacy devices - then implement H.264 (and probably even H.263).

If you are trying to argue for a large company, the situation changes.
However, as a large company, you tend to have an existing portfolio of
patents. You're already playing the game of patents. As long as your
hypothetical "IPR owners to grant a license only to ‘conforming
implementations’" doesn't happen, you are free to choose 2. and avoid
Nokia.

As for the threat in your option 2. - I can only see Google with IPR
around VP8. Now, Google's IPR statement on WebM codecs, which includes
VP8 and VP9 currently states: "Google hereby grants to you a
perpetual, worldwide, non-exclusive, no-charge, royalty-free,
irrevocable (except as stated in this section) patent license"
http://www.webmproject.org/license/additional/
The word "perpetual" implies (to my non-lawyer eyes) that they can't
suddenly change this to mean "only if you are conformant to the
standard". So you can't be referring to such a risk associated with
VP8 being created by Google. I don't know which other company you
would want to be afraid of for your hypothetical threat in 2. Could
you clarify?


Best Regards,
Silvia.


> (Yes, I am aware that #2 is ‘unlikely’, but one day someone will decide that the “only to conformant implementations” clause needs to be real and enforced, and will do this; our hypothetical small company might prefer not to be the example case.)
>
> (I use a small company as the example, because for them the risk is bankruptcy, but of course no-one likes to step into the path of trouble even if they have the resources to weather it.)
>
> Dave Singer
>
> singer@mac.com
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
> _______________________________________________
> 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



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------010200030300090306070300-- From nobody Thu Dec 4 07:51:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43631AD3BB for ; Thu, 4 Dec 2014 07:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkQT4hXsT8m2 for ; Thu, 4 Dec 2014 07:51:40 -0800 (PST) Received: from smtpcmd01217.aruba.it (smtpcmd01217.aruba.it [62.149.158.217]) by ietfa.amsl.com (Postfix) with ESMTP id E8C961AD46E for ; Thu, 4 Dec 2014 07:50:38 -0800 (PST) Received: from lminiero ([95.247.193.79]) by smtpcmd01.ad.aruba.it with bizsmtp id PTqc1p00o1jExjz01TqcH6; Thu, 04 Dec 2014 16:50:37 +0100 Date: Thu, 4 Dec 2014 16:50:36 +0100 From: Lorenzo Miniero To: Andrew Allen Message-ID: <20141204165036.58efd995@lminiero> In-Reply-To: <20141204154326.5955730.32803.3228@blackberry.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> <20141204154326.5955730.32803.3228@blackberry.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xinIRqXCruUKtAA20mwtwr3qUyw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 15:51:42 -0000 On Thu, 4 Dec 2014 15:43:28 +0000 Andrew Allen wrote: > Silvia >=20 > I think the risk for small companies is if they suddenly have a > successful product and have revenue that they then become a target. > Plenty of cash flow to go after without the experience and resources > to fight off the lawsuit. >=20 Forcing H.264 only on small fishes like us instead will remove the risk of having a successful product entirely, as we wouldn't be able to afford it. I guess we should be grateful. L. > My point was the fact that small companies may have implemented VP8 > without yet becoming engaged in a lawsuit does not prove that VP8 is > RF. >=20 > Andrew >=20 > Sent from my BlackBerry 10 smartphone. > From: Silvia Pfeiffer > Sent: Wednesday, December 3, 2014 23:17 > To: Andrew Allen > Cc: David Singer; rtcweb@ietf.org > Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI > (again, still, sorry) >=20 >=20 > Indeed, that's why I said point 1. in David's list doesn't make > sense, since he's talking about a small company getting sued by > Nokia. S. >=20 > On Thu, Dec 4, 2014 at 12:42 PM, Andrew Allen > > wrote: Silvia >=20 > It is not usually the small companies that get sued in patent cases. > Its companies with assets and significant revenues that get the > lawsuits. >=20 > Nobody sues the penniless! - thats like suing the homeless! >=20 > Andrew >=20 > Sent from my BlackBerry 10 smartphone. > From: Silvia Pfeiffer > Sent: Wednesday, December 3, 2014 19:28 > To: David Singer > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI > (again, still, sorry) >=20 >=20 > On Thu, Dec 4, 2014 at 5:33 AM, David Singer > > wrote: > > As I understand it, the recent face to face meeting decided to > > draft the requirement that WebRTC browsers be required to implement > > both VP8 and H.264, and get feedback on this, on the list. > > > > This is some feedback. > > > > > > > > I=E2=80=99d like to point out that this could easily place companies in= an > > impossible position. > > > > Consider: it is not uncommon for IPR owners to grant a license > > (often free) only to =E2=80=98conforming implementations=E2=80=99. (A c= ommon > > rationale is that they want to use their IPR to bring convergence > > and interoperability to the industry). Let=E2=80=99s hypothesize that = this > > happens, now or in future, from Company X, for some IPR in the > > WebRTC specifications. > > > > Consider also: we have an =E2=80=9Cunwilling to license=E2=80=9D statem= ent from > > Nokia on VP8, on the formal record (and including a long list of > > patents). > > > > Consider finally: a small company for whom WebRTC is important. > > > > > > > > Let=E2=80=99s look at the choices: > > > > 1. Follow the mandate, implement VP8, and risk a ruinous lawsuit > > from Nokia. > > > > 2. Reject the mandate, do not implement VP8, and be formally > > therefore not conformant and therefore not in receipt of a license > > from company X; risk a ruinous lawsuit from X. > > > > 3. Do not implement WebRTC, and risk a ruinous loss of relevance. >=20 >=20 > I don't see the risk of 1. having changed because of the IETF's > statement. Plenty of small companies are already doing 1. and have had > to risk getting sued by Nokia at this point in time already. In fact, > it's a risk that small companies always have to deal with since there > is so much patented technology around that you invariable will step on > something. I doubt very much that the IETF's decision has any impact > on small business' risk in that space at all. >=20 >=20 > > I do not think that the IETF should be placing anyone into the > > position of having three extremely unpalatable choices. >=20 > For a small company in the WebRTC space, 3. is a non-choice. 2. Is > more of a business decision than an IP decision - which market are you > trying to address? Are you trying to be interoperable with (current) > browsers - then implement VP8. Are you trying to be interoperable with > legacy devices - then implement H.264 (and probably even H.263). >=20 > If you are trying to argue for a large company, the situation changes. > However, as a large company, you tend to have an existing portfolio of > patents. You're already playing the game of patents. As long as your > hypothetical "IPR owners to grant a license only to =E2=80=98conforming > implementations=E2=80=99" doesn't happen, you are free to choose 2. and a= void > Nokia. >=20 > As for the threat in your option 2. - I can only see Google with IPR > around VP8. Now, Google's IPR statement on WebM codecs, which includes > VP8 and VP9 currently states: "Google hereby grants to you a > perpetual, worldwide, non-exclusive, no-charge, royalty-free, > irrevocable (except as stated in this section) patent license" > http://www.webmproject.org/license/additional/ > The word "perpetual" implies (to my non-lawyer eyes) that they can't > suddenly change this to mean "only if you are conformant to the > standard". So you can't be referring to such a risk associated with > VP8 being created by Google. I don't know which other company you > would want to be afraid of for your hypothetical threat in 2. Could > you clarify? >=20 >=20 > Best Regards, > Silvia. >=20 >=20 > > (Yes, I am aware that #2 is =E2=80=98unlikely=E2=80=99, but one day som= eone will > > decide that the =E2=80=9Conly to conformant implementations=E2=80=9D cl= ause needs > > to be real and enforced, and will do this; our hypothetical small > > company might prefer not to be the example case.) > > > > (I use a small company as the example, because for them the risk is > > bankruptcy, but of course no-one likes to step into the path of > > trouble even if they have the resources to weather it.) > > > > Dave Singer > > > > singer@mac.com > > > > David Singer > > Manager, Software Standards, Apple Inc. > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Thu Dec 4 08:08:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4831AD460 for ; Thu, 4 Dec 2014 08:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6X39PEdmN2IL for ; Thu, 4 Dec 2014 08:08:24 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id CEBA71AD44A for ; Thu, 4 Dec 2014 08:08:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B85AD7C3585; Thu, 4 Dec 2014 17:08:21 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ce5U0nT32zJw; Thu, 4 Dec 2014 17:08:17 +0100 (CET) Received: from [172.28.249.38] (unknown [74.125.57.89]) by mork.alvestrand.no (Postfix) with ESMTPSA id 509A37C358E; Thu, 4 Dec 2014 17:08:15 +0100 (CET) Message-ID: <548086EE.4020404@alvestrand.no> Date: Thu, 04 Dec 2014 17:08:14 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Andrew Allen , "rtcweb@ietf.org" References: <20141204154332.5955730.14347.3231@blackberry.com> In-Reply-To: <20141204154332.5955730.14347.3231@blackberry.com> Content-Type: multipart/alternative; boundary="------------070004080202040106080102" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DvpyHr-Y2V4LS2vMfJPCrwrfrXY Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 16:08:29 -0000 This is a multi-part message in MIME format. --------------070004080202040106080102 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 12/04/2014 04:43 PM, Andrew Allen wrote: > A > Harald > > To me you seem to be saying this was a very un IETF like political > decision structured to gather enough votes to pass rather than one > based on the usual technical merits of each proposal. The amount of un-IETF-like behaviour around this decision is too large to be captured in a single sentence. My point is: *the proposals are not independent*. The reasons for them not being independent are some of them technical, some of them less so. But arguing for "we should consider the proposals independently" is the same thing as arguing for "we should consider the whole decision unmade and start again with no decisions made". Be careful what you ask for. --------------070004080202040106080102 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 12/04/2014 04:43 PM, Andrew Allen wrote:
A
Harald

To me you seem to be saying this was a very un IETF like political decision structured to gather enough votes to pass rather than one based on the usual technical merits of each proposal.

The amount of un-IETF-like behaviour around this decision is too large to be captured in a single sentence.

My point is: *the proposals are not independent*.

The reasons for them not being independent are some of them technical, some of them less so.

But arguing for "we should consider the proposals independently" is the same thing as arguing for "we should consider the whole decision unmade and start again with no decisions made".

Be careful what you ask for.

--------------070004080202040106080102-- From nobody Thu Dec 4 08:09:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902281A1A15 for ; Thu, 4 Dec 2014 08:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZW4opFljPCEx for ; Thu, 4 Dec 2014 08:09:09 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3991AD450 for ; Thu, 4 Dec 2014 08:09:09 -0800 (PST) Received: from Orochi.local (ip-64-134-140-30.public.wayport.net [64.134.140.30]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB4G93jA073276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Dec 2014 10:09:04 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host ip-64-134-140-30.public.wayport.net [64.134.140.30] claimed to be Orochi.local Message-ID: <54808719.10402@nostrum.com> Date: Thu, 04 Dec 2014 08:08:57 -0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , Ron , rtcweb@ietf.org References: <547511DB.5050100@nostrum.com> <547FC4FD.2050300@andyet.net> <20141204150041.GI10449@hex.shelbyville.oz> <54808198.7030207@andyet.net> In-Reply-To: <54808198.7030207@andyet.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wkWNFvixDINbpE2CFFMXTd34fjs Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 16:09:25 -0000 On 12/4/14 07:45, Peter Saint-Andre - &yet wrote: > On 12/4/14, 8:00 AM, Ron wrote: >> >> On Wed, Dec 03, 2014 at 07:20:45PM -0700, Peter Saint-Andre - &yet >> wrote: >>> >>> IMHO we need to either pull out the future-oriented text entirely >>> (which has >>> its own problems) or significantly improve it. I would be happy to >>> propose >>> text for the latter. >> >> I'd definitely be interested in seeing proposals from you to improve >> upon these things. It seemed premature to explore this until we had >> some sense of whether this kind of compromise could fly at all, but >> now that it seems it can, I think these are important details for us >> to clarify as best we can. > > OK, I'll get to work. :-) Awesome, thanks. I've always found your prose to be clearer and easier to read than mine anyway. :) When you draft your text, keep in mind that what we're trying to do is capture the essence of the agreement that we've formed a critical mass around. The less formal (i.e., not really document-ready) version of this is: > "WebRTC devices MUST implement both VP8 and H.264. If compelling > evidence arises that one of the codecs is available for use on a > royalty-free basis, such as all IPR declarations known for the codec > being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change > this normative statement to indicate that only that codec is required. > For absolute, crystal clarity, this provision is only applicable to > WebRTC devices, and not to WebRTC User Agents." There's nuance to be added there, for sure, but I'd encourage you not to color way outside those lines. Expanding scope to discuss issues such as *other* circumstances that may cause revisiting the MTI, for example, are far more likely to weaken consensus than they are to strengthen it. /a From nobody Thu Dec 4 08:45:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7311AD4EB for ; Thu, 4 Dec 2014 08:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nja5azc5I-Cw for ; Thu, 4 Dec 2014 08:45:19 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE581AD4F3 for ; Thu, 4 Dec 2014 08:45:06 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-a2-54808f901cc9 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 81.86.04076.09F80845; Thu, 4 Dec 2014 17:45:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 17:45:04 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= , Justin Uberti Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAH1cz+AAAO23YA= Date: Thu, 4 Dec 2014 16:45:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D57A684@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE2BC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577322@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577B77@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577CB5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D578C4D@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE9AC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D578E30@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EEA4E@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvje6E/oYQgw+zdCy2ThWyaNh4hdVi 7b92dgdmj9Zne1k9Fmwq9Viy5CdTAHMUl01Kak5mWWqRvl0CV0bvuy3sBa+4Kz41/mNsYDzE 2cXIySEhYCIxo28KC4QtJnHh3no2EFtI4AijxLkvVl2MXED2YkaJK3tnsXYxcnCwCVhIdP/T BomLCOxglJj/eiETSAOzgLrEncXn2EFsYQFTifdzjzCD2CICZhILT05ghLCtJJ7e+QO2gEVA ReLom49gcV4BX4nL938zQiybxC9x6tpesGZOgViJX1OngxUxAl33/dQaqGXiEreezGeCuFpA Ysme88wQtqjEy8f/WCFsJYnGJU9YIer1JG5MncIGYWtLLFv4mhlisaDEyZlPWCYwis1CMnYW kpZZSFpmIWlZwMiyilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwog5u+W21g/Hgc8dDjAIc jEo8vAbn6kOEWBPLiitzDzFKc7AoifMuPDcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj 9+G84KDpUp9P/+juYHXy93Q9wsOQ0c/4lFnWslzxh17pZ/9r5zLtfV80bU+JWmzbKPq7TfCD kXWmwUXOyD1zHBe4nNIOz8r3t+2Wku1l/vlVbsXprKOP/7/7zOd7LlzrAPNRL+G/VTkfoyeK tesq3mWLjBC82/TmQfefKpFKH1/NRRsNdiixFGckGmoxFxUnAgDRSqB7iQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Cy7SJUToTl0XB8PzrpF9GwXMOVo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 16:45:25 -0000 Hi, >>>>> Once a DTLS connection has been established, if the=20 >>>>> 'active/passive' status of the endpoints change during a session,=20 >>>>> a new DTLS connection MUST be established. Therefore, endpoints=20 >>>>> SHOULD NOT change the 'active/passive' status in subsequent offers=20 >>>>> and answers, >>>> >>>> Did not the discussion (for rtcweb) conclude that subsequent offers=20 >>>> should offer actpass, but that subsequent answers must say the same=20 >>>> as the previous answer? >>> >>> In the Offer/Answer section, I can define more details regarding the=20 >>> values (actpass etc) to use. >>> >>> BUT, the question is whether we want to allow the endpoints to=20 >>> trigger a new DTLS connection by changing the active/passive status=20 >>> or not. The text above says SHOULD NOT change the active/passive=20 >>> status. >>=20 >> OK, makes sense to me. > > > I am ok with it as well. > > The strength "SHOULD NOT" seems intentional and I think that is right; so= it is still allowed but not recommended. Yes. > May be obvious, but please be sure to mention that, independent of last o= ffer/answer direction, new=20 > offerer SHOULD include actpass and answerer SHOULD answer with previously= negotiated role. Yes. Of course, if the fingerprint and/or transport parameters change, a new DTL= S connections MUST be established. And, in that case I guess it doesn't mat= ter if the TLS roles are also re-negotiated? Regards, Christer From nobody Thu Dec 4 08:47:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2DE1A024C for ; Thu, 4 Dec 2014 08:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0JTjz6CnBMr for ; Thu, 4 Dec 2014 08:47:42 -0800 (PST) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 847F81A889A for ; Thu, 4 Dec 2014 08:47:37 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id hy4so8120830vcb.2 for ; Thu, 04 Dec 2014 08:47:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TM2hrgwHXVizG4e8HYrlt7LY/DKUiKKoXOauAoeCKZY=; b=bOjMhyVDk8ZTSn3XiNVWhbyq/ypX0A3DhfSfb1fu6VAqt7i6OTWDvq5JSE79CV4v9f xTNE60nxQbLyHiWFYnaq3U+qFBmRfEtsfS2AmFU/jthEVzGZrrNPvcmOU2edEESmj6Vl 1777mrfl+vWiXO7EfSWWKyID0Q7r8MmlS4v1NS7/InocTdQCjwSe0+cZM8vKlN9RE+lz 41e6ZGm6jiIbFCATIPeGt2rMJIsAPwZ7we9d1zXVCsooC3ortmB7CipRariPVOjZRjQu ER+Sd9ANbvh5sqJMUlt6PD6PXW3pdfq0nTIY9NU9K+LpUXApFD2YovS94gh50QRcyaiQ YQrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TM2hrgwHXVizG4e8HYrlt7LY/DKUiKKoXOauAoeCKZY=; b=a4MIpJtwBkCe7nV8IDvt3MJyiO12cUxpWJl9un2Y+51zApALHjQUNahVZXC+HqgI6k Q0JZFDmUm81BhK39i35C6osQr0xhYrxCHKCzuonEUvBcwncIkI8y7RKpGpUV6BbIDeWR g6iJ444XlxbhpcICXC+SMTR8vLWeJDXJrgK/GdsDxyCJGOgZNb4nT11ISdrKeQ04xpzW koJOCNlGbp9vAAMF9zxzg6sdUyBq0OU6blLwSUgsufM6ywX0k3y9eS5ytf6Qo+7y5BYx 4HkIG6gJQApTpa8FqMkMatDMW+YHNrS89/PxMPR/meetIm3GZYq+51f9HdSYqjCr8mwu morA== X-Gm-Message-State: ALoCoQkYL2cie0mIToiwlhu91kqtqCyXge/MTY/Yjo9eDsBeNIy8+Xtz6q89Ug0TkZCF80QQGtUS X-Received: by 10.220.178.3 with SMTP id bk3mr4753774vcb.16.1417711656537; Thu, 04 Dec 2014 08:47:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Thu, 4 Dec 2014 08:47:16 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D578C4D@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE2BC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577322@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577B77@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577CB5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D578C4D@ESESSMB209.ericsson.se> From: Justin Uberti Date: Thu, 4 Dec 2014 08:47:16 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c1d370aeb142050966b7e2 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sZ0owVlLrTOB69lWDQnCuFe0PAU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 16:47:46 -0000 --001a11c1d370aeb142050966b7e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, which document would this be going into? On Thu, Dec 4, 2014 at 5:42 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > What about the following text: > > > > > > 8.3.2. TLS Role Determination > > > > If the m- line proto field value is 'SCTP/DTLS' or 'DTLS/SCTP', the > > SDP setup attribute [RFC4145] is used to determine the 'active/ > > passive' status of the offerer and answerer. The 'active/passive' > > status will be used to determine the TLS roles, following the > > procedures in [RFC4572] (the 'active' endpoint will take the TLS clien= t > > role). > > > > Once a DTLS connection has been established, if the 'active/passive' > > status of the endpoints change during a session, a new DTLS > > connection MUST be established. Therefore, endpoints SHOULD NOT > > change the =E2=80=98active/passive=E2=80=99 status in subsequent offer= s and answers, > > unless they want to establish a new DTLS connection (in which case > > the new 'active/passive' status of the offerer and answerer will be > > used to determine the TLS roles associated with the new DTLS > > connection). > > > > NOTE: The procedure above is identical to the one defined for SRTP- > > DTLS in [RFC5763]. > > > > > > Regards, > > > > Christer > > > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* 4. joulukuuta 2014 8:55 > *To:* Justin Uberti > *Cc:* rtcweb@ietf.org > > *Subject:* Re: [rtcweb] JSEP: Why always offer actpass? > > > > I=E2=80=99ve missed that. Awesome! :) > > > > So, if we=E2=80=99re ok with that approach, then we should use similar te= xt in the > SCTP-SDP draft. > > > > Regards, > > > > Christer > > > > *From:* Justin Uberti [mailto:juberti@google.com ] > *Sent:* 4. joulukuuta 2014 8:53 > *To:* Christer Holmberg > *Cc:* Stefan H=C3=A5kansson LK; Makaraju, Maridi Raju (Raju); Roman Shpou= nt; > rtcweb@ietf.org > *Subject:* Re: [rtcweb] JSEP: Why always offer actpass? > > > > 5763, S 6.6 seems to imply that: > > > > Note that if the active/passive status of the endpoints changes, a new > > connection MUST be established. > > > > > > On Wed, Dec 3, 2014 at 10:30 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > So, one suggestion would be to say that, IF one (there offerer or > answerer) changes the previously negotiated roles, the DTLS connection MU= ST > be re-established =E2=80=93 even if the transport parameters etc aren=E2= =80=99t changed. I > think that would be a very useful clarification. > > > > Regards, > > > > Christer > > > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* 4. joulukuuta 2014 7:49 > *To:* Christer Holmberg > *Cc:* Stefan H=C3=A5kansson LK; Makaraju, Maridi Raju (Raju); Roman Shpou= nt; > rtcweb@ietf.org > > > *Subject:* Re: [rtcweb] JSEP: Why always offer actpass? > > > > Currently, Chrome errors out (i.e. setRD fails). > > > > However, I suspect that teardown of the old DTLS association and setup of > a new DTLS association is the desired behavior. > > > > On Wed, Dec 3, 2014 at 8:34 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > Issue #72 talks about maintaining the previously negotiated role when > actpass is received. I think that is a good approach, and could be used i= n > Offer/Answer too. > > BUT, what does the browser do if e.g. the previous role is passive and > active is received? > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > > *From: *Stefan H=C3=A5kansson LK > *Sent: *=E2=80=8E03/=E2=80=8E12/=E2=80=8E2014 17:48 > *To: *Justin Uberti > *Cc: *Makaraju, Maridi Raju (Raju) ; Ch= rister > Holmberg ; Roman Shpount > ; rtcweb@ietf.org > *Subject: *Re: [rtcweb] JSEP: Why always offer actpass? > > On 01/12/14 18:26, Justin Uberti wrote: > > > > > > On Sun, Nov 30, 2014 at 7:26 AM, Stefan H=C3=A5kansson LK > > > >> wrote: > > > > On 30/11/14 16:06, Makaraju, Maridi Raju (Raju) wrote: > > >> On 30/11/14 14:51, Makaraju, Maridi Raju (Raju) wrote: > > >>>> Hi, > > >>>> > > >>>>>> RFC 7345 (UDPTL-DTLS) says the following: > > >>>>>> > > >>>>>> "Once an offer/answer exchange has been completed, either > > >>>>>> endpoint > > >>>> MAY > > >>>>>> send a new offer in order to modify the session. The > > >>>>>> endpoints > > >>>> can > > >>>>>> reuse the existing DTLS association if the key fingerprint > > >>>>>> values > > >>>> and > > >>>>>> transport parameters indicated by each endpoint are > unchanged. > > >>>>>> Otherwise, following the rules for the initial offer/answer > > >>>> exchange, > > >>>>>> the endpoints can negotiate and create a new DTLS associati= on > > >>>>>> and, once created, delete the previous DTLS association, > > >>>>>> following the same rules for the initial offer/answer > exchange. > > >>>>>> Each endpoint needs to be prepared to receive data on both > the > > >>>>>> new and old DTLS associations as long as both are alive." > > >>>>>> > > >>>>>> So, I guess that can be read in a way that the setup > attribute > > >>>>>> as such > > >>>> does not impact previously > > >>>>>> negotiated TLS roles - unless the key fingerprint values > and/or > > >>>>>> transport > > >>>> parameters are modified. > > >>>>>> > > >>>>>> The SCTP-SDP draft currently says that a subsequent offer > must > > >>>>>> not change > > >>>> the previously negotiated roles. But, I guess > > >>>>>> we could say something similar as in RFC 7345. > > >>>>> > > >>>>> I have struggled with this language quite a bit from the > > >>>>> implementation > > >>>> perspective. I think we need to explicitly state > > >>>>> that endpoints MUST reuse the existing association if the ke= y > > >>>>> fingerprint > > >>>> values and transport parameters indicated > > >>>>> by each endpoint are unchanged. > > >>>> > > >>>> We could take such general approach. > > >>>> > > >>>> However, for 'SCTP/DTLS' (DTLS over SCTP), I assume that the > DTLS > > >>>> connection will also be re-established if the underlying SCTP > > >>>> association is re- established - even if no transport > parameters > > >>>> etc are changed. > > >>>> > > >>>> Also, RFC 6083 says: > > >>>> > > >>>> "Each DTLS connection MUST be established and terminated > > within the > > >>>> same SCTP association." > > >>>> > > >>>> > > >>>>> The way this language reads to me is that endpoints can reus= e > the > > >>>>> existing > > >>>> association if they want to, but they can create a new one if > they > > >>>> don't. Also, when this new > > >>>>> association is created, it is unclear if old setup roles MUS= T > be > > >>>>> preserved > > >>>> or if they MUST be selected based on the current offer/answer > > >>>> exchange. It seems the current > > >>>>> specification language is not strong or clear enough on this > > >>>>> topic. > > >>>> > > >>>> In my opinion, IF a new DTLS connection needs to be establish= ed > > >>>> (for whatever reasons), the current roles should be used. > > >>> > > >>> When ICE is NOT used, how does the offerer know that th= e > > >>> answerer does not change the fingerprint and/or transport > > parameters? > > >>> I guess it does not know. So, offerer has to be prepared for > > new DTLS > > >>> association by offering actpass. When ICE is used, the answere= r > > can't > > >>> change transport parameter unless offerer does ICE restart > (which > > >>> changes offerer transport parameters); Ref [1] is very clear o= n > > this > > >>> indicating "DTLS handshake procedure is repeated". However, > > even when > > >>> ICE is used, I do not find any restriction about answerer not > > >>> changing fingerprint. So, even without ICE restart answerer ca= n > > >>> trigger a DTLS renegotiation by changing its fingerprint. > > >>> > > >>> To conclude all this, IMO whether ICE is used or not, sending > > actpass > > >>> for all new offers may be cover all possible scenarios. > > >> > > >> That is also my conclusion based on the discussion so far. > > >> > > >> I also think the JSEP draft as far as detailed out is correct, > > but info > > >> about how the implementation should behave for Subsequent > answers is > > >> missing. Text saying that the role must be maintained (unless > > there is > > >> an ICE restart) should be put in there. > > > > > > > > > Hi Stefan, > > > Looks like, there is some misunderstanding here. > > > > Probably my fault in that case :) > > > > > My conclusion is to include > > > actpass, but not the previously negotiated role, in all subsequen= t > offers, > > > not just during ICE-restarts. > > > > I think that is what the JSEP draft says - and my conclusion is tha= t > it > > _is_ correct. > > > > My point was that the _answer_ should (when it is a subsequent > answer) > > should say the same role as in previous answers (unless there is an > ICE > > restart). > > > > I agree the JSEP text should indicate that roles should stay the same. > > We have had this as a TODO for a while: > > https://github.com/rtcweb-wg/jsep/issues/72 > > Great. I should have checked that out before. > > > > > --001a11c1d370aeb142050966b7e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, which document would this be going into?

On Thu, Dec 4, 2014 at= 5:42 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

What about the following = text:

=C2=A0

=C2=A0

8.3.2.=C2=A0 TLS Role Determination

=C2=A0

=C2=A0=C2=A0 If the m- line proto field value is 'SCTP= /DTLS' or 'DTLS/SCTP', the

=C2=A0=C2=A0 SDP setup attribute [RFC4145] is used to dete= rmine the 'active/

=C2=A0=C2=A0 passive' status of the offerer and answer= er.=C2=A0 The 'active/passive'

=C2=A0=C2=A0 status will be used to determine the TLS role= s, following the

=C2=A0=C2=A0 procedures in [RFC4572] (the 'active'= endpoint will take the TLS client

=C2=A0=C2=A0 role).

=C2=A0

=C2=A0=C2=A0 Once a DTLS connection has been established, = if the 'active/passive'

=C2=A0=C2=A0 status of the endpoints change during a sessi= on, a new DTLS

=C2=A0=C2=A0 connection MUST be established.=C2=A0 Therefo= re, endpoints SHOULD NOT

=C2=A0=C2=A0 change the =E2=80=98active/passive=E2=80=99 s= tatus in subsequent offers and answers,

=C2=A0=C2=A0 unless they want to establish a new DTLS conn= ection (in which case

=C2=A0=C2=A0 the new 'active/passive' status of th= e offerer and answerer will be

=C2=A0=C2=A0 used to determine the TLS roles associated wi= th the new DTLS

=C2=A0=C2=A0 connection).

=C2=A0

=C2=A0=C2=A0 NOTE: The procedure above is identical to the= one defined for SRTP-

=C2=A0=C2=A0 DTLS in [RFC5763].

=C2=A0

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: rtcweb [= mailto:rtcweb-= bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 4. joulukuuta 2014 8:55
To: Justin Uberti
Cc: rtcweb@ietf= .org


Subject: Re: [rtcweb] JSEP: Why always offer actpass?<= /div>

=C2=A0

I=E2=80=99ve missed that.= Awesome! :)

=C2=A0

So, if we=E2=80=99re ok w= ith that approach, then we should use similar text in the SCTP-SDP draft.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: 4. joulukuuta 2014 8:53
To: Christer Holmberg
Cc: Stefan H=C3=A5kansson LK; Makaraju, Maridi Raju (Raju); Roman Sh= pount; rtcweb@ietf.org
Subject: Re: [rtcweb] JSEP: Why always offer actpass?<= /span>

=C2=A0

5763, S 6.6 seems to imply that:

=C2=A0

=C2=A0Note that if the active/passive status of the = endpoints changes, a new

=C2=A0connection MUST be established.<= /p>

=C2=A0

=C2=A0

On Wed, Dec 3, 2014 at 10:30 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,<= /p>

=C2=A0

So, one suggestion would = be to say that, IF one (there offerer or answerer) changes the previously negotiated roles, the DTLS connection MUST be re-established =E2=80=93 eve= n if the transport parameters etc aren=E2=80=99t changed. I think that woul= d be a very useful clarification.

=C2=A0

Regards,=

=C2=A0

Christer=

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: 4. joulukuuta 2014 7:49
To: Christer Holmberg
Cc: Stefan H=C3=A5kansson LK; Makaraju, Maridi Raju (Raju); Roman Sh= pount; rtcweb@ietf.org


Subject: Re: [rtcweb] JSEP: Why always offer actpass?<= /p>

=C2=A0

Currently, Chrome errors out (i.e. setRD fails).<= /u>

=C2=A0

However, I suspect that teardown of the old DTLS ass= ociation and setup of a new DTLS association is the desired behavior.

=C2=A0

On Wed, Dec 3, 2014 at 8:34 PM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:

Hi,

Issue #72 talks about maintaining the previously negotiated role when actpa= ss is received. I think that is a good approach, and could be used in Offer= /Answer too.

BUT, what does the browser do if e.g. the previous role is passive and acti= ve is received?

Regards,

Christer

Sent from my Windows Phone

From: Stefan H=C3=A5kansson LK
Sent: =E2=80=8E03/=E2=80=8E12/=E2=80=8E2014 17:48
To: Justin Uberti
Cc: Makaraju, Maridi Raju (Raju); Christe= r Holmberg; Roman Shpount; <= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank"> rtcweb@ietf.org
Subject: Re: [rtcweb] JSEP: Why always offer actpass?=

On 01/12/14 18:26, Justin Uberti wrote:
>
>
> On Sun, Nov 30, 2014 at 7:26 AM, Stefan H=C3=A5kansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>=C2=A0=C2=A0=C2=A0=C2=A0 On 30/11/14 16:06, Makaraju, Maridi Raju (Raju= ) wrote:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> On 30/11/14 14:51, Makaraju, Ma= ridi Raju (Raju) wrote:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> Hi,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> RFC 7345 (UDPTL= -DTLS) says the following:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> "Once an o= ffer/answer exchange has been completed, either
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> endpoint
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> MAY
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> send a new offe= r in order to modify the session.=C2=A0 The
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> endpoints
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> can
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> reuse the exist= ing DTLS association if the key fingerprint
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> values
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> and
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> transport param= eters indicated by each endpoint are unchanged.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> Otherwise, foll= owing the rules for the initial offer/answer
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> exchange,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> the endpoints c= an negotiate and create a new DTLS association
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> and, once creat= ed, delete the previous DTLS association,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> following the s= ame rules for the initial offer/answer exchange.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> Each endpoint n= eeds to be prepared to receive data on both the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> new and old DTL= S associations as long as both are alive."
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> So, I guess tha= t can be read in a way that the setup attribute
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> as such
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> does not impact previou= sly
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> negotiated TLS = roles - unless the key fingerprint values and/or
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> transport
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> parameters are modified= .
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> The SCTP-SDP dr= aft currently says that a subsequent offer must
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> not change
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> the previously negotiat= ed roles. But, I guess
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>> we could say so= mething similar as in RFC 7345.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> I have struggled wi= th this language quite a bit from the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> implementation
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> perspective. I think we= need to explicitly state
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> that endpoints MUST= reuse the existing association if the key
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> fingerprint
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> values and transport pa= rameters indicated
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> by each endpoint ar= e unchanged.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> We could take such gene= ral approach.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> However, for 'SCTP/= DTLS' (DTLS over SCTP), I assume that the DTLS
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> connection will also be= re-established if the underlying SCTP
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> association is re- esta= blished - even if no transport parameters
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> etc are changed.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> Also, RFC 6083 says: >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> "Each DTLS connect= ion MUST be established and terminated
>=C2=A0=C2=A0=C2=A0=C2=A0 within the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> same SCTP association.&= quot;
>=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=A0=C2=A0=C2=A0 >>>>> The way this langua= ge reads to me is that endpoints can reuse the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> existing
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> association if they wan= t to, but they can create a new one if they
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> don't. Also, when t= his new
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> association is crea= ted, it is unclear if old setup roles MUST be
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> preserved
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> or if they MUST be sele= cted based on the current offer/answer
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> exchange. It seems the = current
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> specification langu= age is not strong or clear enough on this
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>> topic.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> In my opinion, IF a new= DTLS connection needs to be established
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>> (for whatever reasons),= the current roles should be used.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> <Raju> When ICE is NO= T used, how does the offerer know that the
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> answerer does not change th= e fingerprint and/or transport
>=C2=A0=C2=A0=C2=A0=C2=A0 parameters?
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> I guess it does not know. S= o, offerer has to be prepared for
>=C2=A0=C2=A0=C2=A0=C2=A0 new DTLS
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> association by offering act= pass. When ICE is used, the answerer
>=C2=A0=C2=A0=C2=A0=C2=A0 can't
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> change transport parameter = unless offerer does ICE restart (which
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> changes offerer transport p= arameters); Ref [1] is very clear on
>=C2=A0=C2=A0=C2=A0=C2=A0 this
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> indicating "DTLS hands= hake procedure is repeated". However,
>=C2=A0=C2=A0=C2=A0=C2=A0 even when
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> ICE is used, I do not find = any restriction about answerer not
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> changing fingerprint. So, e= ven without ICE restart answerer can
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> trigger a DTLS renegotiatio= n by changing its fingerprint.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> To conclude all this, IMO w= hether ICE is used or not, sending
>=C2=A0=C2=A0=C2=A0=C2=A0 actpass
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> for all new offers may be c= over all possible scenarios.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> That is also my conclusion base= d on the discussion so far.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> I also think the JSEP draft as = far as detailed out is correct,
>=C2=A0=C2=A0=C2=A0=C2=A0 but info
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> about how the implementation sh= ould behave for Subsequent answers is
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> missing. Text saying that the r= ole must be maintained (unless
>=C2=A0=C2=A0=C2=A0=C2=A0 there is
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> an ICE restart) should be put i= n there.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <Raju>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Hi Stefan,
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Looks like, there is some misunders= tanding here.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 Probably my fault in that case :)
>
>=C2=A0=C2=A0=C2=A0=C2=A0 > My conclusion is to include
>=C2=A0=C2=A0=C2=A0=C2=A0 > actpass, but not the previously negotiate= d role, in all subsequent offers,
>=C2=A0=C2=A0=C2=A0=C2=A0 > not just during ICE-restarts.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 I think that is what the JSEP draft says - and= my conclusion is that it
>=C2=A0=C2=A0=C2=A0=C2=A0 _is_ correct.
>
>=C2=A0=C2=A0=C2=A0=C2=A0 My point was that the _answer_ should (when it= is a subsequent answer)
>=C2=A0=C2=A0=C2=A0=C2=A0 should say the same role as in previous answer= s (unless there is an ICE
>=C2=A0=C2=A0=C2=A0=C2=A0 restart).
>
> I agree the JSEP text should indicate that roles should stay the same.=
> We have had this as a TODO for a while:
> https://github.com/rtcweb-wg/jsep/issues/72

Great. I should have checked that out before.

=C2=A0

=C2=A0


--001a11c1d370aeb142050966b7e2-- From nobody Thu Dec 4 08:56:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5761AD4A7 for ; Thu, 4 Dec 2014 08:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQE6JjTXsTW1 for ; Thu, 4 Dec 2014 08:56:17 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED86F1AD4B3 for ; Thu, 4 Dec 2014 08:56:15 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-9a-5480922d1ca2 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 97.8B.24955.D2290845; Thu, 4 Dec 2014 17:56:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 17:56:13 +0100 From: Christer Holmberg To: Justin Uberti Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAHfyaaUAACD+YAAA3cSQP//9fwA///u34D//2vgsIABS2oA///tD7A= Date: Thu, 4 Dec 2014 16:56:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D57A73E@ESESSMB209.ericsson.se> References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE2BC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577322@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577B77@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577CB5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D578C4D@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D57A73EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3Rld3UkOIwbQ+S4utU4Us1v5rZ3dg 8liwqdRjyZKfTAFMUVw2Kak5mWWpRfp2CVwZS6beYSs49Iq54sfsdewNjE/uMncxcnBICJhI rNsk08XICWSKSVy4t54NxBYSOMIoMfUXaxcjF5C9mFGi//sCRpB6NgELie5/2iA1IgJqEg9n 7WIFsZkF1CXuLD7HDmILC5hKvJ97hBmixkxi4ckJjBB2ksSMGV/B6lkEVCTevV/NAmLzCvhK TNkxlwVi1y5eiXfLJoE1cwoESmzf/hNsKCPQcd9PrWGCWCYucevJfCaIowUkluw5zwxhi0q8 fPyPFcJWkmhc8gTquHyJYw/b2SGWCUqcnPmEZQKj6Cwko2YhKZuFpGwW0MvMApoS63fpQ5Qo SkzpfsgOYWtItM6Zy44svoCRfRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYKwd3PJbdQfj 5TeOhxgFOBiVeHgNztWHCLEmlhVX5h5ilOZgURLnXXhuXrCQQHpiSWp2ampBalF8UWlOavEh RiYOTqkGRnVdpQ217hxVN93ky06K22tVisyeesArlDkkvyxlc8853z1cp6uebTpz6kbUn2h7 yRMeQQkn7R6f5xdjebCm76183eewzwv25vXN85twKi44puZFc8yd/Ajjl+weTpcCFBInNMqF d6+0ahfie9+i8+LtTssCQ3Ve69PZGtsd++f1XDZtjRRQYinOSDTUYi4qTgQAX+i8VpYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xbL-ZiNAHZmVT7zitufyCix8_tc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 16:56:21 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D57A73EESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoaXMgd291bGQgZ28gaW50byB0aGUgU0NUUC1TRFAgZHJhZnQuIFNvcnJ5IGZvciBu b3QgbWVudGlvbmluZyB0aGF0IDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IEp1 c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQpTZW50OiAwNCBEZWNlbWJl ciAyMDE0IDE4OjQ3DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcNCkNjOiBydGN3ZWJAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBKU0VQOiBXaHkgYWx3YXlzIG9mZmVyIGFjdHBhc3M/DQoN ClNvcnJ5LCB3aGljaCBkb2N1bWVudCB3b3VsZCB0aGlzIGJlIGdvaW5nIGludG8/DQoNCk9uIFRo dSwgRGVjIDQsIDIwMTQgYXQgNTo0MiBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t Pj4gd3JvdGU6DQpXaGF0IGFib3V0IHRoZSBmb2xsb3dpbmcgdGV4dDoNCg0KDQo4LjMuMi4gIFRM UyBSb2xlIERldGVybWluYXRpb24NCg0KICAgSWYgdGhlIG0tIGxpbmUgcHJvdG8gZmllbGQgdmFs dWUgaXMgJ1NDVFAvRFRMUycgb3IgJ0RUTFMvU0NUUCcsIHRoZQ0KICAgU0RQIHNldHVwIGF0dHJp YnV0ZSBbUkZDNDE0NV0gaXMgdXNlZCB0byBkZXRlcm1pbmUgdGhlICdhY3RpdmUvDQogICBwYXNz aXZlJyBzdGF0dXMgb2YgdGhlIG9mZmVyZXIgYW5kIGFuc3dlcmVyLiAgVGhlICdhY3RpdmUvcGFz c2l2ZScNCiAgIHN0YXR1cyB3aWxsIGJlIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBUTFMgcm9sZXMs IGZvbGxvd2luZyB0aGUNCiAgIHByb2NlZHVyZXMgaW4gW1JGQzQ1NzJdICh0aGUgJ2FjdGl2ZScg ZW5kcG9pbnQgd2lsbCB0YWtlIHRoZSBUTFMgY2xpZW50DQogICByb2xlKS4NCg0KICAgT25jZSBh IERUTFMgY29ubmVjdGlvbiBoYXMgYmVlbiBlc3RhYmxpc2hlZCwgaWYgdGhlICdhY3RpdmUvcGFz c2l2ZScNCiAgIHN0YXR1cyBvZiB0aGUgZW5kcG9pbnRzIGNoYW5nZSBkdXJpbmcgYSBzZXNzaW9u LCBhIG5ldyBEVExTDQogICBjb25uZWN0aW9uIE1VU1QgYmUgZXN0YWJsaXNoZWQuICBUaGVyZWZv cmUsIGVuZHBvaW50cyBTSE9VTEQgTk9UDQogICBjaGFuZ2UgdGhlIOKAmGFjdGl2ZS9wYXNzaXZl 4oCZIHN0YXR1cyBpbiBzdWJzZXF1ZW50IG9mZmVycyBhbmQgYW5zd2VycywNCiAgIHVubGVzcyB0 aGV5IHdhbnQgdG8gZXN0YWJsaXNoIGEgbmV3IERUTFMgY29ubmVjdGlvbiAoaW4gd2hpY2ggY2Fz ZQ0KICAgdGhlIG5ldyAnYWN0aXZlL3Bhc3NpdmUnIHN0YXR1cyBvZiB0aGUgb2ZmZXJlciBhbmQg YW5zd2VyZXIgd2lsbCBiZQ0KICAgdXNlZCB0byBkZXRlcm1pbmUgdGhlIFRMUyByb2xlcyBhc3Nv Y2lhdGVkIHdpdGggdGhlIG5ldyBEVExTDQogICBjb25uZWN0aW9uKS4NCg0KICAgTk9URTogVGhl IHByb2NlZHVyZSBhYm92ZSBpcyBpZGVudGljYWwgdG8gdGhlIG9uZSBkZWZpbmVkIGZvciBTUlRQ LQ0KICAgRFRMUyBpbiBbUkZDNTc2M10uDQoNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpG cm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRjd2Vi LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNClNlbnQ6 IDQuIGpvdWx1a3V1dGEgMjAxNCA4OjU1DQpUbzogSnVzdGluIFViZXJ0aQ0KQ2M6IHJ0Y3dlYkBp ZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0g SlNFUDogV2h5IGFsd2F5cyBvZmZlciBhY3RwYXNzPw0KDQpJ4oCZdmUgbWlzc2VkIHRoYXQuIEF3 ZXNvbWUhIDopDQoNClNvLCBpZiB3ZeKAmXJlIG9rIHdpdGggdGhhdCBhcHByb2FjaCwgdGhlbiB3 ZSBzaG91bGQgdXNlIHNpbWlsYXIgdGV4dCBpbiB0aGUgU0NUUC1TRFAgZHJhZnQuDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdv b2dsZS5jb21dDQpTZW50OiA0LiBqb3VsdWt1dXRhIDIwMTQgODo1Mw0KVG86IENocmlzdGVyIEhv bG1iZXJnDQpDYzogU3RlZmFuIEjDpWthbnNzb24gTEs7IE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAo UmFqdSk7IFJvbWFuIFNocG91bnQ7IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIEpTRVA6IFdoeSBhbHdheXMgb2ZmZXIgYWN0cGFz cz8NCg0KNTc2MywgUyA2LjYgc2VlbXMgdG8gaW1wbHkgdGhhdDoNCg0KIE5vdGUgdGhhdCBpZiB0 aGUgYWN0aXZlL3Bhc3NpdmUgc3RhdHVzIG9mIHRoZSBlbmRwb2ludHMgY2hhbmdlcywgYSBuZXcN CiBjb25uZWN0aW9uIE1VU1QgYmUgZXN0YWJsaXNoZWQuDQoNCg0KT24gV2VkLCBEZWMgMywgMjAx NCBhdCAxMDozMCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpI aSwNCg0KU28sIG9uZSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRvIHNheSB0aGF0LCBJRiBvbmUgKHRo ZXJlIG9mZmVyZXIgb3IgYW5zd2VyZXIpIGNoYW5nZXMgdGhlIHByZXZpb3VzbHkgbmVnb3RpYXRl ZCByb2xlcywgdGhlIERUTFMgY29ubmVjdGlvbiBNVVNUIGJlIHJlLWVzdGFibGlzaGVkIOKAkyBl dmVuIGlmIHRoZSB0cmFuc3BvcnQgcGFyYW1ldGVycyBldGMgYXJlbuKAmXQgY2hhbmdlZC4gSSB0 aGluayB0aGF0IHdvdWxkIGJlIGEgdmVyeSB1c2VmdWwgY2xhcmlmaWNhdGlvbi4NCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29v Z2xlLmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPl0NClNlbnQ6IDQuIGpvdWx1a3V1dGEg MjAxNCA3OjQ5DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcNCkNjOiBTdGVmYW4gSMOla2Fuc3NvbiBM SzsgTWFrYXJhanUsIE1hcmlkaSBSYWp1IChSYWp1KTsgUm9tYW4gU2hwb3VudDsgcnRjd2ViQGll dGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBK U0VQOiBXaHkgYWx3YXlzIG9mZmVyIGFjdHBhc3M/DQoNCkN1cnJlbnRseSwgQ2hyb21lIGVycm9y cyBvdXQgKGkuZS4gc2V0UkQgZmFpbHMpLg0KDQpIb3dldmVyLCBJIHN1c3BlY3QgdGhhdCB0ZWFy ZG93biBvZiB0aGUgb2xkIERUTFMgYXNzb2NpYXRpb24gYW5kIHNldHVwIG9mIGEgbmV3IERUTFMg YXNzb2NpYXRpb24gaXMgdGhlIGRlc2lyZWQgYmVoYXZpb3IuDQoNCk9uIFdlZCwgRGVjIDMsIDIw MTQgYXQgODozNCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpI aSwNCg0KSXNzdWUgIzcyIHRhbGtzIGFib3V0IG1haW50YWluaW5nIHRoZSBwcmV2aW91c2x5IG5l Z290aWF0ZWQgcm9sZSB3aGVuIGFjdHBhc3MgaXMgcmVjZWl2ZWQuIEkgdGhpbmsgdGhhdCBpcyBh IGdvb2QgYXBwcm9hY2gsIGFuZCBjb3VsZCBiZSB1c2VkIGluIE9mZmVyL0Fuc3dlciB0b28uDQoN CkJVVCwgd2hhdCBkb2VzIHRoZSBicm93c2VyIGRvIGlmIGUuZy4gdGhlIHByZXZpb3VzIHJvbGUg aXMgcGFzc2l2ZSBhbmQgYWN0aXZlIGlzIHJlY2VpdmVkPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZQ0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkZyb206IFN0ZWZhbiBIw6VrYW5zc29uIExLPG1haWx0bzpzdGVmYW4ubGsuaGFr YW5zc29uQGVyaWNzc29uLmNvbT4NClNlbnQ6IOKAjjAzL+KAjjEyL+KAjjIwMTQgMTc6NDgNClRv OiBKdXN0aW4gVWJlcnRpPG1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20+DQpDYzogTWFrYXJhanUs IE1hcmlkaSBSYWp1IChSYWp1KTxtYWlsdG86UmFqdS5NYWthcmFqdUBhbGNhdGVsLWx1Y2VudC5j b20+OyBDaHJpc3RlciBIb2xtYmVyZzxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPjsgUm9tYW4gU2hwb3VudDxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+OyBydGN3ZWJAaWV0 Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBKU0VQ OiBXaHkgYWx3YXlzIG9mZmVyIGFjdHBhc3M/DQpPbiAwMS8xMi8xNCAxODoyNiwgSnVzdGluIFVi ZXJ0aSB3cm90ZToNCj4NCj4NCj4gT24gU3VuLCBOb3YgMzAsIDIwMTQgYXQgNzoyNiBBTSwgU3Rl ZmFuIEjDpWthbnNzb24gTEsNCj4gPHN0ZWZhbi5say5oYWthbnNzb25AZXJpY3Nzb24uY29tPG1h aWx0bzpzdGVmYW4ubGsuaGFrYW5zc29uQGVyaWNzc29uLmNvbT4NCj4gPG1haWx0bzpzdGVmYW4u bGsuaGFrYW5zc29uQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KPg0KPiAgICAgT24gMzAvMTEvMTQg MTY6MDYsIE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkgd3JvdGU6DQo+ICAgICAgPj4gT24g MzAvMTEvMTQgMTQ6NTEsIE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkgd3JvdGU6DQo+ICAg ICAgPj4+PiBIaSwNCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+Pj4+IFJGQyA3MzQ1IChVRFBUTC1E VExTKSBzYXlzIHRoZSBmb2xsb3dpbmc6DQo+ICAgICAgPj4+Pj4+DQo+ICAgICAgPj4+Pj4+ICJP bmNlIGFuIG9mZmVyL2Fuc3dlciBleGNoYW5nZSBoYXMgYmVlbiBjb21wbGV0ZWQsIGVpdGhlcg0K PiAgICAgID4+Pj4+PiBlbmRwb2ludA0KPiAgICAgID4+Pj4gTUFZDQo+ICAgICAgPj4+Pj4+IHNl bmQgYSBuZXcgb2ZmZXIgaW4gb3JkZXIgdG8gbW9kaWZ5IHRoZSBzZXNzaW9uLiAgVGhlDQo+ICAg ICAgPj4+Pj4+IGVuZHBvaW50cw0KPiAgICAgID4+Pj4gY2FuDQo+ICAgICAgPj4+Pj4+IHJldXNl IHRoZSBleGlzdGluZyBEVExTIGFzc29jaWF0aW9uIGlmIHRoZSBrZXkgZmluZ2VycHJpbnQNCj4g ICAgICA+Pj4+Pj4gdmFsdWVzDQo+ICAgICAgPj4+PiBhbmQNCj4gICAgICA+Pj4+Pj4gdHJhbnNw b3J0IHBhcmFtZXRlcnMgaW5kaWNhdGVkIGJ5IGVhY2ggZW5kcG9pbnQgYXJlIHVuY2hhbmdlZC4N Cj4gICAgICA+Pj4+Pj4gT3RoZXJ3aXNlLCBmb2xsb3dpbmcgdGhlIHJ1bGVzIGZvciB0aGUgaW5p dGlhbCBvZmZlci9hbnN3ZXINCj4gICAgICA+Pj4+IGV4Y2hhbmdlLA0KPiAgICAgID4+Pj4+PiB0 aGUgZW5kcG9pbnRzIGNhbiBuZWdvdGlhdGUgYW5kIGNyZWF0ZSBhIG5ldyBEVExTIGFzc29jaWF0 aW9uDQo+ICAgICAgPj4+Pj4+IGFuZCwgb25jZSBjcmVhdGVkLCBkZWxldGUgdGhlIHByZXZpb3Vz IERUTFMgYXNzb2NpYXRpb24sDQo+ICAgICAgPj4+Pj4+IGZvbGxvd2luZyB0aGUgc2FtZSBydWxl cyBmb3IgdGhlIGluaXRpYWwgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlLg0KPiAgICAgID4+Pj4+PiBF YWNoIGVuZHBvaW50IG5lZWRzIHRvIGJlIHByZXBhcmVkIHRvIHJlY2VpdmUgZGF0YSBvbiBib3Ro IHRoZQ0KPiAgICAgID4+Pj4+PiBuZXcgYW5kIG9sZCBEVExTIGFzc29jaWF0aW9ucyBhcyBsb25n IGFzIGJvdGggYXJlIGFsaXZlLiINCj4gICAgICA+Pj4+Pj4NCj4gICAgICA+Pj4+Pj4gU28sIEkg Z3Vlc3MgdGhhdCBjYW4gYmUgcmVhZCBpbiBhIHdheSB0aGF0IHRoZSBzZXR1cCBhdHRyaWJ1dGUN Cj4gICAgICA+Pj4+Pj4gYXMgc3VjaA0KPiAgICAgID4+Pj4gZG9lcyBub3QgaW1wYWN0IHByZXZp b3VzbHkNCj4gICAgICA+Pj4+Pj4gbmVnb3RpYXRlZCBUTFMgcm9sZXMgLSB1bmxlc3MgdGhlIGtl eSBmaW5nZXJwcmludCB2YWx1ZXMgYW5kL29yDQo+ICAgICAgPj4+Pj4+IHRyYW5zcG9ydA0KPiAg ICAgID4+Pj4gcGFyYW1ldGVycyBhcmUgbW9kaWZpZWQuDQo+ICAgICAgPj4+Pj4+DQo+ICAgICAg Pj4+Pj4+IFRoZSBTQ1RQLVNEUCBkcmFmdCBjdXJyZW50bHkgc2F5cyB0aGF0IGEgc3Vic2VxdWVu dCBvZmZlciBtdXN0DQo+ICAgICAgPj4+Pj4+IG5vdCBjaGFuZ2UNCj4gICAgICA+Pj4+IHRoZSBw cmV2aW91c2x5IG5lZ290aWF0ZWQgcm9sZXMuIEJ1dCwgSSBndWVzcw0KPiAgICAgID4+Pj4+PiB3 ZSBjb3VsZCBzYXkgc29tZXRoaW5nIHNpbWlsYXIgYXMgaW4gUkZDIDczNDUuDQo+ICAgICAgPj4+ Pj4NCj4gICAgICA+Pj4+PiBJIGhhdmUgc3RydWdnbGVkIHdpdGggdGhpcyBsYW5ndWFnZSBxdWl0 ZSBhIGJpdCBmcm9tIHRoZQ0KPiAgICAgID4+Pj4+IGltcGxlbWVudGF0aW9uDQo+ICAgICAgPj4+ PiBwZXJzcGVjdGl2ZS4gSSB0aGluayB3ZSBuZWVkIHRvIGV4cGxpY2l0bHkgc3RhdGUNCj4gICAg ICA+Pj4+PiB0aGF0IGVuZHBvaW50cyBNVVNUIHJldXNlIHRoZSBleGlzdGluZyBhc3NvY2lhdGlv biBpZiB0aGUga2V5DQo+ICAgICAgPj4+Pj4gZmluZ2VycHJpbnQNCj4gICAgICA+Pj4+IHZhbHVl cyBhbmQgdHJhbnNwb3J0IHBhcmFtZXRlcnMgaW5kaWNhdGVkDQo+ICAgICAgPj4+Pj4gYnkgZWFj aCBlbmRwb2ludCBhcmUgdW5jaGFuZ2VkLg0KPiAgICAgID4+Pj4NCj4gICAgICA+Pj4+IFdlIGNv dWxkIHRha2Ugc3VjaCBnZW5lcmFsIGFwcHJvYWNoLg0KPiAgICAgID4+Pj4NCj4gICAgICA+Pj4+ IEhvd2V2ZXIsIGZvciAnU0NUUC9EVExTJyAoRFRMUyBvdmVyIFNDVFApLCBJIGFzc3VtZSB0aGF0 IHRoZSBEVExTDQo+ICAgICAgPj4+PiBjb25uZWN0aW9uIHdpbGwgYWxzbyBiZSByZS1lc3RhYmxp c2hlZCBpZiB0aGUgdW5kZXJseWluZyBTQ1RQDQo+ICAgICAgPj4+PiBhc3NvY2lhdGlvbiBpcyBy ZS0gZXN0YWJsaXNoZWQgLSBldmVuIGlmIG5vIHRyYW5zcG9ydCBwYXJhbWV0ZXJzDQo+ICAgICAg Pj4+PiBldGMgYXJlIGNoYW5nZWQuDQo+ICAgICAgPj4+Pg0KPiAgICAgID4+Pj4gQWxzbywgUkZD IDYwODMgc2F5czoNCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+PiAiRWFjaCBEVExTIGNvbm5lY3Rp b24gTVVTVCBiZSBlc3RhYmxpc2hlZCBhbmQgdGVybWluYXRlZA0KPiAgICAgd2l0aGluIHRoZQ0K PiAgICAgID4+Pj4gc2FtZSBTQ1RQIGFzc29jaWF0aW9uLiINCj4gICAgICA+Pj4+DQo+ICAgICAg Pj4+Pg0KPiAgICAgID4+Pj4+IFRoZSB3YXkgdGhpcyBsYW5ndWFnZSByZWFkcyB0byBtZSBpcyB0 aGF0IGVuZHBvaW50cyBjYW4gcmV1c2UgdGhlDQo+ICAgICAgPj4+Pj4gZXhpc3RpbmcNCj4gICAg ICA+Pj4+IGFzc29jaWF0aW9uIGlmIHRoZXkgd2FudCB0bywgYnV0IHRoZXkgY2FuIGNyZWF0ZSBh IG5ldyBvbmUgaWYgdGhleQ0KPiAgICAgID4+Pj4gZG9uJ3QuIEFsc28sIHdoZW4gdGhpcyBuZXcN Cj4gICAgICA+Pj4+PiBhc3NvY2lhdGlvbiBpcyBjcmVhdGVkLCBpdCBpcyB1bmNsZWFyIGlmIG9s ZCBzZXR1cCByb2xlcyBNVVNUIGJlDQo+ICAgICAgPj4+Pj4gcHJlc2VydmVkDQo+ICAgICAgPj4+ PiBvciBpZiB0aGV5IE1VU1QgYmUgc2VsZWN0ZWQgYmFzZWQgb24gdGhlIGN1cnJlbnQgb2ZmZXIv YW5zd2VyDQo+ICAgICAgPj4+PiBleGNoYW5nZS4gSXQgc2VlbXMgdGhlIGN1cnJlbnQNCj4gICAg ICA+Pj4+PiBzcGVjaWZpY2F0aW9uIGxhbmd1YWdlIGlzIG5vdCBzdHJvbmcgb3IgY2xlYXIgZW5v dWdoIG9uIHRoaXMNCj4gICAgICA+Pj4+PiB0b3BpYy4NCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+ PiBJbiBteSBvcGluaW9uLCBJRiBhIG5ldyBEVExTIGNvbm5lY3Rpb24gbmVlZHMgdG8gYmUgZXN0 YWJsaXNoZWQNCj4gICAgICA+Pj4+IChmb3Igd2hhdGV2ZXIgcmVhc29ucyksIHRoZSBjdXJyZW50 IHJvbGVzIHNob3VsZCBiZSB1c2VkLg0KPiAgICAgID4+Pg0KPiAgICAgID4+PiA8UmFqdT4gV2hl biBJQ0UgaXMgTk9UIHVzZWQsIGhvdyBkb2VzIHRoZSBvZmZlcmVyIGtub3cgdGhhdCB0aGUNCj4g ICAgICA+Pj4gYW5zd2VyZXIgZG9lcyBub3QgY2hhbmdlIHRoZSBmaW5nZXJwcmludCBhbmQvb3Ig dHJhbnNwb3J0DQo+ICAgICBwYXJhbWV0ZXJzPw0KPiAgICAgID4+PiBJIGd1ZXNzIGl0IGRvZXMg bm90IGtub3cuIFNvLCBvZmZlcmVyIGhhcyB0byBiZSBwcmVwYXJlZCBmb3INCj4gICAgIG5ldyBE VExTDQo+ICAgICAgPj4+IGFzc29jaWF0aW9uIGJ5IG9mZmVyaW5nIGFjdHBhc3MuIFdoZW4gSUNF IGlzIHVzZWQsIHRoZSBhbnN3ZXJlcg0KPiAgICAgY2FuJ3QNCj4gICAgICA+Pj4gY2hhbmdlIHRy YW5zcG9ydCBwYXJhbWV0ZXIgdW5sZXNzIG9mZmVyZXIgZG9lcyBJQ0UgcmVzdGFydCAod2hpY2gN Cj4gICAgICA+Pj4gY2hhbmdlcyBvZmZlcmVyIHRyYW5zcG9ydCBwYXJhbWV0ZXJzKTsgUmVmIFsx XSBpcyB2ZXJ5IGNsZWFyIG9uDQo+ICAgICB0aGlzDQo+ICAgICAgPj4+IGluZGljYXRpbmcgIkRU TFMgaGFuZHNoYWtlIHByb2NlZHVyZSBpcyByZXBlYXRlZCIuIEhvd2V2ZXIsDQo+ICAgICBldmVu IHdoZW4NCj4gICAgICA+Pj4gSUNFIGlzIHVzZWQsIEkgZG8gbm90IGZpbmQgYW55IHJlc3RyaWN0 aW9uIGFib3V0IGFuc3dlcmVyIG5vdA0KPiAgICAgID4+PiBjaGFuZ2luZyBmaW5nZXJwcmludC4g U28sIGV2ZW4gd2l0aG91dCBJQ0UgcmVzdGFydCBhbnN3ZXJlciBjYW4NCj4gICAgICA+Pj4gdHJp Z2dlciBhIERUTFMgcmVuZWdvdGlhdGlvbiBieSBjaGFuZ2luZyBpdHMgZmluZ2VycHJpbnQuDQo+ ICAgICAgPj4+DQo+ICAgICAgPj4+IFRvIGNvbmNsdWRlIGFsbCB0aGlzLCBJTU8gd2hldGhlciBJ Q0UgaXMgdXNlZCBvciBub3QsIHNlbmRpbmcNCj4gICAgIGFjdHBhc3MNCj4gICAgICA+Pj4gZm9y IGFsbCBuZXcgb2ZmZXJzIG1heSBiZSBjb3ZlciBhbGwgcG9zc2libGUgc2NlbmFyaW9zLg0KPiAg ICAgID4+DQo+ICAgICAgPj4gVGhhdCBpcyBhbHNvIG15IGNvbmNsdXNpb24gYmFzZWQgb24gdGhl IGRpc2N1c3Npb24gc28gZmFyLg0KPiAgICAgID4+DQo+ICAgICAgPj4gSSBhbHNvIHRoaW5rIHRo ZSBKU0VQIGRyYWZ0IGFzIGZhciBhcyBkZXRhaWxlZCBvdXQgaXMgY29ycmVjdCwNCj4gICAgIGJ1 dCBpbmZvDQo+ICAgICAgPj4gYWJvdXQgaG93IHRoZSBpbXBsZW1lbnRhdGlvbiBzaG91bGQgYmVo YXZlIGZvciBTdWJzZXF1ZW50IGFuc3dlcnMgaXMNCj4gICAgICA+PiBtaXNzaW5nLiBUZXh0IHNh eWluZyB0aGF0IHRoZSByb2xlIG11c3QgYmUgbWFpbnRhaW5lZCAodW5sZXNzDQo+ICAgICB0aGVy ZSBpcw0KPiAgICAgID4+IGFuIElDRSByZXN0YXJ0KSBzaG91bGQgYmUgcHV0IGluIHRoZXJlLg0K PiAgICAgID4NCj4gICAgICA+IDxSYWp1Pg0KPiAgICAgID4gSGkgU3RlZmFuLA0KPiAgICAgID4g TG9va3MgbGlrZSwgdGhlcmUgaXMgc29tZSBtaXN1bmRlcnN0YW5kaW5nIGhlcmUuDQo+DQo+ICAg ICBQcm9iYWJseSBteSBmYXVsdCBpbiB0aGF0IGNhc2UgOikNCj4NCj4gICAgID4gTXkgY29uY2x1 c2lvbiBpcyB0byBpbmNsdWRlDQo+ICAgICA+IGFjdHBhc3MsIGJ1dCBub3QgdGhlIHByZXZpb3Vz bHkgbmVnb3RpYXRlZCByb2xlLCBpbiBhbGwgc3Vic2VxdWVudCBvZmZlcnMsDQo+ICAgICA+IG5v dCBqdXN0IGR1cmluZyBJQ0UtcmVzdGFydHMuDQo+DQo+ICAgICBJIHRoaW5rIHRoYXQgaXMgd2hh dCB0aGUgSlNFUCBkcmFmdCBzYXlzIC0gYW5kIG15IGNvbmNsdXNpb24gaXMgdGhhdCBpdA0KPiAg ICAgX2lzXyBjb3JyZWN0Lg0KPg0KPiAgICAgTXkgcG9pbnQgd2FzIHRoYXQgdGhlIF9hbnN3ZXJf IHNob3VsZCAod2hlbiBpdCBpcyBhIHN1YnNlcXVlbnQgYW5zd2VyKQ0KPiAgICAgc2hvdWxkIHNh eSB0aGUgc2FtZSByb2xlIGFzIGluIHByZXZpb3VzIGFuc3dlcnMgKHVubGVzcyB0aGVyZSBpcyBh biBJQ0UNCj4gICAgIHJlc3RhcnQpLg0KPg0KPiBJIGFncmVlIHRoZSBKU0VQIHRleHQgc2hvdWxk IGluZGljYXRlIHRoYXQgcm9sZXMgc2hvdWxkIHN0YXkgdGhlIHNhbWUuDQo+IFdlIGhhdmUgaGFk IHRoaXMgYXMgYSBUT0RPIGZvciBhIHdoaWxlOg0KPiBodHRwczovL2dpdGh1Yi5jb20vcnRjd2Vi LXdnL2pzZXAvaXNzdWVzLzcyDQoNCkdyZWF0LiBJIHNob3VsZCBoYXZlIGNoZWNrZWQgdGhhdCBv dXQgYmVmb3JlLg0KDQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B1D57A73EESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0Ii IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPlRoaXMgd291bGQgZ28gaW50byB0aGUgU0NUUC1TRFAgZHJhZnQuIFNvcnJ5IGZv ciBub3QgbWVudGlvbmluZyB0aGF0IDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBu YW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKdXN0aW4gVWJlcnRp IFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDA0IERlY2Vt YmVyIDIwMTQgMTg6NDc8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+ Q2M6PC9iPiBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJd IEpTRVA6IFdoeSBhbHdheXMgb2ZmZXIgYWN0cGFzcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Tb3JyeSwgd2hpY2ggZG9jdW1lbnQgd291bGQgdGhpcyBiZSBnb2luZyBp bnRvPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1 LCBEZWMgNCwgMjAxNCBhdCA1OjQyIEFNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldoYXQgYWJvdXQgdGhlIGZv bGxvd2luZyB0ZXh0Ojwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjguMy4yLiZuYnNwOyBUTFMgUm9sZSBEZXRlcm1pbmF0aW9uPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IElmIHRoZSBtLSBsaW5lIHByb3RvIGZpZWxk IHZhbHVlIGlzICdTQ1RQL0RUTFMnIG9yICdEVExTL1NDVFAnLCB0aGU8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgU0RQIHNldHVwIGF0dHJpYnV0ZSBb UkZDNDE0NV0gaXMgdXNlZCB0byBkZXRlcm1pbmUgdGhlICdhY3RpdmUvPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHBhc3NpdmUnIHN0YXR1cyBvZiB0 aGUgb2ZmZXJlciBhbmQgYW5zd2VyZXIuJm5ic3A7IFRoZSAnYWN0aXZlL3Bhc3NpdmUnPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHN0YXR1cyB3aWxs IGJlIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBUTFMgcm9sZXMsIGZvbGxvd2luZyB0aGU8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcHJvY2VkdXJlcyBp biBbUkZDNDU3Ml0gKHRoZSAnYWN0aXZlJyBlbmRwb2ludCB3aWxsIHRha2UgdGhlIFRMUyBjbGll bnQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcm9s ZSkuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IE9uY2UgYSBEVExTIGNv bm5lY3Rpb24gaGFzIGJlZW4gZXN0YWJsaXNoZWQsIGlmIHRoZSAnYWN0aXZlL3Bhc3NpdmUnPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHN0YXR1cyBv ZiB0aGUgZW5kcG9pbnRzIGNoYW5nZSBkdXJpbmcgYSBzZXNzaW9uLCBhIG5ldyBEVExTPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGNvbm5lY3Rpb24g TVVTVCBiZSBlc3RhYmxpc2hlZC4mbmJzcDsgVGhlcmVmb3JlLCBlbmRwb2ludHMgU0hPVUxEIE5P VDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBjaGFu Z2UgdGhlIOKAmGFjdGl2ZS9wYXNzaXZl4oCZIHN0YXR1cyBpbiBzdWJzZXF1ZW50IG9mZmVycyBh bmQgYW5zd2Vycyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgdW5sZXNzIHRoZXkgd2FudCB0byBlc3RhYmxpc2ggYSBuZXcgRFRMUyBjb25uZWN0aW9u IChpbiB3aGljaCBjYXNlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IHRoZSBuZXcgJ2FjdGl2ZS9wYXNzaXZlJyBzdGF0dXMgb2YgdGhlIG9mZmVyZXIg YW5kIGFuc3dlcmVyIHdpbGwgYmU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgdXNlZCB0byBkZXRlcm1pbmUgdGhlIFRMUyByb2xlcyBhc3NvY2lhdGVk IHdpdGggdGhlIG5ldyBEVExTPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IGNvbm5lY3Rpb24pLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyBOT1RFOiBUaGUgcHJvY2VkdXJlIGFib3ZlIGlzIGlkZW50aWNhbCB0byB0aGUgb25l IGRlZmluZWQgZm9yIFNSVFAtPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IERUTFMgaW4gW1JGQzU3NjNdLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy ZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IHJ0 Y3dlYg0KIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5DaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPlNlbnQ6PC9iPiA0LiBqb3VsdWt1dXRh IDIwMTQgODo1NTxicj4NCjxiPlRvOjwvYj4gSnVzdGluIFViZXJ0aTxicj4NCjxiPkNjOjwvYj4g PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBp ZXRmLm9yZzwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gSlNFUDogV2h5IGFsd2F5cyBvZmZl ciBhY3RwYXNzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SeKAmXZlIG1p c3NlZCB0aGF0LiBBd2Vzb21lISA6KTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvLCBpZiB3ZeKAmXJlIG9rIHdpdGgg dGhhdCBhcHByb2FjaCwgdGhlbiB3ZSBzaG91bGQgdXNlIHNpbWlsYXIgdGV4dCBpbiB0aGUgU0NU UC1TRFAgZHJhZnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBKdXN0aW4NCiBVYmVydGkg WzxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWls dG86anViZXJ0aUBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiA0LiBqb3VsdWt1 dXRhIDIwMTQgODo1Mzxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmc8YnI+DQo8Yj5D Yzo8L2I+IFN0ZWZhbiBIw6VrYW5zc29uIExLOyBNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUp OyBSb21hbiBTaHBvdW50OyA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+DQpydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb cnRjd2ViXSBKU0VQOiBXaHkgYWx3YXlzIG9mZmVyIGFjdHBhc3M/PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+NTc2MywgUyA2LjYgc2VlbXMg dG8gaW1wbHkgdGhhdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwO05vdGUgdGhhdCBpZiB0aGUgYWN0aXZlL3Bhc3NpdmUgc3RhdHVzIG9m IHRoZSBlbmRwb2ludHMgY2hhbmdlcywgYSBuZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDtjb25uZWN0aW9uIE1VU1QgYmUgZXN0YWJsaXNoZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj5PbiBXZWQsIERlYyAzLCAyMDE0IGF0IDEwOjMwIFBNLCBDaHJpc3RlciBIb2xt YmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlNvLCBvbmUgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBzYXkgdGhhdCwgSUYgb25l ICh0aGVyZSBvZmZlcmVyIG9yIGFuc3dlcmVyKSBjaGFuZ2VzIHRoZQ0KIHByZXZpb3VzbHkgbmVn b3RpYXRlZCByb2xlcywgdGhlIERUTFMgY29ubmVjdGlvbiBNVVNUIGJlIHJlLWVzdGFibGlzaGVk IOKAkyBldmVuIGlmIHRoZSB0cmFuc3BvcnQgcGFyYW1ldGVycyBldGMgYXJlbuKAmXQgY2hhbmdl ZC4gSSB0aGluayB0aGF0IHdvdWxkIGJlIGEgdmVyeSB1c2VmdWwgY2xhcmlmaWNhdGlvbi48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IEp1c3Rpbg0KIFViZXJ0aSBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5qdWJlcnRpQGdvb2ds ZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDQuIGpvdWx1a3V1dGEgMjAxNCA3OjQ5PGJy Pg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPkNjOjwvYj4gU3RlZmFuIEjD pWthbnNzb24gTEs7IE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSk7IFJvbWFuIFNocG91bnQ7 IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnJ0Y3dl YkBpZXRmLm9yZzwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBKU0VQOiBXaHkgYWx3YXlz IG9mZmVyIGFjdHBhc3M/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPkN1cnJlbnRseSwgQ2hyb21lIGVycm9ycyBvdXQgKGkuZS4gc2V0 UkQgZmFpbHMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5I b3dldmVyLCBJIHN1c3BlY3QgdGhhdCB0ZWFyZG93biBvZiB0aGUgb2xkIERUTFMgYXNzb2NpYXRp b24gYW5kIHNldHVwIG9mIGEgbmV3IERUTFMgYXNzb2NpYXRpb24gaXMgdGhlIGRlc2lyZWQgYmVo YXZpb3IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+T24gV2VkLCBEZWMgMywgMjAxNCBhdCA4OjM0IFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpLDxicj4NCjxicj4N Cklzc3VlICM3MiB0YWxrcyBhYm91dCBtYWludGFpbmluZyB0aGUgcHJldmlvdXNseSBuZWdvdGlh dGVkIHJvbGUgd2hlbiBhY3RwYXNzIGlzIHJlY2VpdmVkLiBJIHRoaW5rIHRoYXQgaXMgYSBnb29k IGFwcHJvYWNoLCBhbmQgY291bGQgYmUgdXNlZCBpbiBPZmZlci9BbnN3ZXIgdG9vLjxicj4NCjxi cj4NCkJVVCwgd2hhdCBkb2VzIHRoZSBicm93c2VyIGRvIGlmIGUuZy4gdGhlIHByZXZpb3VzIHJv bGUgaXMgcGFzc2l2ZSBhbmQgYWN0aXZlIGlzIHJlY2VpdmVkPzxicj4NCjxicj4NClJlZ2FyZHMs PGJyPg0KPGJyPg0KQ2hyaXN0ZXI8YnI+DQo8YnI+DQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9u ZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0 eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGhyIHNpemU9IjIi IHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbToNCjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRvOnN0ZWZhbi5say5o YWthbnNzb25AZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+U3RlZmFuIEjDpWthbnNzb24g TEs8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+U2VudDoNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+4oCOMDMv4oCOMTIv4oCOMjAxNCAxNzo0ODwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvOg0K PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJtYWlsdG86 anViZXJ0aUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+SnVzdGluIFViZXJ0aTwvYT48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5DYzoNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PGEgaHJlZj0ibWFpbHRvOlJhanUuTWFrYXJhanVAYWxjYXRlbC1sdWNlbnQuY29tIiB0YXJnZXQ9 Il9ibGFuayI+TWFrYXJhanUsIE1hcmlkaSBSYWp1IChSYWp1KTwvYT47DQo8YSBocmVmPSJtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Q2hyaXN0 ZXIgSG9sbWJlcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIiB0YXJn ZXQ9Il9ibGFuayI+Um9tYW4gU2hwb3VudDwvYT47IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnJ0Y3dlYkBpZXRmLm9yZzwvYT48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5TdWJqZWN0Og0KPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZTog W3J0Y3dlYl0gSlNFUDogV2h5IGFsd2F5cyBvZmZlciBhY3RwYXNzPzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij5PbiAwMS8xMi8xNCAxODoyNiwgSnVzdGluIFViZXJ0aSB3cm90ZTo8 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gU3VuLCBOb3YgMzAsIDIwMTQgYXQgNzoy NiBBTSwgU3RlZmFuIEjDpWthbnNzb24gTEs8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5zdGVmYW4u bGsuaGFrYW5zc29uQGVyaWNzc29uLmNvbTwvYT48YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWls dG86c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWls dG86c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJy Pg0KJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT24gMzAvMTEvMTQgMTY6 MDYsIE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkgd3JvdGU6PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBPbiAzMC8xMS8xNCAxNDo1MSwgTWFrYXJh anUsIE1hcmlkaSBSYWp1IChSYWp1KSB3cm90ZTo8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgSGksPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUkZDIDczNDUgKFVEUFRM LURUTFMpIHNheXMgdGhlIGZvbGxvd2luZzo8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZxdW90O09uY2UgYW4g b2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIGhhcyBiZWVuIGNvbXBsZXRlZCwgZWl0aGVyPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg ZW5kcG9pbnQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsgTUFZPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VuZCBhIG5ldyBvZmZlciBpbiBvcmRlciB0byBtb2RpZnkg dGhlIHNlc3Npb24uJm5ic3A7IFRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGVuZHBvaW50czxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBjYW48YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZXVz ZSB0aGUgZXhpc3RpbmcgRFRMUyBhc3NvY2lhdGlvbiBpZiB0aGUga2V5IGZpbmdlcnByaW50PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgdmFsdWVzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7IGFuZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRyYW5zcG9ydCBwYXJhbWV0ZXJzIGluZGljYXRlZCBi eSBlYWNoIGVuZHBvaW50IGFyZSB1bmNoYW5nZWQuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT3RoZXJ3aXNlLCBmb2xsb3dp bmcgdGhlIHJ1bGVzIGZvciB0aGUgaW5pdGlhbCBvZmZlci9hbnN3ZXI8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgZXhjaGFuZ2UsPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgdGhlIGVuZHBvaW50cyBjYW4gbmVnb3RpYXRlIGFuZCBjcmVhdGUgYSBuZXcgRFRMUyBhc3Nv Y2lhdGlvbjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGFuZCwgb25jZSBjcmVhdGVkLCBkZWxldGUgdGhlIHByZXZpb3VzIERU TFMgYXNzb2NpYXRpb24sPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZm9sbG93aW5nIHRoZSBzYW1lIHJ1bGVzIGZvciB0aGUg aW5pdGlhbCBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRWFjaCBlbmRwb2ludCBuZWVk cyB0byBiZSBwcmVwYXJlZCB0byByZWNlaXZlIGRhdGEgb24gYm90aCB0aGU8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBuZXcg YW5kIG9sZCBEVExTIGFzc29jaWF0aW9ucyBhcyBsb25nIGFzIGJvdGggYXJlIGFsaXZlLiZxdW90 Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgU28sIEkgZ3Vlc3MgdGhhdCBjYW4gYmUgcmVhZCBpbiBhIHdheSB0 aGF0IHRoZSBzZXR1cCBhdHRyaWJ1dGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhcyBzdWNoPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IGRvZXMgbm90IGltcGFjdCBw cmV2aW91c2x5PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgbmVnb3RpYXRlZCBUTFMgcm9sZXMgLSB1bmxlc3MgdGhlIGtleSBm aW5nZXJwcmludCB2YWx1ZXMgYW5kL29yPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdHJhbnNwb3J0PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IHBhcmFtZXRlcnMgYXJl IG1vZGlmaWVkLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIFNDVFAtU0RQIGRyYWZ0IGN1cnJlbnRseSBz YXlzIHRoYXQgYSBzdWJzZXF1ZW50IG9mZmVyIG11c3Q8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBub3QgY2hhbmdlPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBw cmV2aW91c2x5IG5lZ290aWF0ZWQgcm9sZXMuIEJ1dCwgSSBndWVzczxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdlIGNvdWxk IHNheSBzb21ldGhpbmcgc2ltaWxhciBhcyBpbiBSRkMgNzM0NS48YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGhhdmUgc3Ry dWdnbGVkIHdpdGggdGhpcyBsYW5ndWFnZSBxdWl0ZSBhIGJpdCBmcm9tIHRoZTxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW1wbGVt ZW50YXRpb248YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsgcGVyc3BlY3RpdmUuIEkgdGhpbmsgd2UgbmVlZCB0byBleHBsaWNpdGx5IHN0YXRl PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyB0aGF0IGVuZHBvaW50cyBNVVNUIHJldXNlIHRoZSBleGlzdGluZyBhc3NvY2lhdGlvbiBp ZiB0aGUga2V5PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBmaW5nZXJwcmludDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyB2YWx1ZXMgYW5kIHRyYW5zcG9ydCBwYXJhbWV0ZXJz IGluZGljYXRlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgYnkgZWFjaCBlbmRwb2ludCBhcmUgdW5jaGFuZ2VkLjxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBXZSBjb3VsZCB0 YWtlIHN1Y2ggZ2VuZXJhbCBhcHByb2FjaC48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgSG93ZXZlciwgZm9yICdTQ1RQL0RUTFMnIChEVExT IG92ZXIgU0NUUCksIEkgYXNzdW1lIHRoYXQgdGhlIERUTFM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgY29ubmVjdGlvbiB3aWxsIGFsc28g YmUgcmUtZXN0YWJsaXNoZWQgaWYgdGhlIHVuZGVybHlpbmcgU0NUUDxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBhc3NvY2lhdGlvbiBpcyBy ZS0gZXN0YWJsaXNoZWQgLSBldmVuIGlmIG5vIHRyYW5zcG9ydCBwYXJhbWV0ZXJzPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IGV0YyBhcmUg Y2hhbmdlZC48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsgQWxzbywgUkZDIDYwODMgc2F5czo8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7RWFjaCBEVExTIGNvbm5lY3Rpb24g TVVTVCBiZSBlc3RhYmxpc2hlZCBhbmQgdGVybWluYXRlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgd2l0aGluIHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBzYW1lIFNDVFAgYXNzb2NpYXRpb24uJnF1b3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBU aGUgd2F5IHRoaXMgbGFuZ3VhZ2UgcmVhZHMgdG8gbWUgaXMgdGhhdCBlbmRwb2ludHMgY2FuIHJl dXNlIHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgZXhpc3Rpbmc8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsgYXNzb2NpYXRpb24gaWYgdGhleSB3YW50IHRvLCBidXQgdGhl eSBjYW4gY3JlYXRlIGEgbmV3IG9uZSBpZiB0aGV5PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IGRvbid0LiBBbHNvLCB3aGVuIHRoaXMgbmV3 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBhc3NvY2lhdGlvbiBpcyBjcmVhdGVkLCBpdCBpcyB1bmNsZWFyIGlmIG9sZCBzZXR1cCBy b2xlcyBNVVNUIGJlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBwcmVzZXJ2ZWQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgb3IgaWYgdGhleSBNVVNUIGJlIHNlbGVjdGVkIGJh c2VkIG9uIHRoZSBjdXJyZW50IG9mZmVyL2Fuc3dlcjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyBleGNoYW5nZS4gSXQgc2VlbXMgdGhlIGN1 cnJlbnQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHNwZWNpZmljYXRpb24gbGFuZ3VhZ2UgaXMgbm90IHN0cm9uZyBvciBjbGVhciBl bm91Z2ggb24gdGhpczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgdG9waWMuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IEluIG15IG9waW5pb24sIElGIGEgbmV3IERUTFMgY29u bmVjdGlvbiBuZWVkcyB0byBiZSBlc3RhYmxpc2hlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyAoZm9yIHdoYXRldmVyIHJlYXNvbnMpLCB0 aGUgY3VycmVudCByb2xlcyBzaG91bGQgYmUgdXNlZC48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7ICZsdDtSYWp1Jmd0OyBXaGVuIElDRSBpcyBOT1QgdXNl ZCwgaG93IGRvZXMgdGhlIG9mZmVyZXIga25vdyB0aGF0IHRoZTxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IGFuc3dlcmVyIGRvZXMgbm90IGNoYW5n ZSB0aGUgZmluZ2VycHJpbnQgYW5kL29yIHRyYW5zcG9ydDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgcGFyYW1ldGVycz88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBJIGd1ZXNzIGl0IGRvZXMgbm90IGtub3cuIFNvLCBvZmZlcmVy IGhhcyB0byBiZSBwcmVwYXJlZCBmb3I8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG5ldyBEVExTPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDsgYXNzb2NpYXRpb24gYnkgb2ZmZXJpbmcgYWN0cGFzcy4gV2hlbiBJQ0UgaXMgdXNlZCwg dGhlIGFuc3dlcmVyPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjYW4ndDxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IGNoYW5nZSB0 cmFuc3BvcnQgcGFyYW1ldGVyIHVubGVzcyBvZmZlcmVyIGRvZXMgSUNFIHJlc3RhcnQgKHdoaWNo PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgY2hh bmdlcyBvZmZlcmVyIHRyYW5zcG9ydCBwYXJhbWV0ZXJzKTsgUmVmIFsxXSBpcyB2ZXJ5IGNsZWFy IG9uPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGlzPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgaW5kaWNhdGluZyAmcXVvdDtE VExTIGhhbmRzaGFrZSBwcm9jZWR1cmUgaXMgcmVwZWF0ZWQmcXVvdDsuIEhvd2V2ZXIsPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBldmVuIHdoZW48YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBJQ0UgaXMgdXNlZCwgSSBkbyBub3Qg ZmluZCBhbnkgcmVzdHJpY3Rpb24gYWJvdXQgYW5zd2VyZXIgbm90PGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgY2hhbmdpbmcgZmluZ2VycHJpbnQu IFNvLCBldmVuIHdpdGhvdXQgSUNFIHJlc3RhcnQgYW5zd2VyZXIgY2FuPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgdHJpZ2dlciBhIERUTFMgcmVu ZWdvdGlhdGlvbiBieSBjaGFuZ2luZyBpdHMgZmluZ2VycHJpbnQuPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBUbyBjb25jbHVkZSBhbGwgdGhpcywgSU1P IHdoZXRoZXIgSUNFIGlzIHVzZWQgb3Igbm90LCBzZW5kaW5nPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBhY3RwYXNzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7Jmd0OyZndDsgZm9yIGFsbCBuZXcgb2ZmZXJzIG1heSBiZSBjb3ZlciBhbGwgcG9z c2libGUgc2NlbmFyaW9zLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 IFRoYXQgaXMgYWxzbyBteSBjb25jbHVzaW9uIGJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uIHNvIGZh ci48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBJIGFsc28gdGhpbmsg dGhlIEpTRVAgZHJhZnQgYXMgZmFyIGFzIGRldGFpbGVkIG91dCBpcyBjb3JyZWN0LDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnV0IGluZm88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IGFib3V0IGhvdyB0aGUgaW1wbGVtZW50YXRpb24g c2hvdWxkIGJlaGF2ZSBmb3IgU3Vic2VxdWVudCBhbnN3ZXJzIGlzPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBtaXNzaW5nLiBUZXh0IHNheWluZyB0aGF0 IHRoZSByb2xlIG11c3QgYmUgbWFpbnRhaW5lZCAodW5sZXNzPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB0aGVyZSBpczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsgYW4gSUNFIHJlc3RhcnQpIHNob3VsZCBiZSBwdXQgaW4gdGhlcmUuPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7ICZsdDtSYWp1Jmd0Ozxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBIaSBTdGVmYW4sPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IExvb2tzIGxpa2UsIHRoZXJlIGlzIHNvbWUg bWlzdW5kZXJzdGFuZGluZyBoZXJlLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFByb2JhYmx5IG15IGZhdWx0IGluIHRoYXQgY2FzZSA6KTxicj4NCiZndDs8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgTXkgY29uY2x1c2lvbiBpcyB0byBp bmNsdWRlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGFjdHBhc3MsIGJ1 dCBub3QgdGhlIHByZXZpb3VzbHkgbmVnb3RpYXRlZCByb2xlLCBpbiBhbGwgc3Vic2VxdWVudCBv ZmZlcnMsPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IG5vdCBqdXN0IGR1 cmluZyBJQ0UtcmVzdGFydHMuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgSSB0aGluayB0aGF0IGlzIHdoYXQgdGhlIEpTRVAgZHJhZnQgc2F5cyAtIGFuZCBteSBj b25jbHVzaW9uIGlzIHRoYXQgaXQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IF9p c18gY29ycmVjdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBN eSBwb2ludCB3YXMgdGhhdCB0aGUgX2Fuc3dlcl8gc2hvdWxkICh3aGVuIGl0IGlzIGEgc3Vic2Vx dWVudCBhbnN3ZXIpPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzaG91bGQgc2F5 IHRoZSBzYW1lIHJvbGUgYXMgaW4gcHJldmlvdXMgYW5zd2VycyAodW5sZXNzIHRoZXJlIGlzIGFu IElDRTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVzdGFydCkuPGJyPg0KJmd0 Ozxicj4NCiZndDsgSSBhZ3JlZSB0aGUgSlNFUCB0ZXh0IHNob3VsZCBpbmRpY2F0ZSB0aGF0IHJv bGVzIHNob3VsZCBzdGF5IHRoZSBzYW1lLjxicj4NCiZndDsgV2UgaGF2ZSBoYWQgdGhpcyBhcyBh IFRPRE8gZm9yIGEgd2hpbGU6PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20v cnRjd2ViLXdnL2pzZXAvaXNzdWVzLzcyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIu Y29tL3J0Y3dlYi13Zy9qc2VwL2lzc3Vlcy83MjwvYT48YnI+DQo8YnI+DQpHcmVhdC4gSSBzaG91 bGQgaGF2ZSBjaGVja2VkIHRoYXQgb3V0IGJlZm9yZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D57A73EESESSMB209erics_-- From nobody Thu Dec 4 09:47:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72461A1BB3; Thu, 4 Dec 2014 09:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64uiIzF-YvgY; Thu, 4 Dec 2014 09:47:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A057F1A1AD0; Thu, 4 Dec 2014 09:47:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141204174709.26945.65249.idtracker@ietfa.amsl.com> Date: Thu, 04 Dec 2014 09:47:09 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eLfx1PAduk4Z4aLkA5eHv8c_De4 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-09.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 17:47:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : STUN Usage for Consent Freshness Authors : Muthu Arul Mozhi Perumal Dan Wing Ram Mohan Ravindranath Tirumaleswar Reddy Martin Thomson Filename : draft-ietf-rtcweb-stun-consent-freshness-09.txt Pages : 9 Date : 2014-12-04 Abstract: To prevent sending excessive traffic to an endpoint, periodic consent needs to be obtained from that remote endpoint. This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage. This same mechanism can also determine connection loss ("liveness") with a remote peer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 4 10:32:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB00C1A1B98 for ; Thu, 4 Dec 2014 10:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYMPkWlSiYp0 for ; Thu, 4 Dec 2014 10:32:19 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0E021A1B7E for ; Thu, 4 Dec 2014 10:32:19 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id E26F77EE751A7; Thu, 4 Dec 2014 18:32:12 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id sB4IWFfH014834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 13:32:15 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 13:32:15 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= , Justin Uberti Thread-Topic: [rtcweb] JSEP: Why always offer actpass? Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAH1cz+AAAO23YAAA7gjEA== Date: Thu, 4 Dec 2014 18:32:14 +0000 Message-ID: References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE2BC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577322@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577B77@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577CB5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D578C4D@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE9AC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D578E30@ESESSMB209.ericsson.se> <1447FA0C20ED5147A1AA0EF02890A64B1D0EEA4E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D57A684@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D57A684@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cTbAiELSdV3-dmCH1uMIViqNWAI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Why always offer actpass? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 18:32:21 -0000 =20 > Of course, if the fingerprint and/or transport parameters change, a new D= TLS > connections MUST be established. And, in that case I guess it doesn't mat= ter > if the TLS roles are also re-negotiated? Especially for transport parameter changes (in SDP answer), it could be a d= ifferent entity now doing the negotiation and needs fresh renegotiation of = roles. BR Raju From nobody Thu Dec 4 11:17:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC2B1A00AD for ; Thu, 4 Dec 2014 11:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS7xiwvmvkap for ; Thu, 4 Dec 2014 11:17:23 -0800 (PST) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13FE91A0079 for ; Thu, 4 Dec 2014 11:17:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417720642; x=2281634242; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8CMHdUM8Z7kx3tqcFEFOyCdrxa9wWo7HPSOryyObDks=; b=Av0OWrz1seTjBsu1T3cK7IGcZ+AP6AhT1SXwU5YfM9vYVffrwxqQru0IwUT40BOY 6FmgXGNjv2wLoN2V15tjC45ySUwvbYOQW+Jepw0Db+h/IzUD5AWpBM/bARMREfZf Hdz1rDITFZpFNLZV1eE39dvwngaZhLduUYe7wgRJxwOHAIy6QCNPAajAB2/cPt0/ jdqsbbuce/wGiCCYq5dI/QAM/O3i5Jzt2rAkBsl9fpw5GcfN3fsrxxzA8OOhRqBo nH312qGc3G8DYCKN27MWsiyPQxrXW6ws1dMwSfisdNkteXfv0vqEJUkXC6O5ZLtA AIKBMvMkc1PqQ+ulU72+aw==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id FD.1C.26546.243B0845; Thu, 4 Dec 2014 11:17:22 -0800 (PST) X-AuditID: 11973e11-f79af6d0000067b2-ae-5480b342d49c Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id F6.27.06123.443B0845; Thu, 4 Dec 2014 11:17:24 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG200273O8YQP60@marigold.apple.com> for rtcweb@ietf.org; Thu, 04 Dec 2014 11:17:22 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <20141204145138.GH10449@hex.shelbyville.oz> Date: Thu, 04 Dec 2014 11:17:21 -0800 Content-transfer-encoding: quoted-printable Message-id: <15016A8B-67BA-40B8-9273-F8CEEBB6869C@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204145138.GH10449@hex.shelbyville.oz> To: Ron X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FAYoeu0uSHE4NE8LYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcXbnD8aCDp6KR6f+MTYwnufsYuTkkBAwkVjbPYEdwhaTuHBv PVsXIxeHkMBeRomJfdeZYYp+XbkHlZjEJPHyZhszhDOfSeLprEamLkYODmYBdYkpU3JBGngF 9CSanjxmArGFBSIkjnSeAdvAJqAq8WDOMUYQm1PAQmLPuRWsIDYLUHz9rf1gcWYBYYnvj++x QNjaEk/eXWCFmGkj8W3Jb3aIvScZJTrvPgVbICIgIfHm/WOoS2Ul/l08A1YkIfCWVeLW4t2M ExiFZyHcNwvJfbOQ7FjAyLyKUSg3MTNHNzPPSC+xoCAnVS85P3cTIyiQp9sJ7mA8vsrqEKMA B6MSD2/h7voQIdbEsuLK3EOM0hwsSuK8bPUNIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY KzLW7jYMZ72VFB74d6N/g/fNgyZh9xJ9ypuZeR8tbpkQ6nSyXPSU+aGuI++LP/6bqmv5JT3q DPMtjjsHLrfK+x5cLCSz8WSfM3td5va7vhuik53OWhx2+cB/v3Vl09WM8Nz9Df96Ojczb5v9 w800V/KeYmPSxZ2vw3t0tzVYn24+cPtlYTC3EktxRqKhFnNRcSIAgMd3PUUCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcouuyuSHE4NQkeYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcXbnD8aCDp6KR6f+MTYwnufsYuTkkBAwkfh15R4bhC0mceHe eiCbi0NIYBKTxMubbcwQznwmiaezGpm6GDk4mAXUJaZMyQVp4BXQk2h68pgJxBYWiJA40nmG HcRmE1CVeDDnGCOIzSlgIbHn3ApWEJsFKL7+1n6wOLOAsMT3x/dYIGxtiSfvLrBCzLSR+Lbk NzvE3pOMEp13n4ItEBGQkHjz/jEzxKWyEv8unmGfwCgwC+GkWUhOmoVk7AJG5lWMAkWpOYmV pnqJBQU5qXrJ+bmbGMGBVxixg/H/MqtDjAIcjEo8vAW760OEWBPLiitzDzFKcDArifCeWNcQ IsSbklhZlVqUH19UmpNafIhRmoNFSZy3KhuoWiA9sSQ1OzW1ILUIJsvEwSnVwLhm3qmv8hys hj2fFs44kTqJO2yzfNvE2wwzgoXFbj8V8FCIyJFLbCzcKDffTzPQttLsoa/uFvVXIWxhb+45 R7Rq5foyiy1afFvXV3SLzETj8uTSKM4900ITd/8x07u5UvTjzVnZ1vu/q3RtmBxvVdLvqPp8 4gdPJctFHAeEn1VYvPNeGyYho8RSnJFoqMVcVJwIAAGC+9I4AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bFylXQlDm7km1hfqi5FXLFkt6oc Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 19:17:24 -0000 > On Dec 4, 2014, at 6:51 , Ron wrote: >=20 > On Wed, Dec 03, 2014 at 10:33:04AM -0800, David Singer wrote: >>=20 >> Consider finally: a small company for whom WebRTC is important. >>=20 >> Let=E2=80=99s look at the choices: >>=20 >> 1. Follow the mandate, implement VP8, and risk a ruinous lawsuit = from Nokia. >>=20 >> 2. Reject the mandate, do not implement VP8, and be formally = therefore not conformant and therefore not in receipt of a license from = company X; risk a ruinous lawsuit from X. >>=20 >> 3. Do not implement WebRTC, and risk a ruinous loss of relevance. >=20 > This seems more like a hypothetical small strawman than a situation > that any *real* small company has expressed to this group. >=20 > Your concern for small operators is heartwarming, but I think if you > consult the list archives to see what such people have actually said > for themselves, the only ruinous legal barrier that Nokia appears to > have them worried about is the IPR it holds on H.264 that is outside > the pool MPEG-LA operates, with no clear guarantee of its terms. >=20 > And we *still* don't have an IPR statement from them about this. > How many times should we need to ask them to respect the IETF process? I=E2=80=99m sorry, is H.264 a specification in progress at the IETF? You = will find declarations from them at ISO, IEC, and ITU, I think. They = state (as I recall) RAND. (Not =E2=80=9Cunwilling to license=E2=80=9D.) David Singer Manager, Software Standards, Apple Inc. From nobody Thu Dec 4 11:25:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F651A0143 for ; Thu, 4 Dec 2014 11:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5I4MgoHCcFk for ; Thu, 4 Dec 2014 11:25:49 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33041A00AD for ; Thu, 4 Dec 2014 11:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417721149; x=2281634749; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lyyGKVQgjMPE/coM/iOGvWDtyQ8gJJjYahBQ5lonQ9M=; b=dnsigqTumPphVVsrR3JhVUtoNBTK+fhVWCwfZHcOXEy3DZG88uVAwvYoKv+YwQvQ LSe2+klovqwj+U9WrEgfSz5et6ivYKDqNRLyw4HnPZcmynfRlPDpS2m+96KslAme NVxf8Hw26HSLJPFOyucN5pfPKa/dKJCiLIX8UN7Dt4mlkbnSzhd9pmWJtP2TabL1 hSO8lCUw1GdkLGFo7vcpBBHQtIJplJVcAAAp3Tl1/Dk4A6FURcktySvTep4MJTm2 MhgmaV6MccVbdYxYnu5NHdIQA6pwBblnoQky/O/xtgfGRvX/ExekjWPgcru1NY4w EeI1LDCQ6AG6yGTuamnNew==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id EC.0C.12074.D35B0845; Thu, 4 Dec 2014 11:25:49 -0800 (PST) X-AuditID: 11973e12-f79f86d000002f2a-5b-5480b53d6e85 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id A5.C3.06091.E15B0845; Thu, 4 Dec 2014 11:25:18 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG200HTLON0G580@marigold.apple.com> for rtcweb@ietf.org; Thu, 04 Dec 2014 11:25:49 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: Date: Thu, 04 Dec 2014 11:25:48 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> To: Silvia Pfieffer X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUi2FCYqmu7tSHEYOEUSYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMXn+B9aC1SwVnfOPMTcw7mTuYuTgkBAwkdjanNzFyAlkiklc uLeerYuRi0NIYB+jxP5PP1khEiYSjy8fZoJITGKS2HLoMSOEM59JYtuhF6wgk5gF1CWmTMkF aeAV0JNoevKYCcQWFoiQONJ5hh3EZhNQlXgw5xgjiM0pECwxr2MiE0grC1D8xHQLkDCzgK/E s5OPmCFsbYkn7y6wQoy0keiYtpANxBYSuMck8fWKPYgtIqAvsWzPIXaIO2Ul/l0EWcUFZH9k ldh+4TP7BEbhWQjXzUJy3SwkKxYwMq9iFMpNzMzRzcwz0UssKMhJ1UvOz93ECArh6XZCOxhP rbI6xCjAwajEw1uwuz5EiDWxrLgy9xCjNAeLkjgvW31DiJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQbGxmz1gp9C/THbvrr47xV3T78rmROy9eu7Ql42ZbVnTR/EiybONH+4RLyWSUd1xX6z M1MnqL+wuPyj61Eex1fJyLmzs68tN26vWuL+barI0gMztKYvv78ssNrrs/Tqt7Onp2lNueyl NtFzBsNOKSX75T+mLDnhafbW2oenWHXyzslF6518HuiwK7EUZyQaajEXFScCAIoOkatCAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FDcoiu3tSHE4N5PBYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMXn+B9aC1SwVnfOPMTcw7mTuYuTkkBAwkXh8+TAThC0mceHe erYuRi4OIYFJTBJbDj1mhHDmM0lsO/SCtYuRg4NZQF1iypRckAZeAT2JpiePwZqFBSIkjnSe YQex2QRUJR7MOcYIYnMKBEvM65jIBNLKAhQ/Md0CJMws4Cvx7OQjZghbW+LJuwusECNtJDqm LWQDsYUE7jFJfL1iD2KLCOhLLNtziB3iTlmJfxfPsE9gFJiFcNAsJAfNQjJ1ASPzKkaBotSc xEpzvcSCgpxUveT83E2M4KArTN3B2Ljc6hCjAAejEg+v5M76ECHWxLLiytxDjBIczEoivCfW NYQI8aYkVlalFuXHF5XmpBYfYpTmYFES543KBqoWSE8sSc1OTS1ILYLJMnFwSjUw9qSfKtqQ 4GTgsKCnMf5Y1+Hzdfa330qcW55+TOXvi7r5C5S5XcVvpUR+Ea5SFnv922NjtcXtCJ0zLtXB mw/9/SXrxnSO25hjwk19pVLjmJ8vHQ1sfZOYDmyblHFKe8e3hlMJezdNdfTJOllh9vZ9J9vJ XO9IhvIz61ozpv35eGHNq1q2OA0/JZbijERDLeai4kQAOIgN7zYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Q6aBq0hkscarGgO0cJficwq56-w Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 19:25:51 -0000 > On Dec 3, 2014, at 21:16 , Silvia Pfeiffer = wrote: >=20 > Indeed, that's why I said point 1. in David's list doesn't make sense, = since he's talking about a small company getting sued by Nokia. So, your conclusion to my question is =E2=80=9CShip VP8, most of you = probably won=E2=80=99t get sued. Good luck. Try not to be too = successful or your luck may change.=E2=80=9D It is an answer; I don=E2=80=99t think it=E2=80=99s a good one, myself. David Singer Manager, Software Standards, Apple Inc. From nobody Thu Dec 4 11:30:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7C31A01D8 for ; Thu, 4 Dec 2014 11:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVZgYICIATNv for ; Thu, 4 Dec 2014 11:30:03 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 384321A016A for ; Thu, 4 Dec 2014 11:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=855; q=dns/txt; s=iport; t=1417721396; x=1418930996; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=f7K2ug02f0dvQlHWlYeCoOI7/XfVBDr4ezgpdnLL9V8=; b=agMRRsyB1INAkELIqRY7Dsc5xITCuT40QigvEAGmAkHkxLntooV/U7LP yrnvn/CZ/+NtD9a44XtPy/cvmCWnY4YpxHoPCdMNOOtMyPtFYwHBpcPfd Wjf0w4Vy/JseRmiVvI+PoKKwQyeDn7bEBfan3t9N1Y0g77/SmVCX0YmdY M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAMy1gFStJV2R/2dsb2JhbABZgmQigS7MZ4EhFgEBAQEBfYQJHR0/EgE+QicEDh+IJAHXOwEBAQEBAQEBAQEBAQEBAQEBAQEBGJAEEQFQgyuBHgWQEIpKgSODLYJyjFaDeYF7OYEAAQEB X-IronPort-AV: E=Sophos;i="5.07,517,1413244800"; d="scan'208";a="102755106" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP; 04 Dec 2014 19:29:55 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sB4JTrp9030245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 19:29:53 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 13:29:52 -0600 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: Call for adoption of draft-alvestrand-rtcweb-gateways Thread-Index: AQHQD/is2LdRMrUKckucyL6VrCW5HA== Date: Thu, 4 Dec 2014 19:29:52 +0000 Message-ID: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <36EF9A1E3AF0D342B7E351C080B06A82@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9yNd8faljM9TvpEM_w9HOqJBtGM Subject: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 19:30:06 -0000 Having reviewed the fine technical comments on this draft since we asked fo= r comments, the chairs have noted that multiple people seem to have read th= e draft. Given this great news we are going make a call for adoption.=20 If you have an opinion, please email the list by Dec 19 and let us know if = you either: A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG document= now B) no, not right now=20 If we get consensus around A we will work with ADs on milestone. Otherwise = we will encourage the authors to keep working on this draft and continue us= ing this email list. We may adopt it later or include the text in other dra= fts.=20 Thanks,=20 The Chairs (Cullen, Sean, Ted) PS - if you want to send an email that says more than A or B, feel free to = change the subject, start a new thread etc.=20 From nobody Thu Dec 4 12:11:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99971A1A82 for ; Thu, 4 Dec 2014 12:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R34kMTp7iATT for ; Thu, 4 Dec 2014 12:11:06 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6760D1A1A7C for ; Thu, 4 Dec 2014 12:10:09 -0800 (PST) Received: by mail-yk0-f179.google.com with SMTP id 19so8347093ykq.10 for ; Thu, 04 Dec 2014 12:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Tr0vJla4sMIkKcBYARr9gWYo5/VJ2mLsBbuvIcpJWyg=; b=tG23dstgW2jOLam4GySlAQKBU/RtOYgT6aIId3D7baEXyPSUj+nFWHaP6eed+59YEK hC1JaY/dYdkbFANHzQSbQ6DCovaNKOgV3h3P391/QH0wvzmhmpT/xcqsflMVZoW9EPdw qOZno0nGgv9hGMFINorAV9Yhox3UyaewomhxERfTcPu04fkeWcjF1lHgR3O/0Sezvokf 5pvSaRqCJ2TD/aLDAu12jaDyMNVHH1MlB3w8UkmDUehcRaEavQy5h3un0p0bEJKkNJIg 8q6Srs5EflFDpkxjB67RImaCmtdNfPMhX8w12ujjDHlXvNJps4uz9tQQDicN8E/uhOlF boug== MIME-Version: 1.0 X-Received: by 10.236.13.47 with SMTP id a35mr15912057yha.84.1417723808140; Thu, 04 Dec 2014 12:10:08 -0800 (PST) Received: by 10.170.135.193 with HTTP; Thu, 4 Dec 2014 12:10:08 -0800 (PST) Received: by 10.170.135.193 with HTTP; Thu, 4 Dec 2014 12:10:08 -0800 (PST) In-Reply-To: <20141204154326.5955730.32803.3228@blackberry.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> <20141204154326.5955730.32803.3228@blackberry.com> Date: Fri, 5 Dec 2014 07:10:08 +1100 Message-ID: From: Silvia Pfeiffer To: Andrew Allen Content-Type: multipart/alternative; boundary=001a11c3d570f953f20509698bfc Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JbLd1LNYUXY9TWsUSlHT1S54mD8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 20:11:14 -0000 --001a11c3d570f953f20509698bfc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There is no difference to h.264 in that respect. I still don't understand the fascination of big companies with perceived problems of small companies. What are you really trying to say? Best Regards, Silvia. On 5 Dec 2014 02:43, "Andrew Allen" wrote: > Silvia > > I think the risk for small companies is if they suddenly have a > successful product and have revenue that they then become a target. Plent= y > of cash flow to go after without the experience and resources to fight of= f > the lawsuit. > > My point was the fact that small companies may have implemented VP8 > without yet becoming engaged in a lawsuit does not prove that VP8 is RF. > > Andrew > > Sent from my BlackBerry 10 smartphone. > *From: *Silvia Pfeiffer > *Sent: *Wednesday, December 3, 2014 23:17 > *To: *Andrew Allen > *Cc: *David Singer; rtcweb@ietf.org > *Subject: *Re: [rtcweb] Finishing up the Video Codec document, MTI > (again, still, sorry) > > Indeed, that's why I said point 1. in David's list doesn't make sense, > since he's talking about a small company getting sued by Nokia. > S. > > On Thu, Dec 4, 2014 at 12:42 PM, Andrew Allen > wrote: > >> Silvia >> >> It is not usually the small companies that get sued in patent cases. >> Its companies with assets and significant revenues that get the lawsuits= . >> >> Nobody sues the penniless! - thats like suing the homeless! >> >> Andrew >> >> Sent from my BlackBerry 10 smartphone. >> *From: *Silvia Pfeiffer >> *Sent: *Wednesday, December 3, 2014 19:28 >> *To: *David Singer >> *Cc: *rtcweb@ietf.org >> *Subject: *Re: [rtcweb] Finishing up the Video Codec document, MTI >> (again, still, sorry) >> >> On Thu, Dec 4, 2014 at 5:33 AM, David Singer wrote: >> > As I understand it, the recent face to face meeting decided to draft >> the requirement that WebRTC browsers be required to implement both VP8 a= nd >> H.264, and get feedback on this, on the list. >> > >> > This is some feedback. >> > >> > >> > >> > I=E2=80=99d like to point out that this could easily place companies i= n an >> impossible position. >> > >> > Consider: it is not uncommon for IPR owners to grant a license (often >> free) only to =E2=80=98conforming implementations=E2=80=99. (A common ra= tionale is that >> they want to use their IPR to bring convergence and interoperability to = the >> industry). Let=E2=80=99s hypothesize that this happens, now or in futur= e, from >> Company X, for some IPR in the WebRTC specifications. >> > >> > Consider also: we have an =E2=80=9Cunwilling to license=E2=80=9D state= ment from Nokia >> on VP8, on the formal record (and including a long list of patents). >> > >> > Consider finally: a small company for whom WebRTC is important. >> > >> > >> > >> > Let=E2=80=99s look at the choices: >> > >> > 1. Follow the mandate, implement VP8, and risk a ruinous lawsuit from >> Nokia. >> > >> > 2. Reject the mandate, do not implement VP8, and be formally therefor= e >> not conformant and therefore not in receipt of a license from company X; >> risk a ruinous lawsuit from X. >> > >> > 3. Do not implement WebRTC, and risk a ruinous loss of relevance. >> >> >> I don't see the risk of 1. having changed because of the IETF's >> statement. Plenty of small companies are already doing 1. and have had >> to risk getting sued by Nokia at this point in time already. In fact, >> it's a risk that small companies always have to deal with since there >> is so much patented technology around that you invariable will step on >> something. I doubt very much that the IETF's decision has any impact >> on small business' risk in that space at all. >> >> >> > I do not think that the IETF should be placing anyone into the positio= n >> of having three extremely unpalatable choices. >> >> For a small company in the WebRTC space, 3. is a non-choice. 2. Is >> more of a business decision than an IP decision - which market are you >> trying to address? Are you trying to be interoperable with (current) >> browsers - then implement VP8. Are you trying to be interoperable with >> legacy devices - then implement H.264 (and probably even H.263). >> >> If you are trying to argue for a large company, the situation changes. >> However, as a large company, you tend to have an existing portfolio of >> patents. You're already playing the game of patents. As long as your >> hypothetical "IPR owners to grant a license only to =E2=80=98conforming >> implementations=E2=80=99" doesn't happen, you are free to choose 2. and = avoid >> Nokia. >> >> As for the threat in your option 2. - I can only see Google with IPR >> around VP8. Now, Google's IPR statement on WebM codecs, which includes >> VP8 and VP9 currently states: "Google hereby grants to you a >> perpetual, worldwide, non-exclusive, no-charge, royalty-free, >> irrevocable (except as stated in this section) patent license" >> http://www.webmproject.org/license/additional/ >> The word "perpetual" implies (to my non-lawyer eyes) that they can't >> suddenly change this to mean "only if you are conformant to the >> standard". So you can't be referring to such a risk associated with >> VP8 being created by Google. I don't know which other company you >> would want to be afraid of for your hypothetical threat in 2. Could >> you clarify? >> >> >> Best Regards, >> Silvia. >> >> >> > (Yes, I am aware that #2 is =E2=80=98unlikely=E2=80=99, but one day so= meone will decide >> that the =E2=80=9Conly to conformant implementations=E2=80=9D clause nee= ds to be real and >> enforced, and will do this; our hypothetical small company might prefer = not >> to be the example case.) >> > >> > (I use a small company as the example, because for them the risk is >> bankruptcy, but of course no-one likes to step into the path of trouble >> even if they have the resources to weather it.) >> > >> > Dave Singer >> > >> > singer@mac.com >> > >> > David Singer >> > Manager, Software Standards, Apple Inc. >> > >> > _______________________________________________ >> > 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 >> > > --001a11c3d570f953f20509698bfc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

There is no difference to h.264 in that respect. I still don= 't understand the fascination of big companies with perceived problems = of small companies. What are you really trying to say?

Best Regards,
Silvia.

On 5 Dec 2014 02:43, "Andrew Allen" &l= t;aallen@blackberry.com> wr= ote:
Silvia

I think the risk for small companies is if they suddenly have a successful = product and have revenue that they then become a target. Plenty of cash flo= w to go after without the experience and resources to fight off the lawsuit= .

My point was the fact that small companies may have implemented VP8 without= yet becoming engaged in a lawsuit does not prove =C2=A0that VP8 is RF.

Andrew

Sent from my BlackBerry 10 smartphone.
From: Silvia Pfeiffer
Sent: Wednesday, December 3, 2014 23:17
To: Andrew Allen
Cc: David Singer; rtcweb@ietf.org
Subject: Re: [rtcweb] Finishing up the Video Codec document, MT= I (again, still, sorry)

Indeed, that's why I said point 1. in David's list doesn't= make sense, since he's talking about a small company getting sued by N= okia.
S.

On Thu, Dec 4, 2014 at 12:42 PM, Andrew Allen <aallen@black= berry.com> wrote:
Silvia

It =C2=A0is not usually the small companies that get sued in patent cases. = Its companies with assets and significant revenues that get the lawsuits.

Nobody sues the=C2=A0=C2=A0penniless! - thats like suing the homeless!=
An= drew

Sent from my BlackBerry 10 smartphone.
From: Silvia Pfeiffer
Sent: Wednesday, December 3, 2014 19:28
To: David Singer
Subject: Re: [rtcweb] Finishing up the Video Codec document, MT= I (again, still, sorry)

On Thu, Dec 4, 2014 at 5:33 AM, David Singer <singer@apple.com> wrote:
> As I understand it, the recent face to face meeting decided to draft t= he requirement that WebRTC browsers be required to implement both VP8 and H= .264, and get feedback on this, on the list.
>
> This is some feedback.
>
>
>
> I=E2=80=99d like to point out that this could easily place companies i= n an impossible position.
>
> Consider: it is not uncommon for IPR owners to grant a license (often = free) only to =E2=80=98conforming implementations=E2=80=99. (A common ratio= nale is that they want to use their IPR to bring convergence and interopera= bility to the industry).=C2=A0 Let=E2=80=99s hypothesize that this happens, now or in future, from Company X, for some IPR in the WebRTC spec= ifications.
>
> Consider also: we have an =E2=80=9Cunwilling to license=E2=80=9D state= ment from Nokia on VP8, on the formal record (and including a long list of = patents).
>
> Consider finally: a small company for whom WebRTC is important.
>
>
>
> Let=E2=80=99s look at the choices:
>
> 1.=C2=A0 Follow the mandate, implement VP8, and risk a ruinous lawsuit= from Nokia.
>
> 2.=C2=A0 Reject the mandate, do not implement VP8, and be formally the= refore not conformant and therefore not in receipt of a license from compan= y X; risk a ruinous lawsuit from X.
>
> 3.=C2=A0 Do not implement WebRTC, and risk a ruinous loss of relevance= .


I don't see the risk of 1. having changed because of the IETF's
statement. Plenty of small companies are already doing 1. and have had
to risk getting sued by Nokia at this point in time already. In fact,
it's a risk that small companies always have to deal with since there is so much patented technology around that you invariable will step on
something. I doubt very much that the IETF's decision has any impact on small business' risk in that space at all.


> I do not think that the IETF should be placing anyone into the positio= n of having three extremely unpalatable choices.

For a small company in the WebRTC space, 3. is a non-choice. 2. Is
more of a business decision than an IP decision - which market are you
trying to address? Are you trying to be interoperable with (current)
browsers - then implement VP8. Are you trying to be interoperable with
legacy devices - then implement H.264 (and probably even H.263).

If you are trying to argue for a large company, the situation changes.
However, as a large company, you tend to have an existing portfolio of
patents. You're already playing the game of patents. As long as your hypothetical "IPR owners to grant a license only to =E2=80=98conformin= g
implementations=E2=80=99" doesn't happen, you are free to choose 2= . and avoid
Nokia.

As for the threat in your option 2. - I can only see Google with IPR
around VP8. Now, Google's IPR statement on WebM codecs, which includes<= br> VP8 and VP9 currently states: "Google hereby grants to you a
perpetual, worldwide, non-exclusive, no-charge, royalty-free,
irrevocable (except as stated in this section) patent license"
http://www.webmproject.org/license/additional/
The word "perpetual" implies (to my non-lawyer eyes) that they ca= n't
suddenly change this to mean "only if you are conformant to the
standard". So you can't be referring to such a risk associated wit= h
VP8 being created by Google. I don't know which other company you
would want to be afraid of for your hypothetical threat in 2. Could
you clarify?


Best Regards,
Silvia.


> (Yes, I am aware that #2 is =E2=80=98unlikely=E2=80=99, but one day so= meone will decide that the =E2=80=9Conly to conformant implementations=E2= =80=9D clause needs to be real and enforced, and will do this; our hypothet= ical small company might prefer not to be the example case.)
>
> (I use a small company as the example, because for them the risk is ba= nkruptcy, but of course no-one likes to step into the path of trouble even = if they have the resources to weather it.)
>
> Dave Singer
>
> singer@mac.com=
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
> _______________________________________________
> 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

--001a11c3d570f953f20509698bfc-- From nobody Thu Dec 4 12:15:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54421A1A97 for ; Thu, 4 Dec 2014 12:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5aT1qO2n1XB for ; Thu, 4 Dec 2014 12:15:40 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA691A1A95 for ; Thu, 4 Dec 2014 12:15:24 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id l18so23744454wgh.12 for ; Thu, 04 Dec 2014 12:15:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+wzGnvUT+wu9UQfjF50N6A0lDK4mPAyUkJUrh0AFqc8=; b=T5P2OLkGwi+J6gHIEFw2umkRz3URzt83WizmdlO6CaTZBBB2B/rNkDrehw+0c6MhZ/ 3XA0pndV/1Lfjb5na6yqNGdL9lhtJB1iPmupvVCBOyu44XY9roU5vdwaqLIBWv1sEjgQ 7FLZbI/j8yxAWEtfQ4bsgUUnQ6oVjttjdc7ABpQNh/5XNZSlqYCWJwRfE+LHpGJ0LIYs /e4e8vRELUcQ5GaFsrBy/ufalVNhIduPfJoY6Na+Mrr/jt9YCHsJlOIanJO6SNHHlh/w 0/igJB8VL/y1bn3C2YkBKpv1pB99DzIlWudUCbZsa240/O51T8mChhmbWVZJfyLH8iLL NPYg== X-Gm-Message-State: ALoCoQnSmHqPdMNGON3FFqgRqx7p11Ffi7jwYTxg1dsjxUP/Ch/5DtYqUx7WQYpm3OthGXDNnVtP X-Received: by 10.194.77.38 with SMTP id p6mr19122243wjw.50.1417724123396; Thu, 04 Dec 2014 12:15:23 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com. [74.125.82.49]) by mx.google.com with ESMTPSA id dg7sm42745378wib.24.2014.12.04.12.15.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 12:15:22 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id n12so15297360wgh.8 for ; Thu, 04 Dec 2014 12:15:22 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.92.116 with SMTP id cl20mr19074317wjb.71.1417724122116; Thu, 04 Dec 2014 12:15:22 -0800 (PST) Received: by 10.216.70.16 with HTTP; Thu, 4 Dec 2014 12:15:21 -0800 (PST) In-Reply-To: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> Date: Thu, 4 Dec 2014 15:15:21 -0500 Message-ID: From: Roman Shpount To: David Singer Content-Type: multipart/alternative; boundary=047d7bd910c2b03e1f0509699ef3 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MHcQwx3A-cPDF2FRek0oliRRVU0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 20:15:47 -0000 --047d7bd910c2b03e1f0509699ef3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David, The other answer is "Ship H.264. Most of you are going to get sued. Good luck settling." The risk associated with licensing H.264 is very high for any company who is not already part of this quagmire. There are enough problems there to hire an IPR law firm the second you look at H.264 and hope that they are professional enough and there is enough money to settle. I do understand that companies who are already stuck with H.264 would not want to be exposed to any additional IPR claims. There is also a little problem that if they implement VP8, they cannot sue any other VP8 implementers, or risk losing the VP8 IPR license. Being a small company, we had to go through patent law suite/settlement process several times already. Being small is not a defense against getting sued. Some IPR holders prefer to start with going after smaller players to create a large precedent base before going after larger targets. As far as possibility of being sued is concerned, the free VP8 license actually looks safer for us then the paid H.264 license. Neither offers indemnity, but, at least, VP8 license offers reciprocity. I do think that the current solution is the only one currently possible. If everyone implements both, then everyone would be forced to deal with the same problems. Hopefully, as a result, some sort of collective resolution would be found. I doubt anybody is happy with this decision. There are a parties who are affected by this decision who can make the situation better for everybody. If they think this decision is so bad, they know exactly what is required to make other options acceptable. _____________ Roman Shpount On Thu, Dec 4, 2014 at 2:25 PM, David Singer wrote: > > > On Dec 3, 2014, at 21:16 , Silvia Pfeiffer > wrote: > > > > Indeed, that's why I said point 1. in David's list doesn't make sense, > since he's talking about a small company getting sued by Nokia. > > So, your conclusion to my question is =E2=80=9CShip VP8, most of you prob= ably > won=E2=80=99t get sued. Good luck. Try not to be too successful or your = luck may > change.=E2=80=9D > > It is an answer; I don=E2=80=99t think it=E2=80=99s a good one, myself. > > > > David Singer > Manager, Software Standards, Apple Inc. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bd910c2b03e1f0509699ef3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
David,

The other answer is "Ship H.264. Most = of you are going to get sued. Good luck settling." The risk associated= with licensing H.264 is very high for any company who is not already part = of this quagmire. There are enough problems there to hire an IPR law firm t= he second you look at H.264 and hope that they are professional enough and = there is enough money to settle.=C2=A0=C2=A0I do understand that companies = who are already stuck with H.264 would not want to be exposed to any additi= onal IPR claims. There is also a little problem that if they implement VP8,= they cannot sue any other VP8 implementers, or risk losing the VP8 IPR lic= ense.

Being a small company, we had to go through patent= law suite/settlement process several times already. Being small is not a d= efense against getting sued. Some IPR holders prefer to start with going af= ter smaller players to create a large precedent base before going after lar= ger targets. As far as possibility of being sued is concerned, the free VP8= license actually looks safer for us then the paid H.264 license. Neither o= ffers indemnity, but, at least, VP8 license offers reciprocity.
=

I do think that the current solution is the only one cu= rrently possible. If everyone implements both, then everyone would be force= d to deal with the same problems. Hopefully, as a result, some sort of coll= ective resolution would be found. I doubt anybody is happy with this decisi= on. There are a parties who are affected by this decision who can make the = situation better for everybody. If they think this decision is so bad, they= know exactly what is required to make other options acceptable.

_____________
Roman Shpount

On Thu, Dec 4, 2014 at 2:25 PM, David Singer= <singer@apple.com> wrote:
=
> On Dec 3, 2014, at 21:16 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
>
> Indeed, that's why I said point 1. in David's list doesn't= make sense, since he's talking about a small company getting sued by N= okia.

So, your conclusion to my question is =E2=80=9CShip VP8, most of you probab= ly won=E2=80=99t get sued. Good luck.=C2=A0 Try not to be too successful or= your luck may change.=E2=80=9D

It is an answer; I don=E2=80=99t think it=E2=80=99s a good one, myself.



David Singer
Manager, Software Standards, Apple Inc.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7bd910c2b03e1f0509699ef3-- From nobody Thu Dec 4 12:20:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E736B1A1AD8 for ; Thu, 4 Dec 2014 12:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7M25-x40bHQ4 for ; Thu, 4 Dec 2014 12:20:12 -0800 (PST) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A480D1A1AD3 for ; Thu, 4 Dec 2014 12:20:12 -0800 (PST) Received: by mail-yh0-f43.google.com with SMTP id z6so8593522yhz.2 for ; Thu, 04 Dec 2014 12:20:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vhymwF9CLk8OR53phg0gBxv9mrW04wDsYI4ddt73DnM=; b=jC5XOFALGb6WqlFyAukpulsSKBLDiA6B4uB1P9x7myYhMd/hoUSdEBMI5e32VeZQlW daJD+aJ/Ye1j1zyuW+OilxdoitvhujGmbID8hcH6suvvlOZwErhZKKFR0vwpSSiwQqnM q8EW6OyfWDQZVDM9rMGE6QwrjDTIMZMfprI9lSUVFDVQ+ilyJeWmVa6viplGo2rKoIaN xix5ezjCbKp3hO/52UIudg04FS2y6u+R5kv7LMTChfbnw7OADumf8TG4CJ46jzgZrBZv bimAaktZveEOECvBGCTty1mkJ0CaTIdN9dVXYfeFJXt7aQ2fW+zgkHobHmC7t6ne1rzp GZQw== MIME-Version: 1.0 X-Received: by 10.236.96.196 with SMTP id r44mr14990243yhf.187.1417724411670; Thu, 04 Dec 2014 12:20:11 -0800 (PST) Received: by 10.170.135.193 with HTTP; Thu, 4 Dec 2014 12:20:11 -0800 (PST) Received: by 10.170.135.193 with HTTP; Thu, 4 Dec 2014 12:20:11 -0800 (PST) In-Reply-To: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> Date: Fri, 5 Dec 2014 07:20:11 +1100 Message-ID: From: Silvia Pfeiffer To: David Singer Content-Type: multipart/alternative; boundary=089e01537a46f2770a050969aff9 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MAkcxBwm6ARHktv5FLDLuY3FR5M Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 20:20:14 -0000 --089e01537a46f2770a050969aff9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5 Dec 2014 06:25, "David Singer" wrote: > > > > On Dec 3, 2014, at 21:16 , Silvia Pfeiffer wrote: > > > > Indeed, that's why I said point 1. in David's list doesn't make sense, since he's talking about a small company getting sued by Nokia. > > So, your conclusion to my question is =E2=80=9CShip VP8, most of you prob= ably won=E2=80=99t get sued. Good luck. Try not to be too successful or your lu= ck may change.=E2=80=9D Yes and it's the same answer as for h.264 and h.265 for that matter. Only add to that the extra licence fee you heavy to pay, which is a certainty - the risk of getting sued is uncertain and frankly quite small compared to other risks that you take as a small company. It would be nice to remove those risks, too, yes, but it's not a show stopper and no different between the codecs. Regards, Silvia. > It is an answer; I don=E2=80=99t think it=E2=80=99s a good one, myself. > > > > David Singer > Manager, Software Standards, Apple Inc. > --089e01537a46f2770a050969aff9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 5 Dec 2014 06:25, "David Singer" <singer@apple.com> wrote:
>
>
> > On Dec 3, 2014, at 21:16 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
> >
> > Indeed, that's why I said point 1. in David's list doesn&= #39;t make sense, since he's talking about a small company getting sued= by Nokia.
>
> So, your conclusion to my question is =E2=80=9CShip VP8, most of you p= robably won=E2=80=99t get sued. Good luck.=C2=A0 Try not to be too successf= ul or your luck may change.=E2=80=9D

Yes and it's the same answer as for h.264 and h.265 for = that matter. Only add to that the extra licence fee you heavy to pay, which= is a certainty - the risk of getting sued is uncertain and frankly quite s= mall compared to other risks that you take as a small company.

It would be nice to remove those risks, too, yes, but it'= ;s not a show stopper and no different between the codecs.

Regards,
Silvia.

> It is an answer; I don=E2=80=99t think it=E2=80=99s a g= ood one, myself.
>
>
>
> David Singer
> Manager, Software Standards, Apple Inc.
>

--089e01537a46f2770a050969aff9-- From nobody Thu Dec 4 12:29:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AEE1A1B1F for ; Thu, 4 Dec 2014 12:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7DCoC4K5Nyl for ; Thu, 4 Dec 2014 12:29:21 -0800 (PST) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C381A1B1E for ; Thu, 4 Dec 2014 12:29:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417724961; x=2281638561; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NYKT+kgH8A6cqkSZE9tQRviV/5DjEffsE0k8iAgBaI8=; b=sUzFZbLx724hn03mqLCGSIgxLnzr2jwqps+zuHogKf2M4I83Vj/xmFs9PEszhCV+ fXFW3IN5Mkl+rfZzevdF/X9WCAm578kIsHJPPXR+27Uv+ICXY7GcmIOvsUlSFoSR drboIlaLREsZoBXFKbcUTXtBUxgYEYoyYLCvcXxLa94E2BX2sMfoETp5M9XwsOEo 9mP8hqsouoEf9UIwNdB+ufJiJDNTt/ea1UFaaJ/P56xkTcAILQ01oYsZyvBODTdE Yud99TB/xQGwDqB2hkyLY0HNku+wt+dJUxqzWUPxXki4tlqV2hQBnhWnzx0B/7lX hGz0L/OEivY4CPOUalL6RQ==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id E6.8D.26546.124C0845; Thu, 4 Dec 2014 12:29:21 -0800 (PST) X-AuditID: 11973e11-f79af6d0000067b2-df-5480c42143ee Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id B2.51.06123.324C0845; Thu, 4 Dec 2014 12:29:23 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG2002H4RKWQP90@marigold.apple.com> for rtcweb@ietf.org; Thu, 04 Dec 2014 12:29:21 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: Date: Thu, 04 Dec 2014 12:29:20 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> To: Roman Shpount X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FAYoat4pCHE4NpWYYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8bFrPVvBbJmKj/8nMTYwHhbrYuTkkBAwkWhZdJcRwhaTuHBv PVsXIxeHkMBeRok/L26ywRQtODWFCSIxiUnix/0VLBDOfCaJN8f2AVVxcDALqEtMmZIL0sAr oCfR9OQxE4gtLBAhcaTzDDuIzSagKvFgzjGwbZwCwRIfHn9gBrFZgOJbenvAljELhEm8mANj a0s8eXeBFWKmjcSUB/3MEHtvMEtMPL8XbJAIUPPf75OZIC6Vlfh3EWQZF5D9klVi+qv9zBMY hWch3DcLyX2zkOxYwMi8ilEoNzEzRzczz0gvsaAgJ1UvOT93EyMokKfbCe5gPL7K6hCjAAej Eg9v4e76ECHWxLLiytxDjNIcLErivGz1DSFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGDc/ nnErxeDFGZclXOGRTj+5erYerLh8gVUh8MZngeXSfYLzK6/nS+aHz9zqubhOJYF3yRO2Y/KJ mR2+JcuunC16KRj0/ERt2b3JzeWLNCPnpU2Ru3lhUW3s8m3uWV/kRBo9FNROZYdfaO9YaKWt rXPGdu2M8qnHKgvvaK94Lb91UY3A15Pn5ZRYijMSDbWYi4oTAemuV7RFAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcoqt8pCHEYOk0Dou1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8bFrPVvBbJmKj/8nMTYwHhbrYuTkkBAwkVhwagoThC0mceHe erYuRi4OIYFJTBI/7q9ggXDmM0m8ObYPKMPBwSygLjFlSi5IA6+AnkTTk8dgzcICERJHOs+w g9hsAqoSD+YcYwSxOQWCJT48/sAMYrMAxbf09rCB2MwCYRIv5sDY2hJP3l1ghZhpIzHlQT8z xN4bzBITz+8FGyQC1Pz3+2SoS2Ul/l08wz6BUWAWwkmzkJw0C8nYBYzMqxgFilJzEitN9RIL CnJS9ZLzczcxggOvMGIH4/9lVocYBTgYlXh4C3bXhwixJpYVV+YeYpTgYFYS4XXZ3xAixJuS WFmVWpQfX1Sak1p8iFGag0VJnLcqG6haID2xJDU7NbUgtQgmy8TBKdXAuGvyw4oJU2ds+qe9 QnHTb42/kfuTpJjVPwjEcopGFW7wXJQ+O/qj5dlvG7yKxF3NtNxPS938ouJkxGppL+8dVFUj a/PDxmD55Jty/5jjX0tw74phvKCevqSahefn223MDmYmLcdVmf/wuWYEf1/0+tKzLZtOSIjI rYzcHjJ7Z4rqylhtCcm5SizFGYmGWsxFxYkAvIvnpDgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/66uQwHliYo975ey9OsiYmY03WBo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 20:29:24 -0000 > On Dec 4, 2014, at 12:15 , Roman Shpount wrote: >=20 > David, >=20 > The other answer is "Ship H.264. Most of you are going to get sued. = Good luck settling." The risk associated with licensing H.264 is very = high for any company who is not already part of this quagmire. I beg to disagree. I am unaware of any problem from any company that = has not made clear RAND declarations to the appropriate bodies, and most = of those are members of MPEG-LA, so though it=E2=80=99s not quite a = one-stop shop, it=E2=80=99s close. Not only is there a formal =E2=80=9Cunwilling to license=E2=80=9D on the = table for VP8, it was not developed by the companies active in this = area, and with significant portfolios, and (as Nokia shows) they may not = find themselves under formal or moral obligation to license at all. > There are enough problems there to hire an IPR law firm the second you = look at H.264 and hope that they are professional enough and there is = enough money to settle. I do understand that companies who are already = stuck with H.264 would not want to be exposed to any additional IPR = claims. There is also a little problem that if they implement VP8, they = cannot sue any other VP8 implementers, or risk losing the VP8 IPR = license. True, we would get some protection from practicing entities. >=20 > Being a small company, we had to go through patent law = suite/settlement process several times already. Being small is not a = defense against getting sued. Not what Silvia was hoping to hear. > Some IPR holders prefer to start with going after smaller players to = create a large precedent base before going after larger targets. As far = as possibility of being sued is concerned, the free VP8 license actually = looks safer for us then the paid H.264 license. Neither offers = indemnity, but, at least, VP8 license offers reciprocity. I think there is also some defensive suspension in the H.264 licenses, = but I would have to check. >=20 > I do think that the current solution is the only one currently = possible. If everyone implements both, then everyone would be forced to = deal with the same problems. =E2=80=9CWe may as well all drown together=E2=80=9D =E2=80=94 it=E2=80=99s= not very cheery, is it? > Hopefully, as a result, some sort of collective resolution would be = found. I doubt anybody is happy with this decision. There are a parties = who are affected by this decision who can make the situation better for = everybody. If they think this decision is so bad, they know exactly what = is required to make other options acceptable. I wish. >=20 > _____________ > Roman Shpount >=20 > On Thu, Dec 4, 2014 at 2:25 PM, David Singer wrote: >=20 > > On Dec 3, 2014, at 21:16 , Silvia Pfeiffer = wrote: > > > > Indeed, that's why I said point 1. in David's list doesn't make = sense, since he's talking about a small company getting sued by Nokia. >=20 > So, your conclusion to my question is =E2=80=9CShip VP8, most of you = probably won=E2=80=99t get sued. Good luck. Try not to be too = successful or your luck may change.=E2=80=9D >=20 > It is an answer; I don=E2=80=99t think it=E2=80=99s a good one, = myself. >=20 >=20 >=20 > David Singer > Manager, Software Standards, Apple Inc. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 David Singer Manager, Software Standards, Apple Inc. From nobody Thu Dec 4 12:30:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838F61A1B53 for ; Thu, 4 Dec 2014 12:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoPcOoYnTlHL for ; Thu, 4 Dec 2014 12:30:51 -0800 (PST) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7051C1A1B43 for ; Thu, 4 Dec 2014 12:30:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417725051; x=2281638651; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NRQRHPqdQlq6XaGAy2Yfw/VdxII+r7Amr3NOKoxJwBo=; b=irRTJTOxstv9HGFComKwR3/0dCpMW+9VoEtJy4UbA887+mOoOoUcZF6uXM/qgQDt bfttOZv9BTAVnFouiLme5JRC7y1TtSLRm18zLzCmab8DeoayFvUCpSWJPW/aKj1J FPD7pXJJMEbkShsPx3eQLs7kcuJwtStvrklMOCsOkcNWKvUYU8EqrOVnWdRTWcrm 416f3REJkkkUeuMEmVsWFK20f8UeY0m9SMjQ1DvN2GriX1EBQstQdkTLE6CKdcMR tpxQ7nhGQxYgICxpOiJjGyRlVFMwlpy8adkJ7ozyroGEwW+9Ajh2r0KBwxWwwH2Z KVPY5WNIz1nji05EZjmitw==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 39.ED.26546.B74C0845; Thu, 4 Dec 2014 12:30:51 -0800 (PST) X-AuditID: 11973e11-f79af6d0000067b2-7e-5480c47b4ca9 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 91.72.06123.C74C0845; Thu, 4 Dec 2014 12:30:52 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG2005IHRNE6L10@marigold.apple.com> for rtcweb@ietf.org; Thu, 04 Dec 2014 12:30:50 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: Date: Thu, 04 Dec 2014 12:30:50 -0800 Content-transfer-encoding: quoted-printable Message-id: <1F326DF9-79C2-4562-853B-240D934EA235@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> To: Silvia Pfieffer X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FAYoVt9pCHEYNIndou1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcepeB2PBTM6KzTfXsjYwzmfvYuTkkBAwkbh8eiIjhC0mceHe ejYQW0hgL6PE9ktZMDW3D15n6WLkAopPYpJYf+49K4Qzn0ni4OMZQA4HB7OAusSUKbkgDbwC ehJNTx4zgdjCAhESRzrPgC1jE1CVeDDnGNgyToFgiZltT1hBbBag+NHHL8FsZgFLieP/7zBB 2NoST95dYIWYaSNxon0vO8TeG8wSn6ZuALtUREBfYtmeQ1DfyEr8u3gGrEhC4C2rxPW2/awT GIVnIdw3C8l9s5DsWMDIvIpRKDcxM0c3M89IL7GgICdVLzk/dxMjKIyn2wnuYDy+yuoQowAH oxIPb+Hu+hAh1sSy4srcQ4zSHCxK4rxs9Q0hQgLpiSWp2ampBalF8UWlOanFhxiZODilGhiv NRb+neg8+7VoVvaZF9MPqgYV28Yy2zc1Fmnvuu4ntqD/0mHdjm2LBRJOaF9ZftOyaFrg/LXX 7Iq22e/fPkt8x+EJR26muRRsCWffcLzuKp+ryXOmZ3Y3J3ozbV7IM3/dyZZs396/Z3l/PfoZ 9/fdm/r3S8xPhwgpVtx6c2v2nmSX657aep+TlViKMxINtZiLihMBOVrAg0QCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcoltzpCHEoGGBlcXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOHWvg7FgJmfF5ptrWRsY57N3MXJySAiYSNw+eJ0FwhaTuHBv PVsXIxeHkMAkJon1596zQjjzmSQOPp4B5HBwMAuoS0yZkgvSwCugJ9H05DETiC0sECFxpPMM 2FA2AVWJB3OOMYLYnALBEjPbnrCC2CxA8aOPX4LZzAKWEsf/32GCsLUlnry7wAox00biRPte doi9N5glPk3dwAaSEBHQl1i25xDU1bIS/y6eYZ/AKDAL4aRZSE6ahWTsAkbmVYwCRak5iZWm eokFBTmpesn5uZsYwYFXGLGD8f8yq0OMAhyMSjy8BbvrQ4RYE8uKK3MPMUpwMCuJ8LrsbwgR 4k1JrKxKLcqPLyrNSS0+xCjNwaIkzluVDVQtkJ5YkpqdmlqQWgSTZeLglGpg5Jtnwsml0bjn vsBdnVixOyc3nzWNDEqX/fHy57aDXLKt2y8XHM5W3mv6Lqbit14lk+Ff06YuE9vUtFUiX/WX bGOV11e9tmVC3wmm6Sc+/75+J6E8X/naYv0LQa8WT9k38cR0jdCmN29fvzu3bdKEvPQtfFK1 5fccPgTvPsJe/i4yxCj4ueB9EyWW4oxEQy3mouJEAD3VFNY4AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/L2bhL634m0hE7xDpDhoP5MC-IEg Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 20:30:54 -0000 > On Dec 4, 2014, at 12:20 , Silvia Pfeiffer = wrote: >=20 >=20 > On 5 Dec 2014 06:25, "David Singer" wrote: > > > > > > > On Dec 3, 2014, at 21:16 , Silvia Pfeiffer = wrote: > > > > > > Indeed, that's why I said point 1. in David's list doesn't make = sense, since he's talking about a small company getting sued by Nokia. > > > > So, your conclusion to my question is =E2=80=9CShip VP8, most of you = probably won=E2=80=99t get sued. Good luck. Try not to be too = successful or your luck may change.=E2=80=9D >=20 > Yes and it's the same answer as for h.264 and h.265 for that matter. It is not at all. Where are the =E2=80=9Cunwilling to license=E2=80=9D = statements for H.264? Where is the VP8 license coverage from the larger = players not in the MPEG-LA agreement? > Only add to that the extra licence fee you heavy to pay, which is a = certainty - the risk of getting sued is uncertain and frankly quite = small compared to other risks that you take as a small company. See the other thread=E2=80=A6 David Singer Manager, Software Standards, Apple Inc. From nobody Thu Dec 4 12:35:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3412A1A1DE2 for ; Thu, 4 Dec 2014 12:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_7Q55f7_fvo for ; Thu, 4 Dec 2014 12:34:55 -0800 (PST) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E1C1A1BFC for ; Thu, 4 Dec 2014 12:34:35 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id l13so20697379iga.9 for ; Thu, 04 Dec 2014 12:34:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=P9qzlHfk+NTn8dJnam2Gg4Ygn1WbgW6KD+azbX/iHyU=; b=TnZqlkLFjC9OAQzUAkNpMwoXIxREHa83rZUV5V5UuBkKOMJ58BwRnELghpq4Cce1AC XRr9kyCVGzCIM2Kpbqry8VQ1k0stQ3u8LTBdhJ29BG75NpWrIDcQUllqOG/okNWCgceS iXRD6jnJKRFDmBth0zPW7QBEN1Ub6OgHIowg0+I9RtFcWX+tHLLwB207E2734wVBLawo Ti7n74YzCjCUi7W/efMUWeieWO1wKGCBtuU8vI/BuD25krk7ZWd9W1LP3GAHTlhCg+lL L+zhba2se7NjfhKsjz35rf8nchNKZNrJHjdwcwFbKuzMFXCyRHxF4QMdJ3O4mAnQIST+ MUjQ== X-Gm-Message-State: ALoCoQn8KsciMkysREQ+Q/hnJSyW6SM9zW0Wwgi3Gy5wY1TR8f3acCqlh/44yAL/OYvNXNzSvVC8 X-Received: by 10.50.131.225 with SMTP id op1mr123173igb.4.1417725275230; Thu, 04 Dec 2014 12:34:35 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id w7sm14918368iod.8.2014.12.04.12.34.34 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Dec 2014 12:34:34 -0800 (PST) Message-ID: <5480C531.5050104@bbs.darktech.org> Date: Thu, 04 Dec 2014 15:33:53 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/oV5SuOC-IZWaD4s3_v7nB9t-cIo Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 20:34:58 -0000 A formal "unwilling to license" without any factual information to back it up is practically meaningless. What is the legal difference between a company that does that and a company who sues using a previously-undeclared H.264 IPR? Gili On 04/12/2014 3:29 PM, David Singer wrote: >> On Dec 4, 2014, at 12:15 , Roman Shpount wrote: >> >> David, >> >> The other answer is "Ship H.264. Most of you are going to get sued. Good luck settling." The risk associated with licensing H.264 is very high for any company who is not already part of this quagmire. > I beg to disagree. I am unaware of any problem from any company that has not made clear RAND declarations to the appropriate bodies, and most of those are members of MPEG-LA, so though it’s not quite a one-stop shop, it’s close. > > Not only is there a formal “unwilling to license†on the table for VP8, it was not developed by the companies active in this area, and with significant portfolios, and (as Nokia shows) they may not find themselves under formal or moral obligation to license at all. > > >> There are enough problems there to hire an IPR law firm the second you look at H.264 and hope that they are professional enough and there is enough money to settle. I do understand that companies who are already stuck with H.264 would not want to be exposed to any additional IPR claims. There is also a little problem that if they implement VP8, they cannot sue any other VP8 implementers, or risk losing the VP8 IPR license. > True, we would get some protection from practicing entities. > >> Being a small company, we had to go through patent law suite/settlement process several times already. Being small is not a defense against getting sued. > Not what Silvia was hoping to hear. > >> Some IPR holders prefer to start with going after smaller players to create a large precedent base before going after larger targets. As far as possibility of being sued is concerned, the free VP8 license actually looks safer for us then the paid H.264 license. Neither offers indemnity, but, at least, VP8 license offers reciprocity. > I think there is also some defensive suspension in the H.264 licenses, but I would have to check. > >> I do think that the current solution is the only one currently possible. If everyone implements both, then everyone would be forced to deal with the same problems. > “We may as well all drown together†— it’s not very cheery, is it? > >> Hopefully, as a result, some sort of collective resolution would be found. I doubt anybody is happy with this decision. There are a parties who are affected by this decision who can make the situation better for everybody. If they think this decision is so bad, they know exactly what is required to make other options acceptable. > I wish. > >> _____________ >> Roman Shpount >> >> On Thu, Dec 4, 2014 at 2:25 PM, David Singer wrote: >> >>> On Dec 3, 2014, at 21:16 , Silvia Pfeiffer wrote: >>> >>> Indeed, that's why I said point 1. in David's list doesn't make sense, since he's talking about a small company getting sued by Nokia. >> So, your conclusion to my question is “Ship VP8, most of you probably won’t get sued. Good luck. Try not to be too successful or your luck may change.†>> >> It is an answer; I don’t think it’s a good one, myself. >> >> >> >> David Singer >> Manager, Software Standards, Apple Inc. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > David Singer > Manager, Software Standards, Apple Inc. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Dec 4 12:40:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6751B1A1E0F for ; Thu, 4 Dec 2014 12:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZS29P7Dlt8E for ; Thu, 4 Dec 2014 12:40:52 -0800 (PST) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F321A1B6B for ; Thu, 4 Dec 2014 12:40:51 -0800 (PST) Received: by mail-yh0-f42.google.com with SMTP id v1so8692510yhn.29 for ; Thu, 04 Dec 2014 12:40:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NjZZ187WlsQuPAw+LHRJbFxCFRBiV2XZc30aABZHwug=; b=vjk/OuSJyiM2aVEd9qHYOoXfJPVHPmzSimjTcG2JYCJ0ebJrphnhgKt3Z8nCzuOwEt XbdmzXR+0o1sEdUdXS2Q35IDyqdBqPFz1o10vIkDmh3TflXCp2Vy0GkHuX6BJ2Jq6LvU WPdu5Yvu/uZ5ytdEbxaLALb6FtXOmoPgUPrTRccKzWw50/rFySjMZRn3cxkh5x3M4lTf 8hRmshiwRNv3zTmXj5ZZ55MFQqP6rfT0WmxuqDfnMHzT5Ky3Evna3JSrtbk3Rv6EIVtc bV16h1BKWJptvAZA9Mj3dtXGyaXj6qMB0ofawfm7pjnmw2BLvR9Jl/RmG/Q00CHFtA1F sNjw== MIME-Version: 1.0 X-Received: by 10.236.11.168 with SMTP id 28mr15592169yhx.170.1417725651193; Thu, 04 Dec 2014 12:40:51 -0800 (PST) Received: by 10.170.135.193 with HTTP; Thu, 4 Dec 2014 12:40:51 -0800 (PST) Received: by 10.170.135.193 with HTTP; Thu, 4 Dec 2014 12:40:51 -0800 (PST) In-Reply-To: <1F326DF9-79C2-4562-853B-240D934EA235@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> <1F326DF9-79C2-4562-853B-240D934EA235@apple.com> Date: Fri, 5 Dec 2014 07:40:51 +1100 Message-ID: From: Silvia Pfeiffer To: David Singer Content-Type: multipart/alternative; boundary=001a1133c956d415eb050969f98c Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/iyW2ssQjCJQ18WK7aNtPHI-jvZU Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 20:40:53 -0000 --001a1133c956d415eb050969f98c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5 Dec 2014 07:30, "David Singer" wrote: > > > > On Dec 4, 2014, at 12:20 , Silvia Pfeiffer wrote: > > > > > > On 5 Dec 2014 06:25, "David Singer" wrote: > > > > > > > > > > On Dec 3, 2014, at 21:16 , Silvia Pfeiffer < silviapfeiffer1@gmail.com> wrote: > > > > > > > > Indeed, that's why I said point 1. in David's list doesn't make sense, since he's talking about a small company getting sued by Nokia. > > > > > > So, your conclusion to my question is =E2=80=9CShip VP8, most of you = probably won=E2=80=99t get sued. Good luck. Try not to be too successful or your lu= ck may change.=E2=80=9D > > > > Yes and it's the same answer as for h.264 and h.265 for that matter. > > It is not at all. Where are the =E2=80=9Cunwilling to license=E2=80=9D s= tatements for H.264? Where is the VP8 license coverage from the larger players not in the MPEG-LA agreement? > > > Only add to that the extra licence fee you heavy to pay, which is a certainty - the risk of getting sued is uncertain and frankly quite small compared to other risks that you take as a small company. That can very nicely be construed as anticompetitive behaviour I would think in my layman knowledge. It certainly doesn't look like playing fair. > See the other thread=E2=80=A6 Indeed, Roman certainly has more experience with law suits and still shares my position. Regards, Silvia. > David Singer > Manager, Software Standards, Apple --001a1133c956d415eb050969f98c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 5 Dec 2014 07:30, "David Singer" <singer@apple.com> wrote:
>
>
> > On Dec 4, 2014, at 12:20 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
> >
> >
> > On 5 Dec 2014 06:25, "David Singer" <singer@apple.com> wrote:
> > >
> > >
> > > > On Dec 3, 2014, at 21:16 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> wro= te:
> > > >
> > > > Indeed, that's why I said point 1. in David's l= ist doesn't make sense, since he's talking about a small company ge= tting sued by Nokia.
> > >
> > > So, your conclusion to my question is =E2=80=9CShip VP8, mos= t of you probably won=E2=80=99t get sued. Good luck.=C2=A0 Try not to be to= o successful or your luck may change.=E2=80=9D
> >
> > Yes and it's the same answer as for h.264 and h.265 for that = matter.
>
> It is not at all.=C2=A0 Where are the =E2=80=9Cunwilling to license=E2= =80=9D statements for H.264?=C2=A0 Where is the VP8 license coverage from t= he larger players not in the MPEG-LA agreement?
>
> > Only add to that the extra licence fee you heavy to pay, which is= a certainty - the risk of getting sued is uncertain and frankly quite smal= l compared to other risks that you take as a small company.

That can very nicely be construed as anticompetitive behavio= ur I would think in my layman knowledge. It certainly doesn't look like= playing fair.

> See the other thread=E2=80=A6

Indeed, Roman certainly has more experience with law suits a= nd still shares my position.

Regards,
Silvia.

> David Singer
> Manager, Software Standards, Apple

--001a1133c956d415eb050969f98c-- From nobody Thu Dec 4 12:43:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35A61A1ABB for ; Thu, 4 Dec 2014 12:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRRm-d4hAonw for ; Thu, 4 Dec 2014 12:43:48 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D5EA1A1AA5 for ; Thu, 4 Dec 2014 12:43:48 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id A1EC6DC592D10; Thu, 4 Dec 2014 20:43:43 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sB4Khk5Y027530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 21:43:46 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 21:43:46 +0100 From: "DRAGE, Keith (Keith)" To: David Singer , Silvia Pfieffer Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) Thread-Index: AQHQD/+9dvoOgSKMeEyydWLYZisN4px/0Z8AgAASoDA= Date: Thu, 4 Dec 2014 20:43:46 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B28CDFF@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> <1F326DF9-79C2-4562-853B-240D934EA235@apple.com> In-Reply-To: <1F326DF9-79C2-4562-853B-240D934EA235@apple.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EkqsZ9wBzl4LEnrDD-3L7GBsVz8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 20:43:51 -0000 As a tangent to this discussion, I'd note that pretty much every codec impl= ementor will be subject to additional IPR risk. This is because pretty much= all the standards specifications of codecs only specify the decoder (VP8 i= ncluded). Therefore any IPR claims and licences tied to the specification w= ill only have relevance to the decoder. Unless you have a viable application that only needs the decoder, you will = have zero visibility in the standards IPR databases of what IPR claims migh= t exist against your coder implementation. Everyone who uses the term "codec" in association with "royalty free" or "I= PR free" is misleading the world. What they mean is the decoder only. Regards Keith > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20 > David Singer > Sent: 04 December 2014 20:31 > To: Silvia Pfieffer > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Finishing up the Video Codec document,=20 > MTI (again, still, sorry) >=20 >=20 > > On Dec 4, 2014, at 12:20 , Silvia Pfeiffer=20 > wrote: > >=20 > >=20 > > On 5 Dec 2014 06:25, "David Singer" wrote: > > > > > > > > > > On Dec 3, 2014, at 21:16 , Silvia Pfeiffer=20 > wrote: > > > > > > > > Indeed, that's why I said point 1. in David's list=20 > doesn't make sense, since he's talking about a small company=20 > getting sued by Nokia. > > > > > > So, your conclusion to my question is "Ship VP8, most of=20 > you probably won't get sued. Good luck. Try not to be too=20 > successful or your luck may change." > >=20 > > Yes and it's the same answer as for h.264 and h.265 for that matter. >=20 > It is not at all. Where are the "unwilling to license"=20 > statements for H.264? Where is the VP8 license coverage from=20 > the larger players not in the MPEG-LA agreement? >=20 > > Only add to that the extra licence fee you heavy to pay,=20 > which is a certainty - the risk of getting sued is uncertain=20 > and frankly quite small compared to other risks that you take=20 > as a small company. >=20 > See the other thread... >=20 > David Singer > Manager, Software Standards, Apple Inc. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From nobody Thu Dec 4 12:52:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31D71A1B23 for ; Thu, 4 Dec 2014 12:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_2PRsDNLOCQ for ; Thu, 4 Dec 2014 12:52:43 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C413E1A1A88 for ; Thu, 4 Dec 2014 12:52:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417726363; x=2281639963; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5iESltNeREH8v/2zv9CvLAJCnR3jqEj/bSJ+m1mjLkg=; b=rZQ0a2+Zd6NjJHSdwBaHsbKs0jxwed7E6QCmZb2+N7mcIkZC2lEkOBmDtK8Ge4AZ iomeKC6B/Pk9nlFaQiW6GSfEseZT7k3PBdojcopflIoov0wffRlD7q+utG0OKVlh /injyC19ihM86m2pgmOFaAm3ZVnwIhtx/ZHawH7bNYsj/tfXrGA8jKc6LQb6hiF9 BMMoiajpVHAm0UGtjOGwaaIc7Q8L2y8QuDaiTU27pVXEp8TtLYlGyc8BqpzytA8j qK3snT0BBZjILrByV91MF2Wf247qX8F+c6Wjf/cQfG3jzyKD3Ys7rFgneqG3v85X v5Svqs8oI1k0yDDSZhhlbA==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id E4.1E.12074.B99C0845; Thu, 4 Dec 2014 12:52:43 -0800 (PST) X-AuditID: 11973e12-f79f86d000002f2a-59-5480c99b67d2 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 5D.9E.06123.D99C0845; Thu, 4 Dec 2014 12:52:45 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG200D5XSNU4O00@marigold.apple.com> for rtcweb@ietf.org; Thu, 04 Dec 2014 12:52:43 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: Date: Thu, 04 Dec 2014 12:52:42 -0800 Content-transfer-encoding: quoted-printable Message-id: <1F5B8077-0811-49FC-A168-398162B765F4@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> <1F326DF9-79C2-4562-853B-240D934EA235@apple.com> To: Silvia Pfieffer X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FAYoTv7ZEOIwa9NshZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY8qKlYwFK3krXq5ZyNbAuI6ri5GTQ0LAROLti1lMELaYxIV7 69m6GLk4hAT2Mko8WHacGabo1vH77BCJSUwSt7eeZoRw5jNJNG6dy9LFyMHBLKAuMWVKLkgD r4CeRNOTx2BThQUiJI50nmEHsdkEVCUezDnGCGJzCgRLXJ/zA6yGBSg+a9NWNhCbWcBS4vj/ O0wQtrbEk3cXWCFm2kh8vdPGDLH3EovEy/NHwRpEBPQllu05xA5xqazEv4tnwC6VEPjIKjFl QyfzBEbhWQj3zUJy3ywkOxYwMq9iFMpNzMzRzcwz0UssKMhJ1UvOz93ECArk6XZCOxhPrbI6 xCjAwajEw1uwuz5EiDWxrLgy9xCjNAeLkjgvW31DiJBAemJJanZqakFqUXxRaU5q8SFGJg5O qQZGK88Nj5xaF+b53L+rNj1nVlFGq9HHpr5O9pKYumV/vb0Y3tr9tjLTOnlSLlb627XGlrsR L10EtvftcfsTETjlX+3kB0pc911vv+BcPumO4PamjTKd/L5Oki7hW+TZvO1PPRMJdr0uu9fq D8uWhI2Sc8WbK34KKXm6bTSd/VhU9O3jspYDGi5KLMUZiYZazEXFiQDGQ8mdRQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcojv3ZEOIwae7QhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY8qKlYwFK3krXq5ZyNbAuI6ri5GTQ0LAROLW8fvsELaYxIV7 69m6GLk4hAQmMUnc3nqaEcKZzyTRuHUuSxcjBwezgLrElCm5IA28AnoSTU8eM4HYwgIREkc6 z4ANYhNQlXgw5xgjiM0pECxxfc4PsBoWoPisTVvZQGxmAUuJ4//vMEHY2hJP3l1ghZhpI/H1 ThszxN5LLBIvzx8FaxAR0JdYtucQ1KWyEv8unmGfwCgwC+GkWUhOmoVk7AJG5lWMAkWpOYmV pnqJBQU5qXrJ+bmbGMGBVxixg/H/MqtDjAIcjEo8vAW760OEWBPLiitzDzFKcDArifAaH2kI EeJNSaysSi3Kjy8qzUktPsQozcGiJM5blQ1ULZCeWJKanZpakFoEk2Xi4JRqYKx5/Fjw50dZ pt3hbCeTGsQPGLYY/nS1eR+qtVhLaQHH+jXbKvv1WK5Nfe/V9ueE97vT0c1bD71SuckvwBT7 rX2JcbWj4Znm2o1dqzvbJb50TOjPmuhc+3jB2ue19adZTbTDZxR6NfS87Fz1+6rx2tfXpu/2 TxZbvPIu87lQk98HlmddvcO6UliJpTgj0VCLuag4EQCTPeUwOAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/V0vv9CbtmVcO7v-sv9KtX2shhn0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 20:52:45 -0000 > On Dec 4, 2014, at 12:40 , Silvia Pfeiffer = wrote: >=20 >=20 > On 5 Dec 2014 07:30, "David Singer" wrote: > > > > > > > On Dec 4, 2014, at 12:20 , Silvia Pfeiffer = wrote: > > > > > > > > > On 5 Dec 2014 06:25, "David Singer" wrote: > > > > > > > > > > > > > On Dec 3, 2014, at 21:16 , Silvia Pfeiffer = wrote: > > > > > > > > > > Indeed, that's why I said point 1. in David's list doesn't = make sense, since he's talking about a small company getting sued by = Nokia. > > > > > > > > So, your conclusion to my question is =E2=80=9CShip VP8, most of = you probably won=E2=80=99t get sued. Good luck. Try not to be too = successful or your luck may change.=E2=80=9D > > > > > > Yes and it's the same answer as for h.264 and h.265 for that = matter. > > > > It is not at all. Where are the =E2=80=9Cunwilling to license=E2=80=9D= statements for H.264? Where is the VP8 license coverage from the = larger players not in the MPEG-LA agreement? > > > > > Only add to that the extra licence fee you heavy to pay, which is = a certainty - the risk of getting sued is uncertain and frankly quite = small compared to other risks that you take as a small company. >=20 > That can very nicely be construed as anticompetitive behaviour I would = think in my layman knowledge. It certainly doesn't look like playing = fair. Sorry, I can=E2=80=99t work out what you say is not playing fair? Using = someone else=E2=80=99s patents and assuming that they will give everyone = a license? David Singer Manager, Software Standards, Apple Inc. From nobody Thu Dec 4 13:04:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F23A1A1A82 for ; Thu, 4 Dec 2014 13:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCrUYLAAttE8 for ; Thu, 4 Dec 2014 13:04:35 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774F21A0385 for ; Thu, 4 Dec 2014 13:04:35 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id a1so15668560wgh.33 for ; Thu, 04 Dec 2014 13:04:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=reW5rid6JTDp4IG/ZcZimLMm3NKw/1m4F0Spjs0Gcus=; b=dTkG9R+bfn8mr6unUOBveGX6cN6zFxdw3wxzl2zryUfSmtocyvjO+l/Bl22L4q8I1Y /UalvKf59OtxKDlueFrnubMqm68kBZF0fVU8rDm/o7lhB9e5X/8sKqWrZoWKbs7gFznG fwSLJ2ijxtnmF3fJusWYBt5pZ70VMVdt5f+H6WHkGjOO3QS5aFPouXQYKRO3zqYLSY5m 7FoHw8/m7FckO6NcXmFVWzjOlV8xWwFEtT4Vm22/+YJfkz5lwiIMEYQAihEtxp+xFwXk GFCwO9cLJsS8OHjK+sUl2jVo9V5qqEwjSdNy/+4/Jr2XdtF4Fqgn2Z0Vq0UIMwr0cD+l x1YQ== X-Gm-Message-State: ALoCoQmkxrIuYgdHNlDh4rqPzb+N45fVYCbxP6h1tuTpL7lAfAh+1k8dQc3L/D1+qFZLOl5EkAtc X-Received: by 10.194.216.170 with SMTP id or10mr15607695wjc.96.1417727074304; Thu, 04 Dec 2014 13:04:34 -0800 (PST) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com. [209.85.212.170]) by mx.google.com with ESMTPSA id ep9sm8300391wid.3.2014.12.04.13.04.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 13:04:33 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id bs8so37637794wib.5 for ; Thu, 04 Dec 2014 13:04:33 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.78.9 with SMTP id x9mr24533745wiw.39.1417727073130; Thu, 04 Dec 2014 13:04:33 -0800 (PST) Received: by 10.216.70.16 with HTTP; Thu, 4 Dec 2014 13:04:32 -0800 (PST) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B28CDFF@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> <1F326DF9-79C2-4562-853B-240D934EA235@apple.com> <949EF20990823C4C85C18D59AA11AD8B28CDFF@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 4 Dec 2014 16:04:32 -0500 Message-ID: From: Roman Shpount To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=f46d043bdece95206005096a4ec5 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1uc3bUhF-JzVoTCPxah29R7k3sQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 21:04:38 -0000 --f46d043bdece95206005096a4ec5 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 4, 2014 at 3:43 PM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > As a tangent to this discussion, I'd note that pretty much every codec > implementor will be subject to additional IPR risk. This is because pretty > much all the standards specifications of codecs only specify the decoder > (VP8 included). Therefore any IPR claims and licences tied to the > specification will only have relevance to the decoder. > > Unless you have a viable application that only needs the decoder, you will > have zero visibility in the standards IPR databases of what IPR claims > might exist against your coder implementation. > > Everyone who uses the term "codec" in association with "royalty free" or > "IPR free" is misleading the world. What they mean is the decoder only. > > Actually Google does grant patent license to the implementation of WebM, which includes both encoder and decoder ( http://www.webmproject.org/license/additional/). This is one of the reasons we think VP8 license is better then H.264. (The other two are reciprocity and no use restrictions on the produced media). _____________ Roman Shpount --f46d043bdece95206005096a4ec5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 4, 2014 at 3:43 PM, DRAGE, Keith (Keith) <keith.drage= @alcatel-lucent.com> wrote:
As a tangent = to this discussion, I'd note that pretty much every codec implementor w= ill be subject to additional IPR risk. This is because pretty much all the = standards specifications of codecs only specify the decoder (VP8 included).= Therefore any IPR claims and licences tied to the specification will only = have relevance to the decoder.

Unless you have a viable application that only needs the decoder, you will = have zero visibility in the standards IPR databases of what IPR claims migh= t exist against your coder implementation.

Everyone who uses the term "codec" in association with "roya= lty free" or "IPR free" is misleading the world. What they m= ean is the decoder only.


Actually Google does grant patent lice= nse to the implementation of WebM, which includes both encoder and decoder = (http://www.webm= project.org/license/additional/). This is one of the reasons we think V= P8 license is better then H.264. (The other two are reciprocity and no use = restrictions on the produced media).
_____________
Roman Shpount
=C2=A0
<= /div> --f46d043bdece95206005096a4ec5-- From nobody Thu Dec 4 13:15:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78BC1A1E0F for ; Thu, 4 Dec 2014 13:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vdR0OtcJvyE for ; Thu, 4 Dec 2014 13:15:31 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30C21A1A06 for ; Thu, 4 Dec 2014 13:15:31 -0800 (PST) Received: from [192.168.5.111] (50-193-216-106-static.hfc.comcastbusiness.net [50.193.216.106]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id DCFA0F20DE for ; Thu, 4 Dec 2014 13:15:30 -0800 (PST) Message-ID: <5480CEF2.4020204@mozilla.com> Date: Thu, 04 Dec 2014 13:15:30 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> <1F326DF9-79C2-4562-853B-240D934EA235@apple.com> <949EF20990823C4C85C18D59AA11AD8B28CDFF@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0sgWctgu2Vo-mic10-FJtAOnuHM Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 21:15:38 -0000 Roman Shpount wrote: > Actually Google does grant patent license to the implementation of WebM, > which includes both encoder and decoder > (http://www.webmproject.org/license/additional/). This is one of the > reasons we think VP8 license is better then H.264. (The other two are > reciprocity and no use restrictions on the produced media). Serge also confirmed on this list that that license applies to third-party implementations as well: https://www.ietf.org/mail-archive/web/rtcweb/current/msg04006.html The Opus licenses similarly grant rights to patents that read on the reference implementation, including the encoder, even if used in a third-party implementation. Now, it's certainly possible to infringe other people's IPR by implementing an encoder sufficiently different from the reference encoder. One must be very careful when doing that. But these reference implementations are production-grade. Anyone who merely wishes to deploy a codec has an implementation they can use with just as much assurance of the IPR safety of the encoder as they have of the decoder. From nobody Thu Dec 4 13:22:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4E11A1AA7 for ; Thu, 4 Dec 2014 13:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhSwxEHVrGmO for ; Thu, 4 Dec 2014 13:22:04 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395631A1A06 for ; Thu, 4 Dec 2014 13:22:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417728123; x=2281641723; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NqKewsHG/r+hO4Gsv/5OkgCcbPpmCtp8SX0k5lc4U+o=; b=zO7tKkP7t4+1c5xabiA9OZFS2LVd5Sxpm/9cz4YRPOu1S2kLPdQElkKwjx313tG/ VSDfhhEYFSVP9Aym8Z/SKGheRVWvwSnelvKzaYq6UbUbtN5VQJHGWFuTVpywaWZ9 tfceWYHBC7dVqZzK3DD503n4wnll76s7eMORkcc7YsfQwcKzEQlGvPXH4QscyYbK DA/X0/U1lSR49snZEemwVAbYLNlhe3NadZ1NWq9jQBUzGlfcXVGNoq0/OiDrusY1 t6ppxqGqLL1ZG+MvmyIUOe1PRMz1Fktb8HlrDXXx7tqr69K8PBRIwCl2pRAAafqR ePRCl8vwo7BP6kkXEXLW2w==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id CF.D2.06819.B70D0845; Thu, 4 Dec 2014 13:22:03 -0800 (PST) X-AuditID: 11973e13-f79656d000001aa3-4e-5480d07bf013 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id B8.48.05775.660D0845; Thu, 4 Dec 2014 13:21:43 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG200DBOU0Q4O10@marigold.apple.com> for rtcweb@ietf.org; Thu, 04 Dec 2014 13:22:03 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: Date: Thu, 04 Dec 2014 13:22:02 -0800 Content-transfer-encoding: quoted-printable Message-id: <21A1F1F4-34A4-49D8-B649-A1C42E5F13BA@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> <1F326DF9-79C2-4562-853B-240D934EA235@apple.com> <949EF20990823C4C85C18D59AA11AD8B28CDFF@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: Roman Shpount X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUi2FAYpVt9oSHEYPp1Y4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0bLkNnvBI4GK2ZOusjUwnuftYuTkkBAwkfi54SM7hC0mceHe erYuRi4OIYG9jBL713UxwxSdfbGCHSIxiUli54e5UM58JonnO2YxdjFycDALqEtMmZIL0sAr oCfR9OQxE4gtLBAhcaTzDNgGNgFViQdzjjGC2JwCwRLf7x1mBbFZgOK3Xp4A28wsMJFRYsfW Q2AJZgFtiSfvLrBCDLWR2HznBwvE4sWsEk2rvrOBJESAuv9+n8wEcaqsxL+LZ8CukxD4yCqx 9NQs5gmMwrMQDpyF5MBZSHYsYGRexSiUm5iZo5uZZ6qXWFCQk6qXnJ+7iREUytPthHcwnl5l dYhRgINRiYe3YHd9iBBrYllxZe4hRmkOFiVxXrb6hhAhgfTEktTs1NSC1KL4otKc1OJDjEwc nFINjJuOTFB4POnR1HlXvrZViN4u+uFzwn9dKGuq0M7+mx7bhepcfik3WYqYL7n38udczfYj 1xk2vb2/+qrBn0dnE/5JvpzBqKXweek8g1sZLTMat0h4CHz/rG3/bfniC6qn4s7anv3DxKbw rEguT9EudeJ7w/qNtYUzUw5/qNw+cYJeS3X2b7/iuOtKLMUZiYZazEXFiQCUDfXHRgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUi2FDcopt+oSHEoOMFt8Xaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKaFlym73gkUDF7ElX2RoYz/N2MXJySAiYSJx9sYIdwhaTuHBv PVsXIxeHkMAkJomdH+ayQzjzmSSe75jF2MXIwcEsoC4xZUouSAOvgJ5E05PHTCC2sECExJHO M2CD2ARUJR7MOcYIYnMKBEt8v3eYFcRmAYrfenkCbAGzwERGiR1bD4ElmAW0JZ68u8AKMdRG YvOdHywQixezSjSt+s4GkhAB6v77fTITxKmyEv8unmGfwCgwC+GmWUhumoVk7AJG5lWMAkWp OYmVZnqJBQU5qXrJ+bmbGMGhVxi1g7FhudUhRgEORiUeXomd9SFCrIllxZW5hxglOJiVRHiN jzSECPGmJFZWpRblxxeV5qQWH2KU5mBREudNyQaqFkhPLEnNTk0tSC2CyTJxcEo1MOoHPeQ/ VR4a25D7Z3bprliJSVGPnvllT7gtYp3+PbDvZ6ZxSP/h7x2WPyeJcDZImAYc26v5Ttj2/iW2 yXzTlvP2m5ywqn/KGdnJbFejMe+W5fFFn3/9s2db4CiboyljsLJWhbGvd9ma7IslKyXt/T5k BrCxpc9qS7r0VGDhM1W56B7u0+INSizFGYmGWsxFxYkA8NkHnTkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0OrlsuLUvaIhqGQY2IbaaZIsKqo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 21:22:06 -0000 > On Dec 4, 2014, at 13:04 , Roman Shpount wrote: >=20 > On Thu, Dec 4, 2014 at 3:43 PM, DRAGE, Keith (Keith) = wrote: > As a tangent to this discussion, I'd note that pretty much every codec = implementor will be subject to additional IPR risk. This is because = pretty much all the standards specifications of codecs only specify the = decoder (VP8 included). Therefore any IPR claims and licences tied to = the specification will only have relevance to the decoder. >=20 > Unless you have a viable application that only needs the decoder, you = will have zero visibility in the standards IPR databases of what IPR = claims might exist against your coder implementation. >=20 > Everyone who uses the term "codec" in association with "royalty free" = or "IPR free" is misleading the world. What they mean is the decoder = only. >=20 >=20 > Actually Google does grant patent license to the implementation of = WebM, which includes both encoder and decoder = (http://www.webmproject.org/license/additional/). This is one of the = reasons we think VP8 license is better then H.264. (The other two are = reciprocity and no use restrictions on the produced media). It doesn=E2=80=99t take long to find the word =E2=80=9Cencoder=E2=80=9D = in the MPEG-LA summary: "SUMMARY OF AVC/H.264 LICENSE TERMS1 The AVC Patent Portfolio License is divided into two principal parts = (see Diagram): (a) sublicenses granting the right to manufacture and = sell AVC encoders and decoders=E2=80=A6=E2=80=9D That the specification only specifies the decoding process does not mean = that the license only applies to decoding. Those granting licenses = appear to grant them also for encoding, to my read. (IANAL). MPEG has taken the position that as long as you produce decodable, = conformant, bitstreams, you can encode how you like. Given that this = has resulted in substantial (I have heard 2X) performance improvements = in the life of codecs (MPEG-2 and I think AVC) this seems goodness to = me. David Singer Manager, Software Standards, Apple Inc. From nobody Thu Dec 4 13:56:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478FC1A6FA3 for ; Thu, 4 Dec 2014 13:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxTGO-n8Vykd for ; Thu, 4 Dec 2014 13:56:36 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D406C1A6F0A for ; Thu, 4 Dec 2014 13:56:27 -0800 (PST) Received: by mail-yk0-f177.google.com with SMTP id 9so8296934ykp.8 for ; Thu, 04 Dec 2014 13:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=s4uJTGIwzkjt4wzZVH1dSkUYgx+jP4geS8bIIv8f77o=; b=Le5VMwgQ8o/Zu9SPfOVRZMn9V4hnLw/gGSfkVo9uKDpJeEipK/Bm/v82qX1gEesUHm FTSFoc80paQ4kQr9luky3EDch4oQaZEn0K4n4Ym2fBQGxKrbu/g/wxQ+iM3X9sEzCZ5q 4gsQkNvRTug+v5uF+i6z8REVmuPu+7Gl5NJYez4eyYWvC00VHOPiaVANYmoqgNCao/si wGUyGCtFpzCwxhDC3H/y10LT6l3zyZrEVsqMzdcxNxzD2brKSR4CENv4NvW5T77OMgJq Q0djCDl/tNhKD/n4KMlMBUVjBXflAwq1h4dSGOF4nFpQ2qM2dCVvXlPKT7pCxdHCnfjy nuoA== X-Received: by 10.170.132.194 with SMTP id y185mr18192726ykb.97.1417730187076; Thu, 04 Dec 2014 13:56:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.170.135.193 with HTTP; Thu, 4 Dec 2014 13:56:06 -0800 (PST) In-Reply-To: <1F5B8077-0811-49FC-A168-398162B765F4@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> <1F326DF9-79C2-4562-853B-240D934EA235@apple.com> <1F5B8077-0811-49FC-A168-398162B765F4@apple.com> From: Silvia Pfeiffer Date: Fri, 5 Dec 2014 08:56:06 +1100 Message-ID: To: David Singer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1u_O8v5FBjFWVOZ20bxRErZxXKs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 21:56:38 -0000 On Fri, Dec 5, 2014 at 7:52 AM, David Singer wrote: > >> On Dec 4, 2014, at 12:40 , Silvia Pfeiffer w= rote: >> >> >> On 5 Dec 2014 07:30, "David Singer" wrote: >> > >> > >> > > On Dec 4, 2014, at 12:20 , Silvia Pfeiffer wrote: >> > > >> > > >> > > On 5 Dec 2014 06:25, "David Singer" wrote: >> > > > >> > > > >> > > > > On Dec 3, 2014, at 21:16 , Silvia Pfeiffer wrote: >> > > > > >> > > > > Indeed, that's why I said point 1. in David's list doesn't make = sense, since he's talking about a small company getting sued by Nokia. >> > > > >> > > > So, your conclusion to my question is =E2=80=9CShip VP8, most of y= ou probably won=E2=80=99t get sued. Good luck. Try not to be too successfu= l or your luck may change.=E2=80=9D >> > > >> > > Yes and it's the same answer as for h.264 and h.265 for that matter. >> > >> > It is not at all. Where are the =E2=80=9Cunwilling to license=E2=80= =9D statements for H.264? Where is the VP8 license coverage from the large= r players not in the MPEG-LA agreement? >> > >> > > Only add to that the extra licence fee you heavy to pay, which is a = certainty - the risk of getting sued is uncertain and frankly quite small c= ompared to other risks that you take as a small company. >> >> That can very nicely be construed as anticompetitive behaviour I would t= hink in my layman knowledge. It certainly doesn't look like playing fair. > > Sorry, I can=E2=80=99t work out what you say is not playing fair? Using = someone else=E2=80=99s patents and assuming that they will give everyone a = license? "unwilling to license" doesn't seem like they even want to make money with their patents. Since that is limited to patents that apply to one codec and not to any other codec, I can only interpret that as playing unfair. Note that this is my personal opinion and I don't think taking this discussion any further is useful in any way. :-) Silvia. From nobody Thu Dec 4 14:00:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74CC1A6FDF for ; Thu, 4 Dec 2014 14:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTYgjM9vzO8g for ; Thu, 4 Dec 2014 14:00:26 -0800 (PST) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A26B1A6FE1 for ; Thu, 4 Dec 2014 14:00:26 -0800 (PST) Received: by mail-qg0-f53.google.com with SMTP id q108so13203015qgd.40 for ; Thu, 04 Dec 2014 14:00:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=2fJCXnPOlxjds7rEY4vJaRrBJ7a/E58BDny2xZ28gaM=; b=YXzJmHTbQwI1ttOV6/CUzYF7ml2aWNi4M3AUWBn2LRzuUZoCp14ETT4VbRe3z2t8Bm p5/bTx0pbNzwrLllox2Rsyw7uzhp7clZ7xGAVSIY1jDBgoks4zG2YHkeRvsNEr/wo3PW PRjzIN+G1ScZMps5xh+6pqTHKsEmAFVfxFrxha92TLvbv+anXEBM+Klrqk8GNIlJ2u9y 4glIzflUpObTjjSE71UiEc9Oq3TXAOfH3hLYDGTcWAbxBoOSTaOPorsQK4pCHcr5pZ14 AIYtQmNGYTJBPkPM919VsR4AV+TKHdek5gtwUXRpMikfIPvvXObJ+V3hp7xhYUQxoCvN 2qFQ== X-Gm-Message-State: ALoCoQll+d5jjCC/7PIpNffyrk+B5GFp9+fTRSOavrp4bmgT01W0yKApWTrCR6iKnwSYN3qfwd6B X-Received: by 10.224.22.196 with SMTP id o4mr17661590qab.85.1417730420049; Thu, 04 Dec 2014 14:00:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Thu, 4 Dec 2014 13:59:59 -0800 (PST) In-Reply-To: <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 4 Dec 2014 22:59:59 +0100 Message-ID: To: David Singer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-UtR9TYDso5G6g-OtuT0fjN8rWw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 22:00:31 -0000 2014-12-03 19:33 GMT+01:00 David Singer : > As I understand it, the recent face to face meeting decided to draft the = requirement that WebRTC browsers be required to implement both VP8 and H.26= 4, and get feedback on this, on the list. > > This is some feedback. I've been searching in both the rtcweb and public-webrtc mailing lists, and must say that it is VERY SAD that the only "contribution" and "feedback" received from Apple are these regarding "MTI codecs", nothing else. I hope Apple has better things to do than sending FUD to working groups in which they have no interest. --=20 I=C3=B1aki Baz Castillo From nobody Thu Dec 4 14:01:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53151A1B8C for ; Thu, 4 Dec 2014 14:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1zNrde5BkS2 for ; Thu, 4 Dec 2014 14:01:47 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD78C1A1EEA for ; Thu, 4 Dec 2014 14:01:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417730507; x=2281644107; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tcpjkWKK00S+Lozrz1WiqS71BR4U/UIE5PX3WXC1Xto=; b=gLnlcRIqk6NNTQSwm/GvIsa+BO+FKtTvz077mRcI4F6tFfuHrktMlZBItMeFKMZq 9DxAGQn+85gBSUWS8JuyKpBorKwoh6+uCY9flyJnTXS7g+ZkJv0vIbxfTH/0Rn6L u/Cc38APfIyK+vVzPfLZzUJQgcanPRZwkjyUfj4+Hk2sVcNtUvjoiml118uJt223 ZoGvrZyEmKqxvtBgwWe+PkR5bYG/p/zHjwEJEXyLYm3Uw1P8cy54Xlg2/YZfD7Xw cGpOeToT3gEmQE2aQAWvuffyPoDrDlyNqYHCO2nOQCejivZ8aBhxEODP5CDK8i2N OzEFK/Q1p/G+79jFo6QtJA==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 9D.2A.18524.BC9D0845; Thu, 4 Dec 2014 14:01:47 -0800 (PST) X-AuditID: 11973e15-f79476d00000485c-a7-5480d9cb67f2 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 66.6E.06123.CC9D0845; Thu, 4 Dec 2014 14:01:48 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG200D57VUY4O30@marigold.apple.com> for rtcweb@ietf.org; Thu, 04 Dec 2014 14:01:46 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: Date: Thu, 04 Dec 2014 14:01:46 -0800 Content-transfer-encoding: quoted-printable Message-id: <5FA32856-A066-4656-B6BE-2C1602EF1E26@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> <1F326DF9-79C2-4562-853B-240D934EA235@apple.com> <1F5B8077-0811-49FC-A168-398162B765F4@apple.com> To: Silvia Pfieffer X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUi2FAYoXv6ZkOIwZQTzBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4+SmG0wFc8Qrpjf/YGpgvCrUxcjJISFgIrHi6zkWCFtM4sK9 9WxdjFwcQgJ7GSXWPbnPDFO0srEVzBYSmMQk0f/PGqJoPpPE7T3tQAkODmYBdYkpU3JBangF 9CSanjxmArGFBSIkjnSeYQex2QRUJR7MOcYIYnMKBEucPTwZLM4CFH/fcpcRYoyvxOTrUSBh ZgFtiSfvLrBCjLSR+HO8hwli7RlWibZpE8DuERHQl1i25xA7xJ2yEv8uguziArLfskqsPnCX dQKj8CyE82YhOW8Wkh0LGJlXMQrlJmbm6GbmmeklFhTkpOol5+duYgQF8XQ70R2MZ1ZZHWIU 4GBU4uEt3F0fIsSaWFZcmXuIUZqDRUmcl62+IURIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD 4xSJPtuVh0N2v3t75sPlS2ZK4j/bVdJPHpWcs3m2r8K8GPkJT2/mGz85y6YtnHfSau/p3Pv8 Z4Szt3KGpzjmLK53ex0498Fq5zx9XVmrhU8sKnyjfteuzPz04VpzqUrMk97VP4T2299S38y5 9e3Ll+HHl92enqVza+/p3xO+TOyubF2rorXRtlmJpTgj0VCLuag4EQCzUH9UQwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FDconvmZkOIwcJpRhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4+SmG0wFc8Qrpjf/YGpgvCrUxcjJISFgIrGysZUZwhaTuHBv PRuILSQwiUmi/591FyMXkD2fSeL2nnagIg4OZgF1iSlTckFqeAX0JJqePGYCsYUFIiSOdJ5h B7HZBFQlHsw5xghicwoES5w9PBkszgIUf99ylxFijK/E5OtRIGFmAW2JJ+8usEKMtJH4c7yH CWLtGVaJtmkTwG4TEdCXWLbnEDvEnbIS/y6eYZ/AKDAL4aJZSC6ahWTsAkbmVYwCRak5iZWm eokFBTmpesn5uZsYwUFXGLGD8f8yq0OMAhyMSjy8BbvrQ4RYE8uKK3MPMUpwMCuJ8BofaQgR 4k1JrKxKLcqPLyrNSS0+xCjNwaIkzluVDVQtkJ5YkpqdmlqQWgSTZeLglGpgPKPrHfBsr2Te pA3rvL6eDnv2r8tfTyv89nZB4QvKzj9lX5kmPAoRrl5j9ezCpNuTrmz+m63N9ObFu2L/y4uT sz563+FsKp19+42i2719Kk/C634r1Emt7ct4x3zm3cnczNRfmxf9mKrnlfhsTW/xvyOlr9+y ajeLyJueFxPaztOlfbAz4e6zS0osxRmJhlrMRcWJAG9qkrU2AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/SuVzAm76ouk8HvPxIHudOFRj3cQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 22:01:50 -0000 > On Dec 4, 2014, at 13:56 , Silvia Pfeiffer = wrote: >=20 > On Fri, Dec 5, 2014 at 7:52 AM, David Singer wrote: >>=20 >>> On Dec 4, 2014, at 12:40 , Silvia Pfeiffer = wrote: >>>=20 >>>=20 >>> On 5 Dec 2014 07:30, "David Singer" wrote: >>>>=20 >>>>=20 >>>>> On Dec 4, 2014, at 12:20 , Silvia Pfeiffer = wrote: >>>>>=20 >>>>>=20 >>>>> On 5 Dec 2014 06:25, "David Singer" wrote: >>>>>>=20 >>>>>>=20 >>>>>>> On Dec 3, 2014, at 21:16 , Silvia Pfeiffer = wrote: >>>>>>>=20 >>>>>>> Indeed, that's why I said point 1. in David's list doesn't make = sense, since he's talking about a small company getting sued by Nokia. >>>>>>=20 >>>>>> So, your conclusion to my question is =E2=80=9CShip VP8, most of = you probably won=E2=80=99t get sued. Good luck. Try not to be too = successful or your luck may change.=E2=80=9D >>>>>=20 >>>>> Yes and it's the same answer as for h.264 and h.265 for that = matter. >>>>=20 >>>> It is not at all. Where are the =E2=80=9Cunwilling to license=E2=80=9D= statements for H.264? Where is the VP8 license coverage from the = larger players not in the MPEG-LA agreement? >>>>=20 >>>>> Only add to that the extra licence fee you heavy to pay, which is = a certainty - the risk of getting sued is uncertain and frankly quite = small compared to other risks that you take as a small company. >>>=20 >>> That can very nicely be construed as anticompetitive behaviour I = would think in my layman knowledge. It certainly doesn't look like = playing fair. >>=20 >> Sorry, I can=E2=80=99t work out what you say is not playing fair? = Using someone else=E2=80=99s patents and assuming that they will give = everyone a license? >=20 > "unwilling to license" doesn't seem like they even want to make money > with their patents. Since that is limited to patents that apply to one > codec and not to any other codec, I can only interpret that as playing > unfair. Note that this is my personal opinion and I don't think taking > this discussion any further is useful in any way. :-) Got you. Notwithstanding that I agree that the discussion seems to be = due to taper off, and noting that I have no idea what Nokia=E2=80=99s = motivation is, I also note that sometimes people offer licenses only in = some cases (e.g. for a specific international standard) as a way to try = to bring interoperability and convergence to the industry. =E2=80=9CYou = can use my nice idea only if you implement X in an interoperable = fashion=E2=80=9D. I actually think that this is one of the better uses = of IPR, as it helps converge into interoperable playing fields. Of course, when X is not free, this is then problematic for those who = prefer free. I recognize that. David Singer Manager, Software Standards, Apple Inc. From nobody Thu Dec 4 14:03:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED84B1A6F0A for ; Thu, 4 Dec 2014 14:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4NoV7OD22ei for ; Thu, 4 Dec 2014 14:03:52 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1208D1A1EF0 for ; Thu, 4 Dec 2014 14:03:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417730625; x=2281644225; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=UKnEpkECvkWkP8CL/1JixiKngi15lkfLNr1jN3cPupk=; b=h/oNixn7616nkTvPp8NzzbTdmW2umO2rGChsMt6FicUF05xn8Jx09Aeq0WNkBFmu 2kFzIw9hRUZCr9StENGDU+hjucLb5Q9faZEJTr/h67c9DnIAoJEaFWabLr1PAmxb TYoUczBt2kCIZKzSGrjnE0600WMOEEgRW2QvdKySI/mF4XuXvfitkTBOEMILs7df rWQSTC2C34V+H/RDGabdYAao06RPqKGZ+4a+ZJiLyooNLuhhzcnFuKxV3DKmWU1w WyAlZO1L2ShbQ+iRCDe9Da87rUhLHNTV5LFS6+dlfg6QPCdfgr6P5eQu8LS+j1R9 GREFUGWfSu9DYEauhDmW1Q==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 79.8B.06819.14AD0845; Thu, 4 Dec 2014 14:03:45 -0800 (PST) X-AuditID: 11973e13-f79656d000001aa3-e6-5480da4171e7 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 78.CF.06123.34AD0845; Thu, 4 Dec 2014 14:03:47 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG200D95VY94O30@marigold.apple.com> for rtcweb@ietf.org; Thu, 04 Dec 2014 14:03:45 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: Date: Thu, 04 Dec 2014 14:03:44 -0800 Content-transfer-encoding: quoted-printable Message-id: <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUi2FAYoet4qyHEYM1fLYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsez8JsaCqxwV3//fYm5g/MLWxcjJISFgInHg1komCFtM4sK9 9WBxIYG9jBL3TifC1Kw+NwOohgsoPolJovnFD2YIZz6TxM3jb1i6GDk4mAXUJaZMyQVp4BXQ k2h68hhsqLBAhMSRzjPsIDabgKrEgznHGEFsToFgiUdvTzCD2CxA8ZkH+1lAbJAxSyc3sEHY 2hJP3l1ghZhpI7Hy7n+ovY8YJXoXT2YG2SsiYC6xaJIcxKGyEv8uguziArLfskqsfr2EaQKj 8CyE82YhOW8WkhULGJlXMQrlJmbm6GbmmeolFhTkpOol5+duYgQF8XQ74R2Mp1dZHWIU4GBU 4uEt2F0fIsSaWFZcmXuIUZqDRUmcl62+IURIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY9aR zoK55nIllXZKndx/j1TZfl1q8/F/BSdXfvHKvy8+sSz+lhrzxVNp3h69i1Ll9vVHt/bdU4y1 dVzx5PCXDTPW5C3ZsKNQxv/1AtNl80T7y2frL36qHr3tmlvSbqmTb87MjpYRyCs+ty3F7tbu 74fCln6xPeN65KTBsr77Bb9/7dZ4zhC58LgSS3FGoqEWc1FxIgChLMJCQwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FDcout8qyHEYPYqBYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsez8JsaCqxwV3//fYm5g/MLWxcjJISFgIrH63AwmCFtM4sK9 9UBxLg4hgUlMEs0vfjBDOPOZJG4ef8PSxcjBwSygLjFlSi5IA6+AnkTTk8dgzcICERJHOs+w g9hsAqoSD+YcYwSxOQWCJR69PcEMYrMAxWce7GcBsUHGLJ3cwAZha0s8eXeBFWKmjcTKu/+h 9j5ilOhdPJkZZK+IgLnEoklyEIfKSvy7eIZ9AqPALISLZiG5aBaSqQsYmVcxChSl5iRWmuol FhTkpOol5+duYgSHXWHEDsb/y6wOMQpwMCrx8Bbsrg8RYk0sK67MPcQowcGsJMJrfKQhRIg3 JbGyKrUoP76oNCe1+BCjNAeLkjhvVTZQtUB6YklqdmpqQWoRTJaJg1OqgdFjE2+066RmyY/z 3Gv3bfxvmBHy4HbVpD1xDTFvv86r+VVfs4/334nEEB/Np0eupklpmGx4VrOkLs3BMOpIWJlh UeZxCeGgQz9UF2YuMLY8MEu8Xi64epXTOb1Ca5HOcL8bhZ8frz8aKOz1RYrrVv3N+0dPHv+4 U7zGxGL91LWvVm5puvD/yyIlluKMREMt5qLiRACVrUW2NwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1qrxWWWhtQOSTfTGBHaQoNjeLJg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 22:03:53 -0000 > On Dec 4, 2014, at 13:59 , I=C3=B1aki Baz Castillo = wrote: >=20 > 2014-12-03 19:33 GMT+01:00 David Singer : >> As I understand it, the recent face to face meeting decided to draft = the requirement that WebRTC browsers be required to implement both VP8 = and H.264, and get feedback on this, on the list. >>=20 >> This is some feedback. >=20 > I've been searching in both the rtcweb and public-webrtc mailing > lists, and must say that it is VERY SAD that the only "contribution" > and "feedback" received from Apple are these regarding "MTI codecs", > nothing else. >=20 > I hope Apple has better things to do than sending FUD to working > groups in which they have no interest. I apologize for both the fact that you think this is FUD, and for the = lack of other engagement. Quite where you see the uncertainty and doubt in the =E2=80=9Cyou MUST = implement something which, it is stated, is subject to IPR which CANNOT = be licensed=E2=80=9D, I am less sure. Fear, yes, I get that. David Singer Manager, Software Standards, Apple Inc. From nobody Thu Dec 4 14:21:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB081A6FEB for ; Thu, 4 Dec 2014 14:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yEsNmxqWmZu for ; Thu, 4 Dec 2014 14:21:50 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD271A1BA4 for ; Thu, 4 Dec 2014 14:21:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417731709; x=2281645309; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+1Ti9f3fc8/qlxfRWgXV3bPnl26EVGUX0mykotkUr5s=; b=yMTmeiJeNQ3b87ZbQai/0Cz41uCiSOLY4lGMVR28TVZwF/RsMkhd8KtWUSwcd4Zv qqvbw+hv39OlVFHyh4+XhhPLZxAO7MmdLdLqryK8wcpGoksO/HUWNWae+Kd+wYCi txWV/JfuczXiD6x7pi4t4V/nnyGnhq5u8lfryFo8BjlvG6od4CWk3aRWcXPT6+1Z gZUNVvw7IGsdZyS2/5khk6gc7YDtTrrInZOTf3POd4IXt2ZjvDE8mcROvDB54Ojp ZVx57Nt2fQXDhdlEaMaeQjqiYcRGUT32lqJcfA8WramJz9GYvKbdWML/U4ShRXrR pUBcnWnYNQ49FsRC/hDAww==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id A0.5F.06819.D7ED0845; Thu, 4 Dec 2014 14:21:49 -0800 (PST) X-AuditID: 11973e13-f79656d000001aa3-23-5480de7dd7fa Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 2F.24.06091.E5ED0845; Thu, 4 Dec 2014 14:21:18 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG2005DKWSD6L60@marigold.apple.com> for rtcweb@ietf.org; Thu, 04 Dec 2014 14:21:49 -0800 (PST) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <5480C531.5050104@bbs.darktech.org> Date: Thu, 04 Dec 2014 14:21:48 -0800 Content-transfer-encoding: quoted-printable Message-id: <0C44FAD4-08C9-43FE-84BE-3B09C993443F@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> <5480C531.5050104@bbs.darktech.org> To: cowwoc X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FCYqlt7ryHEYOItLYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMfdOL2NBN3vF94k2DYznWbsYOTkkBEwkPi15yAhhi0lcuLee rYuRi0NIYB+jxNv535hhiuasf8QEkZjEJLH1fB8jhDOfSeL/sz4mkCpmAS2J9TuPg9m8AnoS TU8eg9nCAhESRzrPsIPYbAKqEg/mHANq5uDgFDCQOHzVASTMAhQ+0PSREWKMsMT3x/dYIGxt iSfvLrBCjLSRuHbkISvE3o0sEsueLAQrEhFQkbhx7BY7xKWyEv8uguziArJfskps3r2NeQKj 8Cwk981Cct8sJEsWMDKvYhTKTczM0c3MM9VLLCjISdVLzs/dxAgK5Ol2wjsYT6+yOsQowMGo xMNbsLs+RIg1say4MvcQozQHi5I4L1t9Q4iQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxvXz 5Ft0vZ9XWVXl+j45xaZ4YVL+QanV/6r0Mr5zdr+MfFifdfRXatCpwoYVPuxpmlOL9+2qftE2 51Mwj3zdwlhTp+eH75jwus27uvR25W/7bXHcaX85HqZmr9j7PZFdd76ZVULsi3PzwrVF/B2v yjikzTAv/dccI93yovine0H+mqOPl7TMUGIpzkg01GIuKk4EADkVDgFFAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcoht3ryHE4PlpI4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMfdOL2NBN3vF94k2DYznWbsYOTkkBEwk5qx/xARhi0lcuLee rYuRi0NIYBKTxNbzfYwQznwmif/P+sCqmAW0JNbvPA5m8wroSTQ9eQxmCwtESBzpPMMOYrMJ qEo8mHMMqJmDg1PAQOLwVQeQMAtQ+EDTR0aIMcIS3x/fY4GwtSWevLvACjHSRuLakYesEHs3 skgse7IQrEhEQEXixrFb7BCXykr8u3iGfQKjwCwkJ81CctIsJHMXMDKvYhQoSs1JrDTXSywo yEnVS87P3cQIDrzC1B2MjcutDjEKcDAq8fBK7qwPEWJNLCuuzD3EKMHBrCTCa3ykIUSINyWx siq1KD++qDQntfgQozQHi5I4b1Q2ULVAemJJanZqakFqEUyWiYNTqoGRJ2J7oVDXXOG1D0Wb XtXJ7nYrW9PxLyaRQbdVTDXQtfz3sf6AZ/VpBd4TV607elEnM750cr9H2XuTytW6d++zbvLb oSTwedeqoLsmVVGub1ZcZNjKt9r/ZVFm9tLVe49bubxNy8o+dKhKsOljg6PuxXnMchUi5vK2 pR6VfOp6nZ+0TtS3GCixFGckGmoxFxUnAgD40b4VOAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/p1umvmLI-4-Bixb8WZH9GQ4NzSQ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 22:21:53 -0000 > On Dec 4, 2014, at 12:33 , cowwoc wrote: >=20 > A formal "unwilling to license" without any factual information to = back it up is practically meaningless. They supply a (long) list of actual patents. That is quite a bit of = factual information. (Rather too much for some people, and not enough = for others, I suspect; a lot of work to read them, and not specific = reasons why they think those patents apply. But you take what you can = get, and the formal process only asks for the patent numbers.) > What is the legal difference between a company that does that and a = company who sues using a previously-undeclared H.264 IPR? Well, in one case you were put on formal notice, and in the other, it = was a situation you were previously unaware of. IANAL but I think this = makes a difference. David Singer Manager, Software Standards, Apple Inc. From nobody Thu Dec 4 14:30:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5821A7020 for ; Thu, 4 Dec 2014 14:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmrpsfprnbpL for ; Thu, 4 Dec 2014 14:30:53 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E0101A7010 for ; Thu, 4 Dec 2014 14:30:53 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id k15so12336631qaq.38 for ; Thu, 04 Dec 2014 14:30:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=WFTxMYVJNATA3pgQNAyH15uzpF4W1xLVRrS4/uwmXE4=; b=JvldLERuUux1Rh84lIRWD+2r2xQb7/QoujgX+j3qTLvtYVcIkLDnHgtZR/++cF5blj vwOASdBj2534t8aVAprXVTb5oF9BKadKoK82Dpb0+zEtqn/yqvHSNEfEjcim5a3TnwYb Q/XFleArGv5HrrLS0ATkoGVScXCG812Zgq0rmAcuXS88YkiBLlDbjaC8VJi1vt7oxMYz izW4MbW+s76OBCEr48ATj1ixVcvqgdRyGi/aJmqWXdv7HXcFgiKcQ9MVlRGOunTiLbKX O4G20r4UP6lIGI3nQTWNCyp7HW5YpsIwVlAZ9XIsRDhTyul7avPRxL5syGhqaFXbbcBZ E1GQ== X-Gm-Message-State: ALoCoQmPldscEOa+JIXeoWOdL9GWOA9sZlWGVbz/rV/wL8Igqy1kx1raAEOgS213v1kNvnDjjPXu X-Received: by 10.224.22.196 with SMTP id o4mr17857164qab.85.1417732252549; Thu, 04 Dec 2014 14:30:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Thu, 4 Dec 2014 14:30:32 -0800 (PST) In-Reply-To: <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 4 Dec 2014 23:30:32 +0100 Message-ID: To: David Singer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Z6Dw2NwiYBLWfkrHw_75l2HuqMw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 22:30:54 -0000 2014-12-04 23:03 GMT+01:00 David Singer : > Quite where you see the uncertainty and doubt in the =E2=80=9Cyou MUST im= plement something which, it is stated, is subject to IPR which CANNOT be li= censed=E2=80=9D, I am less sure. Fear, yes, I get that. Just to clarify, I'm not in favor of mandating non 100% royalty-free codecs in a W3C specification. --=20 I=C3=B1aki Baz Castillo From nobody Thu Dec 4 14:36:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0719F1A1A75 for ; Thu, 4 Dec 2014 14:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2ClM9qZ45AC for ; Thu, 4 Dec 2014 14:36:22 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7C61A7020 for ; Thu, 4 Dec 2014 14:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417732579; x=2281646179; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5PE8yc6DmmqA0d5vhCgBNKGo0F4ZfvoOrQPAd7oGpig=; b=I6IGNwm6SZc9Xlwo26tMSW2C54BiCf+olr/ufsFurgitSWutTpOaPZYeHWKWd5F8 iWuQGXfgQQWQ6UAqnG5c9DZoabTU0HWL7z3t2SXu5+6a4RbbJEAAOZmecYW7MjjJ vYDUvkzc+a5Nas0PnssejabqWv/PlVNnDJ0Ly6moHTh8ixXlbAe9DholTX/6jR+X NLz3d/lno2uQ/V5WrtSLuSTTVUwiNQ+9PEmNSFtxosnAyjb1dIXVgmt8w5zokMYB z+RfGYssisL9aGx712P8/dIhIFBmrUjkCGyJMBHb+BC7+HJwlKQebvNiJ5Jey97t /HZcWCen7NQxzYWoRudwew==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 82.B2.12074.3E1E0845; Thu, 4 Dec 2014 14:36:19 -0800 (PST) X-AuditID: 11973e12-f79f86d000002f2a-97-5480e1e33a56 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 14.E1.05452.6E1E0845; Thu, 4 Dec 2014 14:36:22 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG200DQ9XGJ4O40@marigold.apple.com> for rtcweb@ietf.org; Thu, 04 Dec 2014 14:36:19 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: Date: Thu, 04 Dec 2014 14:36:18 -0800 Content-transfer-encoding: quoted-printable Message-id: <4A0ABA0E-3D2C-49D6-9FC4-71F725531738@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FCYpvv4YUOIwaoJhhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY8ut52wFR9kqJq+4wN7AOI+1i5GTQ0LAROLu47csELaYxIV7 69m6GLk4hAT2MUo8f76VCabowYLVTBCJSUwSN7rXMEM485kknh45BuRwcDALqEtMmZIL0sAr oCfR9OQxWLOwQITEkc4z7CA2m4CqxIM5xxhBbE6BYIn2h2fArmABip+YswWsHmTM0skNbBC2 tsSTdxdYIWbaSDTfe8cCsfcOk8Tdz0/YQPaKCJhLLJokB3GorMS/iyC7uIDsl6wSj86/Z53A KDwL4bxZSM6bhWTFAkbmVYxCuYmZObqZeSZ6iQUFOal6yfm5mxhBYTzdTmgH46lVVocYBTgY lXh4C3bXhwixJpYVV+YeYpTmYFES52WrbwgREkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwFhj NyX0XNOuRYvMs04nXTy6VrJAfecNxaTk/quHZUxfW7Z8ZWy3W1UiZd9vdulYga3ZnAvu67bN FWvJcTIXZzA2yc6UyWe9aujbmnTzssw3gf9ravsezZyZ+NJrldaN5wtnzr2ZkLdK9OnZ7f3L frb7yOR/eFIY2zxd8URXpaPPARX7l3cmfFZiKc5INNRiLipOBAAjQV2LRAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FDcovvsYUOIQVuzicXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK2HLrOVvBUbaKySsusDcwzmPtYuTkkBAwkXiwYDUThC0mceHe erYuRi4OIYFJTBI3utcwQzjzmSSeHjkG5HBwMAuoS0yZkgvSwCugJ9H05DFYs7BAhMSRzjPs IDabgKrEgznHGEFsToFgifaHZ8CWsQDFT8zZAlYPMmbp5AY2CFtb4sm7C6wQM20kmu+9Y4HY e4dJ4u7nJ2wge0UEzCUWTZKDOFRW4t/FM+wTGAVmIVw0C8lFs5BMXcDIvIpRoCg1J7HSQi+x oCAnVS85P3cTIzjsCtN2MDYttzrEKMDBqMTDW7C7PkSINbGsuDL3EKMEB7OSCK/xkYYQId6U xMqq1KL8+KLSnNTiQ4zSHCxK4rzV2UDVAumJJanZqakFqUUwWSYOTqkGxpCsoIyHh/4FnLhj ln2vLGXueSMV82bzSA15xu1S+YueTj8qv+7906cL/dxLJn6JNarbV8DwRCrZVe+FgP8y7t4l zIo9nHmtL8Le19zgPu1iW7lV/ERGoLTHB/3pe7Y5tWRtsrpcL7F9gVFbCM/Z4JKe6sk/hP9K y8d3Sf6ZfuiL6+oDFp9qlViKMxINtZiLihMBAHt3KTcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/h5DJ-BSxyR279zPNYXZUkaWwJLg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 22:36:26 -0000 > On Dec 4, 2014, at 14:30 , I=C3=B1aki Baz Castillo = wrote: >=20 > 2014-12-04 23:03 GMT+01:00 David Singer : >> Quite where you see the uncertainty and doubt in the =E2=80=9Cyou = MUST implement something which, it is stated, is subject to IPR which = CANNOT be licensed=E2=80=9D, I am less sure. Fear, yes, I get that. >=20 > Just to clarify, I'm not in favor of mandating non 100% royalty-free > codecs in a W3C specification. I understand and respect that. I would also prefer not to mandate an RF = codec; I just can=E2=80=99t find one. I don=E2=80=99t like the = situation at all. =20 I just don=E2=80=99t see the current proposed wording as solving = anything, and in fact, it makes the problem worse, not better. David Singer Manager, Software Standards, Apple Inc. From nobody Thu Dec 4 15:02:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CEE1A8749 for ; Thu, 4 Dec 2014 15:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66rVaNsQyall for ; Thu, 4 Dec 2014 15:02:44 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9B01A8746 for ; Thu, 4 Dec 2014 15:02:44 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id BE40B2BE58883; Thu, 4 Dec 2014 23:02:38 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sB4N2gRk014668 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Dec 2014 00:02:42 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 00:02:42 +0100 From: "DRAGE, Keith (Keith)" To: "Timothy B. Terriberry" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) Thread-Index: AQHQEAXmSNqBPks4zU2cSbL9+QhOa5x/3g0AgAAsGJA= Date: Thu, 4 Dec 2014 23:02:41 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B28CF6B@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> <1F326DF9-79C2-4562-853B-240D934EA235@apple.com> <949EF20990823C4C85C18D59AA11AD8B28CDFF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5480CEF2.4020204@mozilla.com> In-Reply-To: <5480CEF2.4020204@mozilla.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EQIOQxiJ9lyagdFGSj2A_LhhdQw Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 23:02:50 -0000 Both yours and David's responses to this are outside the IPR gathering exer= cise that forms part of the standards process. The idea of the standards process is that a group of vendors etc write a st= andard, they are forced to declare their IPR involved in that standard. If = the population is sufficiently large you stand a good chance of identifying= all the worldwide IPR relating to that standard. The bigger the standards organisation, with the greater coverage of all the= vendors in that space, the better the process works. So at that level, IPR knowledge for codecs is primarily on the decoder spac= e and what IPR exists there. What Tim is saying (and a somewhat parallel situation exists with MPEG LA) = is that a limited set of organisations will limit your IPR problems and giv= e you some help with the encoder IPR. For VP8 that is limited to Google's I= PR and any background research they may have done. For MPEG LA it is limite= d to the members of the pool, which is only a subset of those involved in t= he parallel standards process. Yes it helps, but it does not have the degre= e of confidence of identifying all the existing IPR that the standards proc= ess would do. Regards Keith =20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20 > Timothy B. Terriberry > Sent: 04 December 2014 21:16 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Finishing up the Video Codec document,=20 > MTI (again, still, sorry) >=20 > Roman Shpount wrote: > > Actually Google does grant patent license to the implementation of=20 > > WebM, which includes both encoder and decoder=20 > > (http://www.webmproject.org/license/additional/). This is=20 > one of the=20 > > reasons we think VP8 license is better then H.264. (The=20 > other two are=20 > > reciprocity and no use restrictions on the produced media). >=20 > Serge also confirmed on this list that that license applies=20 > to third-party implementations as well:=20 > https://www.ietf.org/mail-archive/web/rtcweb/current/msg04006.html >=20 > The Opus licenses similarly grant rights to patents that read=20 > on the reference implementation, including the encoder, even=20 > if used in a third-party implementation. >=20 > Now, it's certainly possible to infringe other people's IPR=20 > by implementing an encoder sufficiently different from the=20 > reference encoder. One must be very careful when doing that.=20 > But these reference implementations are production-grade.=20 > Anyone who merely wishes to deploy a codec has an=20 > implementation they can use with just as much assurance of=20 > the IPR safety of the encoder as they have of the decoder. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From nobody Thu Dec 4 15:16:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0A21A6FD1 for ; Thu, 4 Dec 2014 15:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZVowdfag-bV for ; Thu, 4 Dec 2014 15:16:31 -0800 (PST) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE61F1A6F0D for ; Thu, 4 Dec 2014 15:16:30 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id hq12so8206534vcb.41 for ; Thu, 04 Dec 2014 15:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=by+pKuGy5zcNNW6wg8oC9BWP2qA241r1mlwU2RKaq1Q=; b=El743TJ9WzvAu+YhtWRlPkksjVde3btw67fdqh737RY/fhC0ImPuDAHJWr+UrIsHsG FcaFCojCtGRuCcSZChQq/iaRGaJKJo+PoXo8xCQEoC9WZhakXK9Zaz56Azp+sUIjnClw 6BpfB9gA4uHuEHxnDl0ie8A/2UIIRonYMTD3ltrCGfAe+WKyS3fHRrGj51j8dMRnZw63 vV67oAxITT4gxSysUybc82Bvto+DeqffKd/77/HXblupNIdyv4Tbm40wGr+reQgpgUCK 26+fwp49ihMjuc4BHYEiJvoTak+xAA+lnsDWzzGehj4ShxP9/WcxfRrXxZE7C+aX58ex 6mDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=by+pKuGy5zcNNW6wg8oC9BWP2qA241r1mlwU2RKaq1Q=; b=FMilDHS1Rr7kR2V5zQtv0igSsgv6PC/HMo3E96MJ8cvaU2JJH8OhZ4hdh384PoWapC Nmplg0pDLAnxSgHf1mI9GtbTMq6fDxRGYF7fmsxhIe5qmsAx5qj/4O5Pz4hspG1qWcFh 0+kN4MTQ11ZbdLS4ZnXEQY5GFTxMpCgVu3/2yWAdFHBfVbHsPZrzo6H70/fIGV7kqKYz CcYCsf1heVvsJJQyPKcFlfP5G5/kwfVYFmBHc3xsfRdIGPvzzxDGSMtrwqKXnWyEIgOS iX3OpEx6T83T9vnlMeRzBAhGbBpDAn+NrTIOUnVdm9b4MlPux9fdRiBn1fqEXcrl+Dzc xtgQ== X-Gm-Message-State: ALoCoQlcbs+3EPhfEGmapzeCknSrZmqKF+G8065wG5C0tRyabXqbASoQ8KP7yD5jsjPJv8Z36Tuk X-Received: by 10.52.117.161 with SMTP id kf1mr5590018vdb.65.1417734989875; Thu, 04 Dec 2014 15:16:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Thu, 4 Dec 2014 15:16:09 -0800 (PST) In-Reply-To: <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> From: Justin Uberti Date: Thu, 4 Dec 2014 15:16:09 -0800 Message-ID: To: David Singer Content-Type: multipart/alternative; boundary=bcaec547cbdd751f8d05096c2667 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-kM2U4741bQWHg3RQBy5vUCrQ1w Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2014 23:16:32 -0000 --bcaec547cbdd751f8d05096c2667 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 4, 2014 at 2:03 PM, David Singer wrote: > > > On Dec 4, 2014, at 13:59 , I=C3=B1aki Baz Castillo wrot= e: > > > > 2014-12-03 19:33 GMT+01:00 David Singer : > >> As I understand it, the recent face to face meeting decided to draft > the requirement that WebRTC browsers be required to implement both VP8 an= d > H.264, and get feedback on this, on the list. > >> > >> This is some feedback. > > > > I've been searching in both the rtcweb and public-webrtc mailing > > lists, and must say that it is VERY SAD that the only "contribution" > > and "feedback" received from Apple are these regarding "MTI codecs", > > nothing else. > > > > I hope Apple has better things to do than sending FUD to working > > groups in which they have no interest. > > I apologize for both the fact that you think this is FUD, and for the lac= k > of other engagement. > > Quite where you see the uncertainty and doubt in the =E2=80=9Cyou MUST im= plement > something which, it is stated, is subject to IPR which CANNOT be licensed= =E2=80=9D, > I am less sure. Fear, yes, I get that. > > I don't see others being deterred by the alleged uncertainty; there was quite a broad consensus for this at IETF 91. But again, if this is a particularly sensitive issue for your employer, I think there are many potential solutions we can discuss. --bcaec547cbdd751f8d05096c2667 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 4, 2014 at 2:03 PM, David Singer <singer@apple.com><= /span> wrote:

> On Dec 4, 2014, at 13:59 , I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
>
> 2014-12-03 19:33 GMT+01:00 David Singer <singer@apple.com>:
>> As I understand it, the recent face to face meeting decided to dra= ft the requirement that WebRTC browsers be required to implement both VP8 a= nd H.264, and get feedback on this, on the list.
>>
>> This is some feedback.
>
> I've been searching in both the rtcweb and public-webrtc mailing > lists, and must say that it is VERY SAD that the only "contributi= on"
> and "feedback" received from Apple are these regarding "= ;MTI codecs",
> nothing else.
>
> I hope Apple has better things to do than sending FUD to working
> groups in which they have no interest.

I apologize for both the fact that you think this is FUD, and for th= e lack of other engagement.

Quite where you see the uncertainty and doubt in the =E2=80=9Cyou MUST impl= ement something which, it is stated, is subject to IPR which CANNOT be lice= nsed=E2=80=9D, I am less sure.=C2=A0 Fear, yes, I get that.


I don= 't see others being deterred by the alleged uncertainty; there was quit= e a broad consensus for this at IETF 91. But again, if this is a particular= ly sensitive issue for your employer, I think there are many potential solu= tions we can discuss.
--bcaec547cbdd751f8d05096c2667-- From nobody Thu Dec 4 16:23:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B053E1A883A for ; Thu, 4 Dec 2014 16:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_I9cMk75NOp for ; Thu, 4 Dec 2014 16:23:19 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0AE1A8839 for ; Thu, 4 Dec 2014 16:23:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417738998; x=2281652598; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aDRBA1171NpwwILnrX4hXjV24tki9jyM5WBFE8/xE1Q=; b=dtmCfTvUkNBvdQBczmQyB9esIAcixuWr3T9RrxsdDQpIRnoaBGtBqMuUWaZf5pW5 zglzMOcG8iWReTDm4vpTi8CiVigd/j0A9OJXZDH+ibEVxAMm363on2uXz2v9xSlu Lw/1OM6VWfK8xY/zzSxmqM4zIhIEhmjyWjNMHQdbSDrD0RpSlVnZM7FvsQG9lyXM zFpo6QYnj6Gpf0rI0tncBRqDeL9oWi/8iwKYXyE4/AGka5sZon4gT7P0lQ4QQURO 3h82Z+R3jW5lmcFRZzEmerflXfL3y1y09Ivyr+D9k6P5kXSse4Ip0rH80kCd3VqS 5M51LrMr6+THuHqydknOgg==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id AE.96.18524.6FAF0845; Thu, 4 Dec 2014 16:23:18 -0800 (PST) X-AuditID: 11973e15-f79476d00000485c-66-5480faf6e6d0 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 9E.7D.05858.0FAF0845; Thu, 4 Dec 2014 16:23:12 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG300G6I2EU2H10@marigold.apple.com> for rtcweb@ietf.org; Thu, 04 Dec 2014 16:23:18 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <4A0ABA0E-3D2C-49D6-9FC4-71F725531738@apple.com> Date: Thu, 04 Dec 2014 16:23:17 -0800 Content-transfer-encoding: quoted-printable Message-id: <11AC48F2-D93C-407D-8D31-8C4D27CB5F62@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <4A0ABA0E-3D2C-49D6-9FC4-71F725531738@apple.com> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FDorPvtV0OIQX+XusXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK6P59lLVgNWfF/rYtLA2Mx9m7GDk4JARMJN5vN+pi5AQyxSQu 3FvP1sXIxSEksJdRYlbTRbiaXyeEIeKTmCRenJzODuHMZ5LYtuM+WBGzgLrElCm5IIN4BfQk mp48ZgKxhQUiJI50nmEHsdkEVCUezDnGCGJzCthK3PzUDBZnAYp//7SVBcRmFtCWePLuAivE HBuJhgvLweqFBPqZJTa1gdWLAK26/PACO8TRshL/Lp4Bu0dC4CmrROvPfrYJjEKzEE6aheSk WUhWLGBkXsUolJuYmaObmWeml1hQkJOql5yfu4kRFKrT7UR3MJ5ZZXWIUYCDUYmHt3B3fYgQ a2JZcWXuIUZpDhYlcV62+oYQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYzl+7tu+83ettr8 Fd8MqT9enr0ZrddufnH6L/ula0e61FoF/cLjrHI3lSzXRF6Tkpj1OME0V6KC/eSnNq1bRY8Z natPC8WeWv+RUWP+pdDjKitz++Zzt0gs36hzf11Y2OWfgY8b0zasZZOM6eZ6dyCZQ+14xI7D 1jujjEv37L39WGJfFVtks7cSS3FGoqEWc1FxIgBAzSvhNgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUi2FDcovvhV0OIwbtZihZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEro/v3UdaC1ZwV+9u2sDQwHmfvYuTgkBAwkfh1QriLkRPIFJO4 cG89WxcjF4eQwCQmiRcnp7NDOPOZJLbtuA/WwCygLjFlSi5IA6+AnkTTk8dMILawQITEkc4z 7CA2m4CqxIM5xxhBbE4BW4mbn5rB4ixA8e+ftrKA2MwC2hJP3l1ghZhjI9FwYTlYvZBAP7PE pjawehGgVZcfXmCHOE5W4t/FM+wTGPlnIVwxC8kVs5BMXcDIvIpRoCg1J7HSSC+xoCAnVS85 P3cTIzi4Cp13MB5bZnWIUYCDUYmHt2B3fYgQa2JZcWXuIUYJDmYlEV7jIw0hQrwpiZVVqUX5 8UWlOanFhxilOViUxHntXgGlBNITS1KzU1MLUotgskwcnFINjPUf+7fMqNmS0XWVW/4B+9vb F539ss3XKytcMDH9/3X525Lfzh/2NZQxfrsbuntTZWXnj7J1a7+/L2zVlrOe8INj/7yUloef q3f7BTwwYHCJWmmlLRnWU9efWFMZf8Vbf8Puo8suBG7cbXBOI6Fzjc5kC3GZqefzde4dP371 1Ycjm7179EyXuyqxFGckGmoxFxUnAgDuPEbQKgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5zHi1ItfAtxEed3LC62IDfYyv2o Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 00:23:21 -0000 > On Dec 4, 2014, at 14:36 , David Singer wrote: >=20 >=20 >> On Dec 4, 2014, at 14:30 , I=C3=B1aki Baz Castillo = wrote: >>=20 >> 2014-12-04 23:03 GMT+01:00 David Singer : >>> Quite where you see the uncertainty and doubt in the =E2=80=9Cyou = MUST implement something which, it is stated, is subject to IPR which = CANNOT be licensed=E2=80=9D, I am less sure. Fear, yes, I get that. >>=20 >> Just to clarify, I'm not in favor of mandating non 100% royalty-free >> codecs in a W3C specification. >=20 > I understand and respect that. I would also prefer not to mandate an = RF codec; I just can=E2=80=99t find one. I don=E2=80=99t like the = situation at all. =20 I obviously meant a non-RF codec. sorry >=20 > I just don=E2=80=99t see the current proposed wording as solving = anything, and in fact, it makes the problem worse, not better. >=20 > David Singer > Manager, Software Standards, Apple Inc. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb David Singer Manager, Software Standards, Apple Inc. From nobody Thu Dec 4 19:57:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFB01ABC75 for ; Thu, 4 Dec 2014 19:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXGoZWTlYyMq for ; Thu, 4 Dec 2014 19:57:14 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id ACB8D1ABD39 for ; Thu, 4 Dec 2014 19:57:13 -0800 (PST) Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail06.adl6.internode.on.net with ESMTP; 05 Dec 2014 14:27:12 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 3A09DFFEE9 for ; Fri, 5 Dec 2014 14:27:10 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KHFGM647H1IE for ; Fri, 5 Dec 2014 14:27:07 +1030 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 1C631FF82B for ; Fri, 5 Dec 2014 14:27:07 +1030 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 09A0980470; Fri, 5 Dec 2014 14:27:07 +1030 (ACDT) Date: Fri, 5 Dec 2014 14:27:06 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141205035706.GB21150@hex.shelbyville.oz> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3qVqrcHLQuE3T4-1HyLCuH9GDy8 Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 03:57:16 -0000 On Thu, Dec 04, 2014 at 02:03:44PM -0800, David Singer wrote: > > > On Dec 4, 2014, at 13:59 , Iñaki Baz Castillo wrote: > > > > 2014-12-03 19:33 GMT+01:00 David Singer : > >> As I understand it, the recent face to face meeting decided to draft the requirement that WebRTC browsers be required to implement both VP8 and H.264, and get feedback on this, on the list. > >> > >> This is some feedback. > > > > I've been searching in both the rtcweb and public-webrtc mailing > > lists, and must say that it is VERY SAD that the only "contribution" > > and "feedback" received from Apple are these regarding "MTI codecs", > > nothing else. > > > > I hope Apple has better things to do than sending FUD to working > > groups in which they have no interest. > > I apologize for both the fact that you think this is FUD, and for the lack of other engagement. > > Quite where you see the uncertainty and doubt in the “you MUST > implement something which, it is stated, is subject to IPR which > CANNOT be licensedâ€, I am less sure. Fear, yes, I get that. Are you seriously suggesting that the due diligence which Google's team did prior to the acquisition of On2 and the VP8 IP was so completely incompetent that they "somehow missed" the barnload of random claims that Nokia have belatedly asserted here as a last scorched earth defence after all other lines of sophistry were apparently failing dismally? And/or that Google was also subsequently too incompetent to look at those and make a few small changes to avoid any they really did? I think you're right that there isn't actually much uncertainty or doubt there, but a small group of H.264 patent holders sure is still trying hard to project the idea that there ought to be some. Their fear is showing yes. But it doesn't really appear to be rubbing off onto anyone else. > “We may as well all drown together†— it’s not very cheery, is it? I think the metaphor you were looking for here was "burn on the platform together". I don't think there's much uncertainty or doubt as to who the arsonists are here. If they want to self-immolate, that's fine, but wanting to burn everyone else to the water line with them isn't encouraging anyone to want to join them in that. The current "compromise" is a direct response to attempts to game the system to avoid the clear no-brainer outcome of adopting VP8, which for all empirical measures is still as RF as Opus is, and would be a near perfect fit as the sort of open to everyone technology that the IETF prefers to endorse in its standards. If you don't like the compromise, that's fine. Lots of us don't very much like it either. But if you want to actually fix that, you're flexing your muscles at the wrong group. You ought to be leaning on Nokia instead. They are the ones who keep shoving a sabot into the machinery here - though it's hard to think they'd persist in that like they have without firm encouragement from their peers. It's not a good look for them. The H.264 patent holder cartel holds all the cards to resolve this one way or the other now. This compromise explicitly hands them the deck to shuffle and deal. The sooner they understand that they can't just bully or frighten the people who really need an RF codec into giving up on having one, the sooner we can all get on with the real game. This compromise is a way of saying that you can't bully us into total inaction and failure of this standard either. I commend the people from both camps who have agreed to meet in the middle, for all the work they have done trying to find real ways to move this forward. Ron From nobody Thu Dec 4 20:19:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E5B1AC3AB for ; Thu, 4 Dec 2014 20:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqUvSWTgjQWd for ; Thu, 4 Dec 2014 20:19:00 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684131AC3B3 for ; Thu, 4 Dec 2014 20:18:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2214; q=dns/txt; s=iport; t=1417753137; x=1418962737; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ipb+SdrhB21ESMBohgnzf7F56rnNhKZK6d6deFNOnXI=; b=SlW4HJX0zY4PsdjQO9/i2RUMrvcXW+WqFnLpXfSfGyTrruoGxOel0eKT 6NZJqtvd4JwValxxsaliHBokvygVOMtC8LJh3r2YIuUtoim2ywTemYDEA hJspRv37it7V7qpnpI1/Ue4MQ529zSMthY9hobFXceT2VJQRS4ONbi2g1 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFABMxgVStJV2Y/2dsb2JhbABZgwZSUwUExjkMhUJPAoEcFgEBAQEBfYQCAQEBBAEBATc0FwQCAQgRAwECHxAnCx0IAgQTCYgyCAXXAQEBAQEBAQQBAQEBAQEBG5AcOgaEMAWPQoN+hhiBIjSCXo8Jg29vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,520,1413244800"; d="scan'208";a="102880415" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP; 05 Dec 2014 04:18:56 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sB54IuKN012794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 5 Dec 2014 04:18:56 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.185]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 22:18:56 -0600 From: "Ram Mohan R (rmohanr)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-09.txt Thread-Index: AQHQEEKVaVnwXFoGL0aXIcUyeunVjQ== Date: Fri, 5 Dec 2014 04:18:56 +0000 Message-ID: References: <20141204174709.26945.65249.idtracker@ietfa.amsl.com> In-Reply-To: <20141204174709.26945.65249.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [173.39.64.151] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sp17Fa6BV3Q-B3pPlVNYvDogkmM Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-09.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 04:19:02 -0000 This version addresses all the WGLC comments received. Please review and let us know if any thing else is missing. Regards, Authors -----Original Message----- From: "internet-drafts@ietf.org" Date: Thursday, 4 December 2014 11:17 pm To: "i-d-announce@ietf.org" Cc: "rtcweb@ietf.org" Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-09.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Real-Time Communication in WEB-browsers >Working Group of the IETF. > > Title : STUN Usage for Consent Freshness > Authors : Muthu Arul Mozhi Perumal > Dan Wing > Ram Mohan Ravindranath > Tirumaleswar Reddy > Martin Thomson > Filename : draft-ietf-rtcweb-stun-consent-freshness-09.txt > Pages : 9 > Date : 2014-12-04 > >Abstract: > To prevent sending excessive traffic to an endpoint, periodic consent > needs to be obtained from that remote endpoint. > > This document describes a consent mechanism using a new Session > Traversal Utilities for NAT (STUN) usage. This same mechanism can > also determine connection loss ("liveness") with a remote peer. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-09 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshnes= s- >09 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Dec 5 00:05:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770421ACD90 for ; Fri, 5 Dec 2014 00:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2Ojcp3CypN6 for ; Fri, 5 Dec 2014 00:05:36 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 370CE1ACAD8 for ; Fri, 5 Dec 2014 00:05:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B5C077C0DC3 for ; Fri, 5 Dec 2014 09:05:34 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQJdhVp-j7VO for ; Fri, 5 Dec 2014 09:05:32 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:a53a:eb60:5dc7:d291]) by mork.alvestrand.no (Postfix) with ESMTPSA id 739877C0D47 for ; Fri, 5 Dec 2014 09:05:04 +0100 (CET) Message-ID: <5481672E.4080305@alvestrand.no> Date: Fri, 05 Dec 2014 09:05:02 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> In-Reply-To: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/r3N4JVLgFAZ9QxESu0PJ-4SI1Ow Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 08:05:40 -0000 Just to get the ball rolling: A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG document now. On 12/04/2014 08:29 PM, Cullen Jennings (fluffy) wrote: > Having reviewed the fine technical comments on this draft since we asked for comments, the chairs have noted that multiple people seem to have read the draft. Given this great news we are going make a call for adoption. > > If you have an opinion, please email the list by Dec 19 and let us know if you either: > > A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG document now > > B) no, not right now > > If we get consensus around A we will work with ADs on milestone. Otherwise we will encourage the authors to keep working on this draft and continue using this email list. We may adopt it later or include the text in other drafts. > > Thanks, > The Chairs (Cullen, Sean, Ted) > > PS - if you want to send an email that says more than A or B, feel free to change the subject, start a new thread etc. > > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Dec 5 00:09:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578761ACAD8 for ; Fri, 5 Dec 2014 00:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np7iR2BKPoyo for ; Fri, 5 Dec 2014 00:09:29 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27401ACDA2 for ; Fri, 5 Dec 2014 00:09:14 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-4a-548168282e08 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id EF.16.04231.82861845; Fri, 5 Dec 2014 09:09:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 09:09:12 +0100 From: Christer Holmberg To: "Cullen Jennings (fluffy)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways Thread-Index: AQHQD/is2LdRMrUKckucyL6VrCW5HJyApObQ Date: Fri, 5 Dec 2014 08:09:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D57BF00@ESESSMB209.ericsson.se> References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> In-Reply-To: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvja5mRmOIwZN0i47JbBZr/7WzOzB5 TPm9kdVjyZKfTAFMUVw2Kak5mWWpRfp2CVwZnyd/Zi24wFNx6OkhtgbGdq4uRk4OCQETifUd O5ghbDGJC/fWs3UxcnEICRxhlJjatZkRJCEksJhR4sCK8i5GDg42AQuJ7n/aIGERgQiJidcv sIHYwgLeEvv33GCEiPtI/Ds+nxXCNpJ4tvYwC0gri4CKxO5tQSBhXgFfiVsTFrNCTLeRePt+ GROIzSlgK3Gy6yPYGEagc76fWgMWZxYQl7j1ZD4TxJkCEkv2nIc6WVTi5eN/rBC2osTHV/sY Iep1JBbs/sQGYWtLLFv4mhlir6DEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyilG0OLW4ODfd yFgvtSgzubg4P08vL7VkEyMwPg5u+a27g3H1a8dDjAIcjEo8vBvkG0OEWBPLiitzDzFKc7Ao ifMuOjcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOj9Uy3LV6qKx1Wz23QvH2uIXDmm4SH /+qe1MmWHSjcnJBpVbo5adfKkHbLfUcVpWL5Ejg4PDf/WbVJL7V+ftme5OI7jkuyGm8tPH/r jdPFVDWvTts/J8v+MkSE5Mhe6X8m4ie4uGXN+dsR3ufebq7+2LdCfafa57lXhFWnyASv/x/m VDarryxJiaU4I9FQi7moOBEA3i3JU3ACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lHfLmPeJITgWBZ0djBV1Jmn3wRs Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 08:09:31 -0000 Hi, A strong support for:=20 A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG documen= t now. I get questions regarding the differences (in terms of supported features) = between WebRTC browsers and gateway on a daily basis, so I believe the indu= stry really needs a document clarifying those things. Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings = (fluffy) Sent: 4. joulukuuta 2014 21:30 To: rtcweb@ietf.org Subject: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways Having reviewed the fine technical comments on this draft since we asked fo= r comments, the chairs have noted that multiple people seem to have read th= e draft. Given this great news we are going make a call for adoption.=20 If you have an opinion, please email the list by Dec 19 and let us know if = you either: A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG document= now B) no, not right now=20 If we get consensus around A we will work with ADs on milestone. Otherwise = we will encourage the authors to keep working on this draft and continue us= ing this email list. We may adopt it later or include the text in other dra= fts.=20 Thanks,=20 The Chairs (Cullen, Sean, Ted) PS - if you want to send an email that says more than A or B, feel free to = change the subject, start a new thread etc.=20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Dec 5 00:22:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5781ACDD5 for ; Fri, 5 Dec 2014 00:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DlLKZ-1vrJp for ; Fri, 5 Dec 2014 00:22:49 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 174761AC7E8 for ; Fri, 5 Dec 2014 00:22:48 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-c9-54816b563130 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FC.72.29772.65B61845; Fri, 5 Dec 2014 09:22:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 09:22:46 +0100 From: Christer Holmberg To: "Ram Mohan R (rmohanr)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-09.txt Thread-Index: AQHQD+paJpylNk+a/UGfE1EvBmkxLZyAVJMAgABUnpA= Date: Fri, 5 Dec 2014 08:22:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D57C013@ESESSMB209.ericsson.se> References: <20141204174709.26945.65249.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvjW54dmOIwb39vBbLu3YwWqz9187u wOQx5fdGVo8lS34yBTBFcdmkpOZklqUW6dslcGVMvHKJtWCvaMXTD/1MDYytgl2MnBwSAiYS 5x6vYYewxSQu3FvP1sXIxSEkcIRR4uO5n8wQzmJGiQdPHgNlODjYBCwkuv9pgzSICIRJTD+x gAXEFhYIlnh7cxsrRDxEYvPpJVC2lcT2qzeYQWwWARWJ9hUzwWxeAV+JqbN+MIHYQgJpEo8/ nQWbwymgL/Gzby4jiM0IdND3U2vAapgFxCVuPZnPBHGogMSSPeeZIWxRiZeP/7FC2IoSH1/t Y4So15FYsPsTG4StLbFs4WuovYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkbR4tTipNx0 IyO91KLM5OLi/Dy9vNSSTYzAODm45bfBDsaXzx0PMQpwMCrx8G6UbwwRYk0sK67MPcQozcGi JM678Ny8YCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MjKfZmOKus3fcFLrw91SsqHn2sacl 3R+49Xtq/hjuTm1jdA0Tu5GUW848W4E9Tf/ykd3XfZdYZOXG7o+RSuJx+WVoELheI/jHW7vv SW0OP6fsfO+6h0Vg+qkVdnxTuP7EHby6su4S5453lwzip+TyblD8wfinS+/yQlkOLfdvxY8K 4t4r101RYinOSDTUYi4qTgQAagf3C3QCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dS4DOtryKSM1smkg2vFDVFGCE1Q Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-09.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 08:22:51 -0000 Hi, I thought the idea was to remove the liveness/heartbeat feature, but it is = still in the draft. Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan R (rmo= hanr) Sent: 5. joulukuuta 2014 6:19 To: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-= 09.txt This version addresses all the WGLC comments received. Please review and let us know if any thing else is missing. Regards, Authors -----Original Message----- From: "internet-drafts@ietf.org" Date: Thursday, 4 December 2014 11:17 pm To: "i-d-announce@ietf.org" Cc: "rtcweb@ietf.org" Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-09.txt > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > This draft is a work item of the Real-Time Communication in=20 >WEB-browsers Working Group of the IETF. > > Title : STUN Usage for Consent Freshness > Authors : Muthu Arul Mozhi Perumal > Dan Wing > Ram Mohan Ravindranath > Tirumaleswar Reddy > Martin Thomson > Filename : draft-ietf-rtcweb-stun-consent-freshness-09.txt > Pages : 9 > Date : 2014-12-04 > >Abstract: > To prevent sending excessive traffic to an endpoint, periodic consent > needs to be obtained from that remote endpoint. > > This document describes a consent mechanism using a new Session > Traversal Utilities for NAT (STUN) usage. This same mechanism can > also determine connection loss ("liveness") with a remote peer. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshne >ss/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-09 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshne >ss- >09 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >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 From nobody Fri Dec 5 00:37:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292581ACDFB for ; Fri, 5 Dec 2014 00:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYOQjKUTjPt6 for ; Fri, 5 Dec 2014 00:37:39 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 4991B1ACDD6 for ; Fri, 5 Dec 2014 00:37:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 2B7787C0D47 for ; Fri, 5 Dec 2014 09:37:38 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oOe5e66L6Yb for ; Fri, 5 Dec 2014 09:37:34 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:a53a:eb60:5dc7:d291]) by mork.alvestrand.no (Postfix) with ESMTPSA id 112EE7C0AEB for ; Fri, 5 Dec 2014 09:37:34 +0100 (CET) Message-ID: <54816ECD.7070601@alvestrand.no> Date: Fri, 05 Dec 2014 09:37:33 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> <5480C531.5050104@bbs.darktech.org> <0C44FAD4-08C9-43FE-84BE-3B09C993443F@apple.com> In-Reply-To: <0C44FAD4-08C9-43FE-84BE-3B09C993443F@apple.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mxJQfJiZdGuIIBxCf4cntHXm-e4 Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 08:37:41 -0000 On 12/04/2014 11:21 PM, David Singer wrote: >> On Dec 4, 2014, at 12:33 , cowwoc wrote: >> >> A formal "unwilling to license" without any factual information to back it up is practically meaningless. > They supply a (long) list of actual patents. That is quite a bit of factual information. (Rather too much for some people, and not enough for others, I suspect; a lot of work to read them, and not specific reasons why they think those patents apply. But you take what you can get, and the formal process only asks for the patent numbers.) Just to be precise: The statement made by Nokia in MPEG does not cite patent numbers. The statement made by Nokia in the IETF does cite patent numbers (thank you, Nokia!) Neither statement explains which part of the VP8 specification the patents apply to. And, of course, neither statement can compel anyone to come to the conclusion that the patent is a) valid, and b) applies to VP8 - that is a matter for each participant's legal analysis, which the industry participants have a long tradition of not sharing publicly (there are probably good reasons for that). > >> What is the legal difference between a company that does that and a company who sues using a previously-undeclared H.264 IPR? > Well, in one case you were put on formal notice, and in the other, it was a situation you were previously unaware of. IANAL but I think this makes a difference. > > David Singer > Manager, Software Standards, Apple Inc. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Dec 5 00:41:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA58E1ACDD6 for ; Fri, 5 Dec 2014 00:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3iQ3Ab3DB4D for ; Fri, 5 Dec 2014 00:40:56 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDA41ACDBF for ; Fri, 5 Dec 2014 00:40:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 821947C0D45 for ; Fri, 5 Dec 2014 09:40:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7-N2kXqHAUY for ; Fri, 5 Dec 2014 09:40:50 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:a53a:eb60:5dc7:d291]) by mork.alvestrand.no (Postfix) with ESMTPSA id 6F3067C0AEB for ; Fri, 5 Dec 2014 09:40:50 +0100 (CET) Message-ID: <54816F91.9010108@alvestrand.no> Date: Fri, 05 Dec 2014 09:40:49 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> <1F326DF9-79C2-4562-853B-240D934EA235@apple.com> <949EF20990823C4C85C18D59AA11AD8B28CDFF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5480CEF2.4020204@mozilla.com> <949EF20990823C4C85C18D59AA11AD8B28CF6B@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B28CF6B@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6X_xe7m32MlKC29CdVNa-Zm2nbo Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 08:40:58 -0000 On 12/05/2014 12:02 AM, DRAGE, Keith (Keith) wrote: > Both yours and David's responses to this are outside the IPR gathering exercise that forms part of the standards process. > > The idea of the standards process is that a group of vendors etc write a standard, they are forced to declare their IPR involved in that standard. If the population is sufficiently large you stand a good chance of identifying all the worldwide IPR relating to that standard. > > The bigger the standards organisation, with the greater coverage of all the vendors in that space, the better the process works. > > So at that level, IPR knowledge for codecs is primarily on the decoder space and what IPR exists there. > > What Tim is saying (and a somewhat parallel situation exists with MPEG LA) is that a limited set of organisations will limit your IPR problems and give you some help with the encoder IPR. For VP8 that is limited to Google's IPR and any background research they may have done. And, of course, the IPR owned by signatories to the license agreement that Google has sublicensed through the WebM CCL: http://www.webm-ccl.org/vp8/agreement/ > For MPEG LA it is limited to the members of the pool, which is only a subset of those involved in the parallel standards process. Yes it helps, but it does not have the degree of confidence of identifying all the existing IPR that the standards process would do. > > Regards > > Keith > From nobody Fri Dec 5 02:38:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E331E1ACE34 for ; Fri, 5 Dec 2014 02:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlxZlu6mlxeL for ; Fri, 5 Dec 2014 02:38:30 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C831ACE33 for ; Fri, 5 Dec 2014 02:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3252; q=dns/txt; s=iport; t=1417775911; x=1418985511; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=zEe/5/vL8qYi9xuGnPo1LJjOOhWT+NkjV1MC94l5ejU=; b=jSgF5sYTAEOo9UBugbOha8GJRYaCwhAAbkaicyToerCbxjaTa5r/D3ma yHILT7Xy6bd3mIqKIsWOvyaYe7It7nsVwSppjLgyEmDinJDxPFN63ZLS5 6biEmt/7Ol1Fiwcv+nFm4sE1Fm8e4pBNDnGIgAa427bAP3CA5//sjcuv9 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAMGKgVStJA2G/2dsb2JhbABZgwZSUwUExjkMhUJPAoEbFgEBAQEBfYQCAQEBBAEBATc0FwQCAQgRAwEBAR8JBycLFAkIAgQBEgmIMggF1iABAQEBAQEBAQEBAQEBAQEBAQEBAQEXkFYGhDAFj0aDfoYbgSI0gl6PC4Nvb4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="scan'208";a="377775278" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP; 05 Dec 2014 10:38:29 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sB5AcSaN028806 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Dec 2014 10:38:28 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.81]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 04:38:28 -0600 From: "Ram Mohan R (rmohanr)" To: Christer Holmberg , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-09.txt Thread-Index: AQHQEHebaVnwXFoGL0aXIcUyeunVjQ== Date: Fri, 5 Dec 2014 10:38:28 +0000 Message-ID: References: <20141204174709.26945.65249.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D57C013@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D57C013@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [173.39.64.151] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mmvZ0T_iQWO2CUkMxImJ_I-OlS0 Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-09.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 10:38:33 -0000 Sorry this is a issue w.r.t picking up a wrong version. We had removed liveness in ver 8. I will check and publish the correct revision. Ram -----Original Message----- From: Christer Holmberg Date: Friday, 5 December 2014 1:52 pm To: Cisco Employee , "rtcweb@ietf.org" Subject: RE: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-09.txt >Hi, > >I thought the idea was to remove the liveness/heartbeat feature, but it >is still in the draft. > >Regards, > >Christer > >-----Original Message----- >From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan R >(rmohanr) >Sent: 5. joulukuuta 2014 6:19 >To: rtcweb@ietf.org >Subject: Re: [rtcweb] I-D Action: >draft-ietf-rtcweb-stun-consent-freshness-09.txt > >This version addresses all the WGLC comments received. >Please review and let us know if any thing else is missing. > >Regards, >Authors > >-----Original Message----- >From: "internet-drafts@ietf.org" >Date: Thursday, 4 December 2014 11:17 pm >To: "i-d-announce@ietf.org" >Cc: "rtcweb@ietf.org" >Subject: [rtcweb] I-D Action: >draft-ietf-rtcweb-stun-consent-freshness-09.txt > >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Real-Time Communication in >>WEB-browsers Working Group of the IETF. >> >> Title : STUN Usage for Consent Freshness >> Authors : Muthu Arul Mozhi Perumal >> Dan Wing >> Ram Mohan Ravindranath >> Tirumaleswar Reddy >> Martin Thomson >> Filename : draft-ietf-rtcweb-stun-consent-freshness-09.txt >> Pages : 9 >> Date : 2014-12-04 >> >>Abstract: >> To prevent sending excessive traffic to an endpoint, periodic consent >> needs to be obtained from that remote endpoint. >> >> This document describes a consent mechanism using a new Session >> Traversal Utilities for NAT (STUN) usage. This same mechanism can >> also determine connection loss ("liveness") with a remote peer. >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshne >>ss/ >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-09 >> >>A diff from the previous version is available at: >>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshne >>ss- >>09 >> >> >>Please note that it may take a couple of minutes from the time of >>submission until the htmlized version and diff are available at >>tools.ietf.org. >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>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 From nobody Fri Dec 5 03:02:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDF81ACE3D for ; Fri, 5 Dec 2014 03:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STMG8A5hbVMt for ; Fri, 5 Dec 2014 03:02:22 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 090541ACE30 for ; Fri, 5 Dec 2014 03:02:21 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y19so590264wgg.0 for ; Fri, 05 Dec 2014 03:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VENDqXTx8G1TmVivoZ7aev1nGqakC3lDlMMb40WKGis=; b=Au8hLPgHsxWHoBoWEZYC9DV0h3uEBoe0Kc+C4pXTn7BkNcwXbjU4rsBKQh8pQaUZ07 aUHbcey/py7MjnLX3FCWAilpldB7dNIdb/Ts4jAKoav88H9u1VhX3ER6tu24/H6UoTIu DWs1MTFpU1XGr9dGm84zYpkGGILvnULzPEzHR+zWphGnVn5YcRvMpJIQlD5ckS05upOD CaiNS2/4GKfLcYkxHWlM2pKo+t08Z7lI/mg7U8Y85Xzkl1CBUa7xv+Lu1IV2W/r3F3Pr 92AdhdxvoNx95RDvg2ldMd/VJzWSJ9wYZc2Fd/bjfQbVP9g0ZQHKwxS/qWsj18l8ihy+ sEqg== MIME-Version: 1.0 X-Received: by 10.194.23.10 with SMTP id i10mr22739268wjf.11.1417777340717; Fri, 05 Dec 2014 03:02:20 -0800 (PST) Received: by 10.180.76.242 with HTTP; Fri, 5 Dec 2014 03:02:20 -0800 (PST) In-Reply-To: References: <20141204174709.26945.65249.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D57C013@ESESSMB209.ericsson.se> Date: Fri, 5 Dec 2014 16:32:20 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: "Ram Mohan R (rmohanr)" Content-Type: multipart/alternative; boundary=047d7b450b1ec3a17b05097602e5 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/y3WWoCqFF_7n0x-HDRi9hHFTiIA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-09.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 11:02:25 -0000 --047d7b450b1ec3a17b05097602e5 Content-Type: text/plain; charset=UTF-8 Does anyone know if there is a way to get -09 version removed from the datatracker? Muthu On Fri, Dec 5, 2014 at 4:08 PM, Ram Mohan R (rmohanr) wrote: > Sorry this is a issue w.r.t picking up a wrong version. We had removed > liveness in ver 8. I will check and publish the correct revision. > > Ram > > -----Original Message----- > From: Christer Holmberg > Date: Friday, 5 December 2014 1:52 pm > To: Cisco Employee , "rtcweb@ietf.org" > > Subject: RE: [rtcweb] I-D Action: > draft-ietf-rtcweb-stun-consent-freshness-09.txt > > >Hi, > > > >I thought the idea was to remove the liveness/heartbeat feature, but it > >is still in the draft. > > > >Regards, > > > >Christer > > > >-----Original Message----- > >From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan R > >(rmohanr) > >Sent: 5. joulukuuta 2014 6:19 > >To: rtcweb@ietf.org > >Subject: Re: [rtcweb] I-D Action: > >draft-ietf-rtcweb-stun-consent-freshness-09.txt > > > >This version addresses all the WGLC comments received. > >Please review and let us know if any thing else is missing. > > > >Regards, > >Authors > > > >-----Original Message----- > >From: "internet-drafts@ietf.org" > >Date: Thursday, 4 December 2014 11:17 pm > >To: "i-d-announce@ietf.org" > >Cc: "rtcweb@ietf.org" > >Subject: [rtcweb] I-D Action: > >draft-ietf-rtcweb-stun-consent-freshness-09.txt > > > >> > >>A New Internet-Draft is available from the on-line Internet-Drafts > >>directories. > >> This draft is a work item of the Real-Time Communication in > >>WEB-browsers Working Group of the IETF. > >> > >> Title : STUN Usage for Consent Freshness > >> Authors : Muthu Arul Mozhi Perumal > >> Dan Wing > >> Ram Mohan Ravindranath > >> Tirumaleswar Reddy > >> Martin Thomson > >> Filename : draft-ietf-rtcweb-stun-consent-freshness-09.txt > >> Pages : 9 > >> Date : 2014-12-04 > >> > >>Abstract: > >> To prevent sending excessive traffic to an endpoint, periodic consent > >> needs to be obtained from that remote endpoint. > >> > >> This document describes a consent mechanism using a new Session > >> Traversal Utilities for NAT (STUN) usage. This same mechanism can > >> also determine connection loss ("liveness") with a remote peer. > >> > >> > >>The IETF datatracker status page for this draft is: > >>https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshne > >>ss/ > >> > >>There's also a htmlized version available at: > >>http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-09 > >> > >>A diff from the previous version is available at: > >>http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshne > >>ss- > >>09 > >> > >> > >>Please note that it may take a couple of minutes from the time of > >>submission until the htmlized version and diff are available at > >>tools.ietf.org. > >> > >>Internet-Drafts are also available by anonymous FTP at: > >>ftp://ftp.ietf.org/internet-drafts/ > >> > >>_______________________________________________ > >>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 > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b450b1ec3a17b05097602e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Does anyone know if there is a way to g= et -09 version removed from the datatracker?

Muthu

On Fri, Dec 5, 2014 at 4:08 PM, Ram Mohan R (rmohanr) <rm= ohanr@cisco.com> wrote:
Sor= ry this is a issue w.r.t picking up a wrong version. We had removed
liveness in ver 8. I will check and publish the correct revision.

Ram

-----Original Message-----
From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Friday, 5 December 2014 1:52 pm
To: Cisco Employee <rmohanr@cisco.c= om>, "rtcweb@ietf.org&qu= ot; <rtcweb@ietf.org>
Subject: RE: [rtcweb] I-D Action:
draft-ietf-rtcweb-stun-consent-freshness-09.txt

>Hi,
>
>I thought the idea was to remove the liveness/heartbeat feature, but it=
>is still in the draft.
>
>Regards,
>
>Christer
>
>-----Original Message-----
>From: rtcweb [mailto:rtcweb-= bounces@ietf.org] On Behalf Of Ram Mohan R
>(rmohanr)
>Sent: 5. joulukuuta 2014 6:19
>To: rtcweb@ietf.org
>Subject: Re: [rtcweb] I-D Action:
>draft-ietf-rtcweb-stun-consent-freshness-09.txt
>
>This version addresses all the WGLC comments received.
>Please review and let us know if any thing else is missing.
>
>Regards,
>Authors
>
>-----Original Message-----
>From: "internet-drafts= @ietf.org" <interne= t-drafts@ietf.org>
>Date: Thursday, 4 December 2014 11:17 pm
>To: "i-d-announce@ietf.or= g" <i-d-announce@ietf.= org>
>Cc: "rtcweb@ietf.org" = <rtcweb@ietf.org>
>Subject: [rtcweb] I-D Action:
>draft-ietf-rtcweb-stun-consent-freshness-09.txt
>
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts<= br> >>directories.
>> This draft is a work item of the Real-Time Communication in
>>WEB-browsers Working Group of the IETF.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: STUN Usage for Consent Freshness
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Muthu Arul Mozhi Perumal
>>=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=A0 Dan Wing
>>=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=A0 Ram Mohan Ravindranath
>>=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=A0 Tirumaleswar Reddy
>>=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=A0 Martin Thomson
>>=C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ie= tf-rtcweb-stun-consent-freshness-09.txt
>>=C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : 9
>>=C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : 2014-12-04
>>
>>Abstract:
>>=C2=A0 =C2=A0To prevent sending excessive traffic to an endpoint, p= eriodic consent
>>=C2=A0 =C2=A0needs to be obtained from that remote endpoint.
>>
>>=C2=A0 =C2=A0This document describes a consent mechanism using a ne= w Session
>>=C2=A0 =C2=A0Traversal Utilities for NAT (STUN) usage.=C2=A0 This s= ame mechanism can
>>=C2=A0 =C2=A0also determine connection loss ("liveness") = with a remote peer.
>>
>>
>>The IETF datatracker status page for this draft is:
>>https://datatracker.ietf.org/doc/draft-i= etf-rtcweb-stun-consent-freshne
>>ss/
>>
>>There's also a htmlized version available at:
>>http://tools.ietf.org/html/draft-ietf-rtc= web-stun-consent-freshness-09
>>
>>A diff from the previous version is available at:
>>http://www.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-rtcweb-stun-consent-freshne
>>ss-
>>09
>>
>>
>>Please note that it may take a couple of minutes from the time of >>submission until the htmlized version and diff are available at
>>tools.ietf.org<= /a>.
>>
>>Internet-Drafts are also available by anonymous FTP at:
>>f= tp://ftp.ietf.org/internet-drafts/
>>
>>_______________________________________________
>>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

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7b450b1ec3a17b05097602e5-- From nobody Fri Dec 5 03:10:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E79C1ACE3A for ; Fri, 5 Dec 2014 03:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITEdaVCqrQ9n for ; Fri, 5 Dec 2014 03:09:54 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABEDD1ACE4D for ; Fri, 5 Dec 2014 03:09:54 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 21E648C54E7C7; Fri, 5 Dec 2014 11:09:50 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sB5B9Top024620 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Dec 2014 12:09:52 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 12:09:38 +0100 From: "DRAGE, Keith (Keith)" To: Muthu Arul Mozhi Perumal , "Ram Mohan R (rmohanr)" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-09.txt Thread-Index: AQHQEHsDO3YNfP0zyUqKnd9OD6B+a5yA1eWA Date: Fri, 5 Dec 2014 11:09:37 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B28D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20141204174709.26945.65249.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D57C013@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TMWbuD2o33hJSpXb6yTyN5fTIfE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-09.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 11:10:04 -0000 No - it is issued All you can provide is the -10 I believe the chairs may be able to place some annotations abot the -09 on = the datatracker entry=20 Keith > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20 > Muthu Arul Mozhi Perumal > Sent: 05 December 2014 11:02 > To: Ram Mohan R (rmohanr) > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] I-D Action:=20 > draft-ietf-rtcweb-stun-consent-freshness-09.txt >=20 > Does anyone know if there is a way to get -09 version removed=20 > from the datatracker? >=20 > Muthu >=20 > On Fri, Dec 5, 2014 at 4:08 PM, Ram Mohan R (rmohanr)=20 > wrote: >=20 >=20 > Sorry this is a issue w.r.t picking up a wrong version.=20 > We had removed > liveness in ver 8. I will check and publish the correct=20 > revision. > =09 > Ram > =09 >=20 > -----Original Message----- > From: Christer Holmberg > Date: Friday, 5 December 2014 1:52 pm > To: Cisco Employee ,=20 > "rtcweb@ietf.org" > Subject: RE: [rtcweb] I-D Action: > draft-ietf-rtcweb-stun-consent-freshness-09.txt > =09 > >Hi, > > > >I thought the idea was to remove the=20 > liveness/heartbeat feature, but it > >is still in the draft. > > > >Regards, > > > >Christer > > > >-----Original Message----- > >From: rtcweb [mailto:rtcweb-bounces@ietf.org] On=20 > Behalf Of Ram Mohan R > >(rmohanr) > >Sent: 5. joulukuuta 2014 6:19 > >To: rtcweb@ietf.org > >Subject: Re: [rtcweb] I-D Action: > >draft-ietf-rtcweb-stun-consent-freshness-09.txt > > > >This version addresses all the WGLC comments received. > >Please review and let us know if any thing else is missing. > > > >Regards, > >Authors > > > >-----Original Message----- > >From: "internet-drafts@ietf.org" > >Date: Thursday, 4 December 2014 11:17 pm > >To: "i-d-announce@ietf.org" > >Cc: "rtcweb@ietf.org" > >Subject: [rtcweb] I-D Action: > >draft-ietf-rtcweb-stun-consent-freshness-09.txt > > > >> > >>A New Internet-Draft is available from the on-line=20 > Internet-Drafts > >>directories. > >> This draft is a work item of the Real-Time Communication in > >>WEB-browsers Working Group of the IETF. > >> > >> Title : STUN Usage for Consent Freshness > >> Authors : Muthu Arul Mozhi Perumal > >> Dan Wing > >> Ram Mohan Ravindranath > >> Tirumaleswar Reddy > >> Martin Thomson > >> Filename :=20 > draft-ietf-rtcweb-stun-consent-freshness-09.txt > >> Pages : 9 > >> Date : 2014-12-04 > >> > >>Abstract: > >> To prevent sending excessive traffic to an=20 > endpoint, periodic consent > >> needs to be obtained from that remote endpoint. > >> > >> This document describes a consent mechanism using=20 > a new Session > >> Traversal Utilities for NAT (STUN) usage. This=20 > same mechanism can > >> also determine connection loss ("liveness") with a=20 > remote peer. > >> > >> > >>The IETF datatracker status page for this draft is: > =09 > >>https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-cons > ent-freshne > >>ss/ > >> > >>There's also a htmlized version available at: > =09 > >>http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-fr > eshness-09 > >> > >>A diff from the previous version is available at: > =09 > >>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-cons > ent-freshne > >>ss- > >>09 > >> > >> > >>Please note that it may take a couple of minutes from=20 > the time of > >>submission until the htmlized version and diff are=20 > available at > >>tools.ietf.org. > >> > >>Internet-Drafts are also available by anonymous FTP at: > >>ftp://ftp.ietf.org/internet-drafts/ > >> > >>_______________________________________________ > >>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 > =09 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > =09 >=20 >=20 > = From nobody Fri Dec 5 04:28:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F671ACE51 for ; Fri, 5 Dec 2014 04:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkD7sD5ehDRA for ; Fri, 5 Dec 2014 04:28:07 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0171A0162 for ; Fri, 5 Dec 2014 04:28:06 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 485616F39E4D4; Fri, 5 Dec 2014 12:28:03 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id sB5CS3IQ018047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Dec 2014 07:28:03 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 07:28:03 -0500 From: "Makaraju, Maridi Raju (Raju)" To: "Cullen Jennings (fluffy)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways Thread-Index: AQHQD/is2LdRMrUKckucyL6VrCW5HJyA7aUQ Date: Fri, 5 Dec 2014 12:28:03 +0000 Message-ID: References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> In-Reply-To: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PDQk6PIyHLPVQoj_Bbkn5Yr2UUE Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 12:28:08 -0000 > A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG docume= nt > now YES, please. BR Raju From nobody Fri Dec 5 05:36:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D9E1A01F6 for ; Fri, 5 Dec 2014 05:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.432 X-Spam-Level: X-Spam-Status: No, score=0.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.999, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvQVXdjI0YpX for ; Fri, 5 Dec 2014 05:36:41 -0800 (PST) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [69.93.243.6]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF921A0362 for ; Fri, 5 Dec 2014 05:36:40 -0800 (PST) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id 76284F521D994; Fri, 5 Dec 2014 07:36:32 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway12.websitewelcome.com (Postfix) with ESMTP id 62A2EF521D8D2 for ; Fri, 5 Dec 2014 07:36:32 -0600 (CST) Received: from [96.231.218.201] (port=49757 helo=192.168.1.7) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xwt3f-0001YK-Q1 for rtcweb@ietf.org; Fri, 05 Dec 2014 07:36:31 -0600 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 5 Dec 2014 08:36:30 -0500 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.218.201 X-Exim-ID: 1Xwt3f-0001YK-Q1 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.7) [96.231.218.201]:49757 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/euzd5q1EIzSAiVFPpY5dfhLwpd0 Subject: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 13:36:42 -0000 All, At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about = codecs, which I dubbed "the great codec compromise." The compromise = text that was discussed appears in slides 12-14 at [4] (which is a = slight editorial variation of the text proposed at [2]). This message serves to confirm the sense of the room. In the room, I heard the following objections and responses (and I=92m = paraphrasing here), which I=92ll take the liberty of categorizing as = IPR, Time, and Trigger: 1) IPR: Objections: There are still IPR concerns which may restrict what a = particular organization feels comfortable with including in their = browser implementations. Response: IPR concerns on this topic are well known. There is even a = draft summarizing the current IPR status for VP8: = draft-benham-rtcweb-vp8litigation. The sense of the room was still that = adopting the compromise text was appropriate. 2) Time: 2.1) Time to consider decision: Objection: The decision to consider the compromise proposal at this = meeting was provided on short notice and did not provide some the = opportunity to attend in person. Response: Six months ago the chairs made it clear discussion would be = revisited @ IETF 91 [0]. The first agenda proposal for the WG included = this topic [1], and the topic was never removed by the chairs. More = importantly, all decisions are confirmed on list; in person attendance = is not required to be part of the process. 2.2) Time to consider text: Objection: The proposed text [2] is too new to be considered. Response: The requirement for browsers to support both VP8 and H.264 was = among the options in the straw poll conducted more than six months ago. = All decisions are confirmed on list so there will be ample time to = discuss the proposal. 3) Trigger: Objection: The =93trigger=94 sentence [3] is all kinds of wrong because = it=92s promising that the future IETF will update this specification. Response: Like any IETF proposal, an RFC that documents the current = proposal can be changed through the consensus process at any other time. After the discussion, some clarifying questions about the hums, and = typing the hum questions on the screen, there was rough consensus in the = room to add (aka =93shove=94) the proposed text into = draft-ietf-rtcweb-video. In keeping with IETF process, I am confirming = this consensus call on the list. If anyone has any other issues that they would like to raise please do = by December 19th. Cheers, spt (as chair) [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html [3] The one that begins with "If compelling evidence ..." [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf= From nobody Fri Dec 5 05:41:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB181A0395 for ; Fri, 5 Dec 2014 05:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id en4ZyJt0kVp5 for ; Fri, 5 Dec 2014 05:41:35 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84EBA1A01F6 for ; Fri, 5 Dec 2014 05:41:35 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sB5DfX3w023998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 5 Dec 2014 13:41:33 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sB5DfXcr030248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 5 Dec 2014 14:41:33 +0100 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 5 Dec 2014 14:41:32 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.75]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 14:41:33 +0100 From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways Thread-Index: AQHQD/is2LdRMrUKckucyL6VrCW5HJyA7aUQgAAUm6A= Date: Fri, 5 Dec 2014 13:41:32 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF8195350C7@DEMUMBX005.nsn-intra.net> References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.158] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 705 X-purgate-ID: 151667::1417786893-0000658F-7B8D0000/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wKWL-VVc3g7W6hKVKKO-dFGlr48 Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 13:41:38 -0000 +1 for "A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG Document" Kind regards, Uwe=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext > Makaraju, Maridi Raju (Raju) > Sent: Friday, December 05, 2014 1:28 PM > To: Cullen Jennings (fluffy); rtcweb@ietf.org > Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb- > gateways >=20 > > A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG > document > > now >=20 > YES, please. >=20 > BR > Raju >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Dec 5 05:44:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD59A1A03FF for ; Fri, 5 Dec 2014 05:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmKjOr3wWPKG for ; Fri, 5 Dec 2014 05:43:59 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA7A1A03A7 for ; Fri, 5 Dec 2014 05:43:59 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id bj1so708735pad.37 for ; Fri, 05 Dec 2014 05:43:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W4VovQP964q8pA+64Tql1vPIWa5XEqXlYaAeu6lmnbI=; b=wu+Y+9B9BsiYlVu9DrMLPi59cS4qACX4/dTgP1cmUduwykA07V14L1McwAj8KNtrCV zEmmrHIFYDUI9i7IK18Zsx4pzTRyuqlpC5jZ4cl0PM2+PS2HYjKvAnnp9LTG11RzgAHR XLDEZdNO1tWE1ocIXI+VQ1GMVIZFCCENGI96pxrkOsccsC3Hka3d+rIi0bIR3+g06MsX q6G7rzCEgWwn6GSkB39CzKVBi2cpo+/pKe/liLik4K6jD2ah4jpJzq5bgtPUSmEUWlu6 HLspqLHeqqZbxTDDHnaqu6NHzAdBlN5aEpiW6exrdLbBKRpVHA3DWNt/lR9uKHSaUrt1 vkVw== MIME-Version: 1.0 X-Received: by 10.70.123.227 with SMTP id md3mr28614104pdb.80.1417787038350; Fri, 05 Dec 2014 05:43:58 -0800 (PST) Received: by 10.70.60.201 with HTTP; Fri, 5 Dec 2014 05:43:58 -0800 (PST) In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF8195350C7@DEMUMBX005.nsn-intra.net> References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> <56C2F665D49E0341B9DF5938005ACDF8195350C7@DEMUMBX005.nsn-intra.net> Date: Fri, 5 Dec 2014 19:13:58 +0530 Message-ID: From: Suhas Nandakumar To: "Rauschenbach, Uwe (NSN - DE/Munich)" Content-Type: multipart/alternative; boundary=001a11c322eac9c5770509784407 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KtyDlzfp0qdbIICd-Qh9dvqEnVA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 13:44:04 -0000 --001a11c322eac9c5770509784407 Content-Type: text/plain; charset=UTF-8 +1 for adoption. On Fri, Dec 5, 2014 at 7:11 PM, Rauschenbach, Uwe (NSN - DE/Munich) < uwe.rauschenbach@nsn.com> wrote: > +1 for "A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG > Document" > > Kind regards, > Uwe > > > -----Original Message----- > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext > > Makaraju, Maridi Raju (Raju) > > Sent: Friday, December 05, 2014 1:28 PM > > To: Cullen Jennings (fluffy); rtcweb@ietf.org > > Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb- > > gateways > > > > > A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG > > document > > > now > > > > YES, please. > > > > BR > > Raju > > > > _______________________________________________ > > 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 > --001a11c322eac9c5770509784407 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for adoption.

On Fri, Dec 5, 2014 at 7:11 PM, Rauschenbach, Uwe (NS= N - DE/Munich) <uwe.rauschenbach@nsn.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">+1 for "A) yes, draft-alvestrand-rtcweb-= gateways should be adopted as a WG
Document"

Kind regards,
Uwe

> -----Original Message-----
> From: rtcweb [mailto:rtcweb= -bounces@ietf.org] On Behalf Of ext
> Makaraju, Maridi Raju (Raju)
> Sent: Friday, December 05, 2014 1:28 PM
> To: Cullen Jennings (fluffy); rtcwe= b@ietf.org
> Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb- > gateways
>
> > A) yes, draft-alve= strand-rtcweb-gateways should be adopted as a WG
> document
> > now
>
> YES, please.
>
> BR
> Raju
>
> _______________________________________________
> 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

--001a11c322eac9c5770509784407-- From nobody Fri Dec 5 07:39:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F541ACE9C for ; Fri, 5 Dec 2014 07:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zncdDqMn_vJq for ; Fri, 5 Dec 2014 07:39:20 -0800 (PST) Received: from hs8.name.com (hs8.name.com [173.193.131.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1EC11ACE97 for ; Fri, 5 Dec 2014 07:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ranjitvoip.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=zGVEnag/J0JHIpFSbku1MvugGIoyC1ZZI1ZhAx/QaMA=; b=INZKWsz/zBRVR/aSdmwoaFxjqYQAup8RJmJrQKwIeW1oZ9rt3Y4npGpZNhPUewuQC1ro/N9CtZUsgDBZNmFvzkfe5YHHyR+fcK+OPFQZKP8mBRkXkor7amLtfB95bM9Ugbs4iEFV3xmyiwZEh3XnTVJbxJKDqyYNLfSwaU8QSsA=; Received: from localhost.localdomain ([127.0.0.1]:33093 helo=webmail.ranjitvoip.com) by hs8.name.com with esmtpa (Exim 4.84) (envelope-from ) id 1XwuyT-001ZyZ-7w; Fri, 05 Dec 2014 09:39:17 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 05 Dec 2014 09:39:17 -0600 From: ranjit@ranjitvoip.com To: Harald Alvestrand In-Reply-To: <5481672E.4080305@alvestrand.no> References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> <5481672E.4080305@alvestrand.no> Message-ID: X-Sender: ranjit@ranjitvoip.com User-Agent: Roundcube Webmail/1.0.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hs8.name.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ranjitvoip.com X-Get-Message-Sender-Via: hs8.name.com: authenticated_id: ranjit@ranjitvoip.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tzO0dtKGlHL9PADfxUhq1TZuwes Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 15:39:21 -0000 yes it should be adopted as WG item Regards Ranjit On 2014-12-05 2:05 am, Harald Alvestrand wrote: > Just to get the ball rolling: > > A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG > document now. > > On 12/04/2014 08:29 PM, Cullen Jennings (fluffy) wrote: >> Having reviewed the fine technical comments on this draft since we >> asked for comments, the chairs have noted that multiple people seem to >> have read the draft. Given this great news we are going make a call >> for adoption. >> >> If you have an opinion, please email the list by Dec 19 and let us >> know if you either: >> >> A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG >> document now >> >> B) no, not right now >> >> If we get consensus around A we will work with ADs on milestone. >> Otherwise we will encourage the authors to keep working on this draft >> and continue using this email list. We may adopt it later or include >> the text in other drafts. >> >> Thanks, >> The Chairs (Cullen, Sean, Ted) >> >> PS - if you want to send an email that says more than A or B, feel >> free to change the subject, start a new thread etc. >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 From nobody Fri Dec 5 09:04:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349471AD428 for ; Fri, 5 Dec 2014 09:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n_EJUxzFVRh for ; Fri, 5 Dec 2014 09:04:33 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2779F1AD42A for ; Fri, 5 Dec 2014 09:04:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1441; q=dns/txt; s=iport; t=1417799072; x=1419008672; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=UwwDqErbaWh50ucWEhgZBaKoGqzIKahPj24ym8eSrgk=; b=E5wQrQ8sW0/Wk8k8tWtQpQPlhv8chJLFt5uAvikoDeSzHalE7MXKMYKt uu9FSMpvUKXLgZS5LAmC3y4X4UzWg8lQPAs06/Q/Q2hThPD26vYJgFVM0 lKLw6I6KkQHEbN4xIVotUuB/S6/X0JsZRrxAJxED3D2wFDPycvbkgTouL Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFLlgVStJV2P/2dsb2JhbABZgwbPLRYBAQEBAX2EBAQeHUSBOQGIRAnWcgEBAQEBAQQBAQEBAQEBAQEZk3eBFQWKMI8vgSKFTSWMK4QQHoJzAQEB X-IronPort-AV: E=Sophos;i="5.07,522,1413244800"; d="scan'208";a="103057981" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP; 05 Dec 2014 17:04:18 +0000 Received: from [10.24.227.43] ([10.24.227.43]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sB5H4GHb008681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Dec 2014 17:04:17 GMT From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 5 Dec 2014 09:03:50 -0800 To: draft-alvestrand-rtcweb-gateways@tools.ietf.org, RTCWEB Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/h1C3L957NUjuoDFN0zrRarhQ6C4 Subject: [rtcweb] SRTP and draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 17:04:35 -0000 Today's adoption call for draft-alvestrand-rtcweb-gateways made me go = read it again. In its section titled "WebRTC device requirements that = can be relaxed", it says this: > If a gateway serves as a media relay into another RTP domain, it = MAY > choose to support only features available in that network. This > means that it MAY not (need to) support Bundle and any of the RTP/ > RTCP extensions related to it, RTCP-Mux, or Trickle Ice. However, = the > gateway MUST support DTLS-SRTP, since this is required for > interworking with WebRTC endpoints. That last sentence (starting with "However") is a requirement that = cannot be relaxed which makes it out of place in a section titled = "requirements that can be relaxed". I agree with what it is saying, but = either provide a full list of WebRTC device requirements that cannot be = relaxed (in its own section), or go into more detail about how DTLS-SRTP = needs to be implemented in a gateway. As one example, a gateway between = WebRTC and an RTP-only network (e.g., call center or whatever) or to a = TDM PBX, will need to support DTLS-SRTP towards WebRTC, but will not = support DTLS-SRTP (or any other sort of keying) towards the RTP-only = network or TDM PBX. Easiest is to simply remove the sentence starting = with "However". Also, a gateway should be able to function into a TDM = domain (not just "an RTP domain"). -d From nobody Fri Dec 5 09:44:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FDC1AD4A7 for ; Fri, 5 Dec 2014 09:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.019 X-Spam-Level: X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebH0_yK6qLi6 for ; Fri, 5 Dec 2014 09:44:03 -0800 (PST) Received: from smtpdg5.aruba.it (smtpdg5.aruba.it [62.149.158.235]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3851AD4AA for ; Fri, 5 Dec 2014 09:44:00 -0800 (PST) Received: from [217.201.200.3] ([217.201.200.3]) by smtpcmd05.ad.aruba.it with bizsmtp id Ptjw1p00P04twFM01tjwxC; Fri, 05 Dec 2014 18:43:57 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----4JSS4HKVH5330MQFHXIWJRB0UOPF6F" Content-Transfer-Encoding: 8bit From: Lorenzo Miniero Date: Fri, 05 Dec 2014 18:43:48 +0100 To: "Cullen Jennings (fluffy)" , "rtcweb@ietf.org" Message-ID: <07A7CF59-FA04-4B0D-93AC-4106BDE35655@meetecho.com> Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zQNW2HW_6eLYNMX0TxPF5YpYJXA Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 17:44:05 -0000 ------4JSS4HKVH5330MQFHXIWJRB0UOPF6F Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 A) Yes, L. Il 04 dicembre 2014 20:29:52 CET, "Cullen Jennings (fluffy)" ha scritto: >Having reviewed the fine technical comments on this draft since we >asked for comments, the chairs have noted that multiple people seem to >have read the draft. Given this great news we are going make a call for >adoption. > >If you have an opinion, please email the list by Dec 19 and let us know >if you either: > >A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG >document now > >B) no, not right now > >If we get consensus around A we will work with ADs on milestone. >Otherwise we will encourage the authors to keep working on this draft >and continue using this email list. We may adopt it later or include >the text in other drafts. > >Thanks, >The Chairs (Cullen, Sean, Ted) > >PS - if you want to send an email that says more than A or B, feel free >to change the subject, start a new thread etc. > > > > > > > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb -- Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. ------4JSS4HKVH5330MQFHXIWJRB0UOPF6F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit A) Yes,

L.

Il 04 dicembre 2014 20:29:52 CET, "Cullen Jennings (fluffy)" <fluffy@cisco.com> ha scritto:
Having reviewed the fine technical comments on this draft since we asked for comments, the chairs have noted that multiple people seem to have read the draft. Given this great news we are going make a call for adoption. 

If you have an opinion, please email the list by Dec 19 and let us know if you either:

A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG document now

B) no, not right now 

If we get consensus around A we will work with ADs on milestone. Otherwise we will encourage the authors to keep working on this draft and continue using this email list. We may adopt it later or include the text in other drafts. 

Thanks, 
The Chairs (Cullen, Sean, Ted)

PS - if you want to send an email that says more than A or B, feel free to change the subject, start a new thread etc. 









rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. ------4JSS4HKVH5330MQFHXIWJRB0UOPF6F-- From nobody Fri Dec 5 09:50:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369371AD49B for ; Fri, 5 Dec 2014 09:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtkiJRjmf7Q5 for ; Fri, 5 Dec 2014 09:50:39 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A408C1AD493 for ; Fri, 5 Dec 2014 09:50:38 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-20-5481f06c13d6 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5B.4B.04231.C60F1845; Fri, 5 Dec 2014 18:50:36 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.148]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 18:50:36 +0100 From: Salvatore Loreto To: "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways Thread-Index: AQHQD/is2LdRMrUKckucyL6VrCW5HJyBNz6A Date: Fri, 5 Dec 2014 17:50:35 +0000 Message-ID: <1E2F5D52-2B23-44D4-9E82-B3897FF1618B@ericsson.com> References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> In-Reply-To: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-ID: <1829BD3A5F7B3D4BB168CD53CB98E1BB@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3RjfnQ2OIwZPZxhYdk9ks1v5rZ3dg 8pjyeyOrx5IlP5kCmKK4bFJSczLLUov07RK4MhY2bWUu+MtZsWDTW7YGxi/sXYycHBICJhI7 pkxghrDFJC7cW8/WxcjFISRwhFHi0INrTBDOYkaJqbNesYFUsQmYSTx/uAWsQ0TAUKJpzzwm EJtZQF3izuJzYFOFBbwl+m48Y4Oo8ZH4d3w+K4RtJHFp1SaWLkYODhYBFYnNSxxBwrwC9hKv /9wDGykkYCPx9v0ysJGcArYSJ7s+MoLYjEDHfT+1BmqVuMStJ/OZII4WkFiy5zzUA6ISLx// Y4WwlSQW3f4MVa8jsWD3JzYI21ribOdRVghbW2LZwtfMEDcISpyc+YRlAqP4LCQrZiFpn4Wk fRaS9llI2hcwsq5iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECIy2g1t+6+5gXP3a8RCjAAej Eg/vBvnGECHWxLLiytxDjNIcLErivIvOzQsWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwOhU 8cVPwuagzL0m/wtxbq7F26TT2yLVCxMknoda/T990O2kxZNN51qv3Zh3SyjTyO7G+9LNlwKK LP3+K2XK7pOWnqW+S/vhCoYI6415px2at7/tdvxj7eZXcDIk1nPCjTl7DmXzCU4RWeDPzsbr vSTnfyuD2OSjDb+nZW47JN32aaW4oN3dC0osxRmJhlrMRcWJAJ+iMwaXAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/99ZFQzZLWmpid24e6hg6RZ7BgpU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 17:50:42 -0000 +1 for "A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG Document" br Salvatore On Dec 4, 2014, at 9:29 PM, Cullen Jennings (fluffy) wro= te: > Having reviewed the fine technical comments on this draft since we asked = for comments, the chairs have noted that multiple people seem to have read = the draft. Given this great news we are going make a call for adoption.=20 >=20 > If you have an opinion, please email the list by Dec 19 and let us know i= f you either: >=20 > A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG docume= nt now >=20 > B) no, not right now=20 >=20 > If we get consensus around A we will work with ADs on milestone. Otherwis= e we will encourage the authors to keep working on this draft and continue = using this email list. We may adopt it later or include the text in other d= rafts.=20 >=20 > Thanks,=20 > The Chairs (Cullen, Sean, Ted) >=20 > PS - if you want to send an email that says more than A or B, feel free t= o change the subject, start a new thread etc.=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Dec 5 10:21:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7ECB1ACE9C for ; Fri, 5 Dec 2014 10:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4F245x3JDSdt for ; Fri, 5 Dec 2014 10:21:08 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688EF1A6EE7 for ; Fri, 5 Dec 2014 10:21:08 -0800 (PST) Received: from [192.168.5.144] (173-164-120-204-Oregon.hfc.comcastbusiness.net [173.164.120.204]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 17E12F2248 for ; Fri, 5 Dec 2014 10:21:08 -0800 (PST) Message-ID: <5481F792.2060307@mozilla.com> Date: Fri, 05 Dec 2014 10:21:06 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> <1E2F5D52-2B23-44D4-9E82-B3897FF1618B@ericsson.com> In-Reply-To: <1E2F5D52-2B23-44D4-9E82-B3897FF1618B@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/w3sP_f2vFrlAqJmG1sO97Dd-xFI Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 18:21:10 -0000 Salvatore Loreto wrote: > +1 for "A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG > Document" +1 From nobody Fri Dec 5 10:57:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8291A1A1B63 for ; Fri, 5 Dec 2014 10:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEX1_6viMYT5 for ; Fri, 5 Dec 2014 10:57:00 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id A3CAA1A1AE3 for ; Fri, 5 Dec 2014 10:57:00 -0800 (PST) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 05 Dec 2014 13:56:55 -0500 Received: from XCT112CNC.rim.net (10.65.161.212) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.210.2; Fri, 5 Dec 2014 13:56:54 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT112CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Fri, 5 Dec 2014 13:56:54 -0500 From: Gaelle Martin-Cocher To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) Thread-Index: AQHQDyewEeqVo81nB0ShjNtLfXarlJx+j7gAgAAgMwD//7RIMIAAge4A///FiXCAAQTWgIABqNgw Date: Fri, 5 Dec 2014 18:56:53 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF359C76@XMB111CNC.rim.net> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F60A8.3080302@alvestrand.no> <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com> <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net> <547FA924.3000504@mozilla.com> <92D0D52F3A63344CA478CF12DB0648AADF35455C@XMB111CNC.rim.net> <548052E7.1050007@alvestrand.no> In-Reply-To: <548052E7.1050007@alvestrand.no> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FpYO3PXFoEGxXxhtdDxxWeKYAaw Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 18:57:02 -0000 Hi Harald,=20 Is that a google position or just an assumption? I don't think anyone has an issue with WebRTC-Compatible endpoint.=20 Assuming browsers have to implement both and that this question is out of t= he way. The remaining point is the 'non-browser', which is already differentiated b= y the note, and it is acknowledged that (over time?) they may only have one= codec to implement.=20 I don't see why revisiting the non-browser category is a problem. Ga=EBlle =09 -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestran= d Sent: Thursday, December 04, 2014 7:26 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, st= ill, sorry) On 12/04/2014 03:10 AM, Gaelle Martin-Cocher wrote: > There was a single hum for the three categories (browser, non-browser, co= mpatible endpoints), right? > > That makes a lot of sense for non-browser entities that are in fact WebRT= C-compatible enpoints (apps, or gateways or else) to push the burden on the= browser vendors as those entities will need to interact with browsers. He= nce "hum"... > > I think it would make a lot of sense to have different "hums" or question= s for the two different categories. > That will bring clarity on what the "non-browser" yet WebRTC endpoint is,= versus what the WebRTC-compatible endpoint is (let aside gateways). > It is not clear to me that we would have had the same results for each ca= tegory if there was two (or three) different questions. It is not clear that the questions are independent. In fact, it is pretty clear to me that some participants who were willing t= o go with this package deal were quite unwilling to commit to all the piece= s of the package if they were presented one at a time, and they had to answ= er the question not knowing how all the other pieces came out. I think this is a textbook case of a "package deal". _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Dec 5 11:11:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765921AD585 for ; Fri, 5 Dec 2014 11:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6g_vFMdTQYf for ; Fri, 5 Dec 2014 11:11:32 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213931AD584 for ; Fri, 5 Dec 2014 11:11:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417806691; x=2281720291; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=j7ROv8CNd85pASnIYbN+KfvI6VuKsdha6Js4sTjYFoo=; b=YeEaP9lPmusWbrlb1JRZrUP1L1c2DA3/y9U/g3XZbavIoXCvxfTDRXiYruQB3vy+ qQgMVcD4MQG5pI1t4GlJ4rY0ePo4bAD8lcy3/I1Nznsdo6DZkNJU3ZVLLzDpSHUA fTDajCAtEmMQX9Kyol9RCyf/FhelgE4AyDQRSl8bWQGCntT7aUIJsbCP/PpmIB+6 MDc3nEZwowO2dG8wpsDxM9nBGiI5GeKVrZA+AAoi++PMNbjHOJ7ZF/JAF4CagZKV ZqrpQyTZPoaiDNc6m/yo5CT4Wbq/5pWr5m7A6IprZr4OtasghkKr0pD9m7xeepYW d5K0XHjX9AvWXxz7Mo0FCg==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 0B.3A.06819.36302845; Fri, 5 Dec 2014 11:11:31 -0800 (PST) X-AuditID: 11973e13-f79656d000001aa3-61-5482036300b4 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 07.5B.05858.D5302845; Fri, 5 Dec 2014 11:11:25 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG400B4YIN7K520@marigold.apple.com> for rtcweb@ietf.org; Fri, 05 Dec 2014 11:11:31 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <20141205035706.GB21150@hex.shelbyville.oz> Date: Fri, 05 Dec 2014 11:11:30 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> To: Ron X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FDorJvM3BRiMPWkgcXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK2PP5IXvBbNGKoyvPMjcwtgl2MXJySAiYSDxaeo8NwhaTuHBv PZDNxSEksJdR4umXRiaYomeLr7NAJCYxSTz9epkVwpnPJPFzZztQhoODWUBdYsqUXJAGXgE9 iaYnj8GahQUiJI50nmEHsdkEVCUezDnGCGJzClhIPP9wmxXEZgGKv377DqyeWUBY4vvjeywQ trbEk3cXWCFm2kj8/7+bCWLvYSaJZZemgA0VEZCQePP+MTPEpbIS/y6CLOMCst+ySjQc+sg6 gVF4FsJ9s5DcNwvJjgWMzKsYhXITM3N0M/NM9RILCnJS9ZLzczcxggJ5up3wDsbTq6wOMQpw MCrx8K6QaAwRYk0sK67MPcQozcGiJM77jhcoJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTF1 9Ylz6br7jk9ccHT99D32hUlFpv6JfNpVv/hWOiRsZrm+7cTcU3ntO96nnjXu2H9io8SiCNbr F1Qzltd+TqtZeDXLhD9ffsGLvax5v6MSDLsPRD1Z5Kl6u4t/Mg/zcbZQ32+7LfwebjnKlrFI 0MtuS9qkCyFtYjU/9oT2CzjMkM4pSq/v2qPEUpyRaKjFXFScCADuVOXLRQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcohvL3BRisG2vpsXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK2PP5IXvBbNGKoyvPMjcwtgl2MXJySAiYSDxbfJ0FwhaTuHBv PVsXIxeHkMAkJomnXy+zQjjzmSR+7mwHquLgYBZQl5gyJRekgVdAT6LpyWMmEFtYIELiSOcZ dhCbTUBV4sGcY4wgNqeAhcTzD7dZQWwWoPjrt+/A6pkFhCW+P77HAmFrSzx5d4EVYqaNxP// u5kg9h5mklh2aQrYUBEBCYk37x8zQ1wqK/Hv4hn2CYwCsxBOmoXkpFlIxi5gZF7FKFCUmpNY aaSXWFCQk6qXnJ+7iREceIXOOxiPLbM6xCjAwajEw7tCojFEiDWxrLgy9xCjBAezkghv8myg EG9KYmVValF+fFFpTmrxIUZpDhYlcd6cd0ApgfTEktTs1NSC1CKYLBMHp1QDI5sm/6yc/tdb d648/mvRwy9HxF5xBDyJmiQ533KFvn6fydY3fEFqQgJynhIFVuvDmD3mcWZ47reocJHrathv +OvxXi99mzXHJ/I9uR5V4rzE7rXvw812HWsj5/VsMelpyj7tphD+MzH37MQyBXmjWL0DylmC u7jKFzLdan3qX/6jdOVt3oYMJZbijERDLeai4kQAiYZF0DgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tPeAygUg3gyalqcUyZhTxrYrd_A Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 19:11:35 -0000 > On Dec 4, 2014, at 19:57 , Ron wrote: >=20 > On Thu, Dec 04, 2014 at 02:03:44PM -0800, David Singer wrote: >>=20 >>> On Dec 4, 2014, at 13:59 , I=C3=B1aki Baz Castillo = wrote: >>>=20 >>> 2014-12-03 19:33 GMT+01:00 David Singer : >>>> As I understand it, the recent face to face meeting decided to = draft the requirement that WebRTC browsers be required to implement both = VP8 and H.264, and get feedback on this, on the list. >>>>=20 >>>> This is some feedback. >>>=20 >>> I've been searching in both the rtcweb and public-webrtc mailing >>> lists, and must say that it is VERY SAD that the only "contribution" >>> and "feedback" received from Apple are these regarding "MTI codecs", >>> nothing else. >>>=20 >>> I hope Apple has better things to do than sending FUD to working >>> groups in which they have no interest. >>=20 >> I apologize for both the fact that you think this is FUD, and for the = lack of other engagement. >>=20 >> Quite where you see the uncertainty and doubt in the =E2=80=9Cyou = MUST >> implement something which, it is stated, is subject to IPR which >> CANNOT be licensed=E2=80=9D, I am less sure. Fear, yes, I get that. >=20 > Are you seriously suggesting that the due diligence which Google's > team did prior to the acquisition of On2 and the VP8 IP was so > completely incompetent that they "somehow missed" the barnload of > random claims that Nokia have belatedly asserted here as a last > scorched earth defence after all other lines of sophistry were > apparently failing dismally? I love your colorful language. I might think that it optimistic to think = one could develop a motion-estimating, DCT-based, entropy-coded, codec = =E2=80=94 one that is in direct family from H.261 and MPEG-2 onwards =E2=80= =94 and avoid all the IPR. But your colorful language and happy faith in = these engineers, and others=E2=80=99 skepticism, are both beside the = point. There is a formal notice from a company that they believe they hold IPR = and they are unwilling to license. You and I can dislike the situation, = dislike patent law, dislike the procedures, or anything else, as much as = we wish, it doesn=E2=80=99t change them. For the IETF to insert a MUST into a specification it is instructing = companies, based on no visible analysis, and (unfortunately, since the = German case closed without a clear answer) no formal judgment, to defy = the claim and risk suit. That is clearly formally inappropriate. The = most we should do is to use a term from RFC 6919 (I=E2=80=99d suggest = sections 1 or 6). David Singer Manager, Software Standards, Apple Inc. From nobody Fri Dec 5 11:14:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524331AD5DA for ; Fri, 5 Dec 2014 11:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTGg_JSdLZVz for ; Fri, 5 Dec 2014 11:14:00 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 849931AD5C7 for ; Fri, 5 Dec 2014 11:13:53 -0800 (PST) Received: from Orochi.local ([12.216.224.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB5JDgeS029533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2014 13:13:43 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [12.216.224.110] claimed to be Orochi.local Message-ID: <548203E2.90602@nostrum.com> Date: Fri, 05 Dec 2014 11:13:38 -0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Gaelle Martin-Cocher , Harald Alvestrand , "rtcweb@ietf.org" References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F60A8.3080302@alvestrand.no> <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com> <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net> <547FA924.3000504@mozilla.com> <92D0D52F3A63344CA478CF12DB0648AADF35455C@XMB111CNC.rim.net> <548052E7.1050007@alvestrand.no> <92D0D52F3A63344CA478CF12DB0648AADF359C76@XMB111CNC.rim.net> In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF359C76@XMB111CNC.rim.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Fywo7gb7aVywlkAXFtIK6yYXQ34 Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 19:14:01 -0000 On 12/5/14 10:56, Gaelle Martin-Cocher wrote: > Is that a google position or just an assumption? We speak as individuals. > Assuming browsers have to implement both and that this question is out of the way. I was about to make the same point that Harald did, but he beat me to it: the questions were asked together because the nature of the compromise was, for many people, "I'm okay with X if and only if Y". Characterizing this as an unconditional acceptance of one without the other is ridiculous. /a From nobody Fri Dec 5 11:17:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D4C1AD5F0 for ; Fri, 5 Dec 2014 11:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHiTIZrCwVzS for ; Fri, 5 Dec 2014 11:17:38 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520D21AD5EC for ; Fri, 5 Dec 2014 11:17:38 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id z12so1718749wgg.15 for ; Fri, 05 Dec 2014 11:17:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3rMbWkBBTEBxK/VvaCIsWkdwR9qM9ZQconTBBRhCGA0=; b=Tqc3XIpJlIzlIRZKqBf8ShjGuTvMEeozvQM6eJ6+d26sN2MLg2ueBWJa05EVsj1pip z7W4iCgrbSTnBy1oZrvV7g+Yjaj96qO/srzxLGyzHvC4o6CgDG1tYeAfu5DOUeAWkD0L yokjlBO2InaKoUu0vdEbZvSn6rypDmFDl4I4OmRjlpaWbwWnwEb7wQnKxN68NaQlRwxY r1Urh2K77w75PbJbXIJ9PkTrZ7bFmOGSo/xBlwDDTa5SWVFFFsTCyqpbfa2F43Q16TZt gKf1frdPU38UFYz/NYMY4JBKCcMLkobrGhL3qrVkcX6DS3czSb5L0Q6VXbuyNsJ3Cl6L kxhg== X-Gm-Message-State: ALoCoQl1W40Ml7KN60Gi+5LiRXfg/7YoG/yXWMm7hM7TiDcTiSCx98UHXjvWFQ93WJZsZqJbtLIB X-Received: by 10.194.90.10 with SMTP id bs10mr15105576wjb.43.1417807057051; Fri, 05 Dec 2014 11:17:37 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com. [209.85.212.179]) by mx.google.com with ESMTPSA id vy7sm46011231wjc.27.2014.12.05.11.17.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Dec 2014 11:17:36 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ex7so2423899wid.0 for ; Fri, 05 Dec 2014 11:17:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.110.161 with SMTP id ib1mr27804698wjb.78.1417807055982; Fri, 05 Dec 2014 11:17:35 -0800 (PST) Received: by 10.216.70.16 with HTTP; Fri, 5 Dec 2014 11:17:35 -0800 (PST) In-Reply-To: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> Date: Fri, 5 Dec 2014 14:17:35 -0500 Message-ID: From: Roman Shpount To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=089e0102fc52ee96f505097ced4a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rgnQxbE4DxnxvUQSBsRjEy5Eb8g Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 19:17:40 -0000 --089e0102fc52ee96f505097ced4a Content-Type: text/plain; charset=UTF-8 Yes, please adopt the draft. _____________ Roman Shpount On Thu, Dec 4, 2014 at 2:29 PM, Cullen Jennings (fluffy) wrote: > Having reviewed the fine technical comments on this draft since we asked > for comments, the chairs have noted that multiple people seem to have read > the draft. Given this great news we are going make a call for adoption. > > If you have an opinion, please email the list by Dec 19 and let us know if > you either: > > A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG > document now > > B) no, not right now > > If we get consensus around A we will work with ADs on milestone. Otherwise > we will encourage the authors to keep working on this draft and continue > using this email list. We may adopt it later or include the text in other > drafts. > > Thanks, > The Chairs (Cullen, Sean, Ted) > > PS - if you want to send an email that says more than A or B, feel free to > change the subject, start a new thread etc. > > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e0102fc52ee96f505097ced4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, please adopt the draft.

_____________
R= oman Shpount

On Thu, Dec 4, 2014 at 2:29 PM, Cullen Jenni= ngs (fluffy) <fluffy@cisco.com> wrote:
Having reviewed the fine technical comments on this draft sin= ce we asked for comments, the chairs have noted that multiple people seem t= o have read the draft. Given this great news we are going make a call for a= doption.

If you have an opinion, please email the list by Dec 19 and let us know if = you either:

A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG document= now

B) no, not right now

If we get consensus around A we will work with ADs on milestone. Otherwise = we will encourage the authors to keep working on this draft and continue us= ing this email list. We may adopt it later or include the text in other dra= fts.

Thanks,
The Chairs (Cullen, Sean, Ted)

PS - if you want to send an email that says more than A or B, feel free to = change the subject, start a new thread etc.








_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--089e0102fc52ee96f505097ced4a-- From nobody Fri Dec 5 11:21:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6991AD5FD for ; Fri, 5 Dec 2014 11:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-L906B_dBQu for ; Fri, 5 Dec 2014 11:21:49 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EF971A00B2 for ; Fri, 5 Dec 2014 11:21:49 -0800 (PST) Received: from Orochi.local ([12.216.224.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB5JLkFc030205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2014 13:21:47 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [12.216.224.110] claimed to be Orochi.local Message-ID: <548205C7.3090805@nostrum.com> Date: Fri, 05 Dec 2014 11:21:43 -0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sean Turner , rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Lya45sWhKGBqK-vzmK4sGefiGuk Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 19:21:51 -0000 On 12/5/14 05:36, Sean Turner wrote: > After the discussion, some clarifying questions about the hums, and typing the hum questions on the screen, there was rough consensus in the room to add (aka “shoveâ€) the proposed text into draft-ietf-rtcweb-video. In keeping with IETF process, I am confirming this consensus call on the list. I believe it should go without saying, but I agree with the room consensus. /a From nobody Fri Dec 5 11:22:37 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7E01AD60A for ; Fri, 5 Dec 2014 11:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jClyMSxqWZRM for ; Fri, 5 Dec 2014 11:22:28 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D4741AD5DD for ; Fri, 5 Dec 2014 11:22:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417807348; x=2281720948; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CwUS2fofLreS6X1dBTEno08jg+p+1L8Jgb3UmrJBMMQ=; b=sUsrc/boPbtTTjDR27+NCc1a9sRBTGA0wCFEI0m7ZxDkW7S7jJ8zxrYsqzKixZu7 Fg2ZDaicmdD3vA/m316H6rsuWz2emEk2EgPblLzJkKSE7YeJufVWmTzz18WQbg9t e9MgL/7JvoFu86M5zoaRdBmFNZqe/K5ypACtHcaWadxtI9oGyONv5bGVlwtX47mh YrWbfY46ZJEBm5jm7ZNVvmfNQY9aZmATn7k6W4GH5RsaI0hX9AuV/Ani4ZySUyNe qPczdBITYKnMAjoaf0T7D6TCtcmEewZPAUdmTh6gN5yTQQm3T/m3fWvQMpg47pN+ 9lF5jt8bMjpFYk904wDRjQ==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 3E.1D.06819.4F502845; Fri, 5 Dec 2014 11:22:28 -0800 (PST) X-AuditID: 11973e13-f79656d000001aa3-ad-548205f4a980 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id FE.50.06123.6F502845; Fri, 5 Dec 2014 11:22:30 -0800 (PST) Received: from da0703a-dhcp60.apple.com (da0703a-dhcp60.apple.com [17.197.35.188]) by aniseed.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG40093RJ5F8P70@aniseed.apple.com> for rtcweb@ietf.org; Fri, 05 Dec 2014 11:22:28 -0800 (PST) MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-type: text/plain; charset=windows-1252 From: "Krasimir D. Kolarov" In-reply-to: Date: Fri, 05 Dec 2014 11:22:28 -0800 Content-transfer-encoding: quoted-printable Message-id: References: To: Sean Turner X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUi2FAYofuFtSnEYO4BUYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMfvCLuaCTTIViyYcYG5g7BDvYuTgkBAwkbjdl9fFyAlkiklc uLeerYuRi0NIYC+jxKqHrawQCROJ13uXMEIk+pkk5nz9xgzhrGWS6F11jBFkkrCArcTW60Eg DbwCehJNTx4zgYSZgez7F7VAwmwC+hJPX65nAbE5BWwkbnfNYgaxWQRUJc7NeQm2i1lAWOL7 43ssELa2xJN3F1ghRtpIPJ49hw3EFhKwlvi1dQWYLSKgJNGwcwcLxJ2yEv8unmEHOU1C4C2r xJPZrWwTGIVnITlpFsJJs5CsWMDIvIpRKDcxM0c3M89UL7GgICdVLzk/dxMjKISn2wnvYDy9 yuoQowAHoxIP7wqJxhAh1sSy4srcQ4zSHCxK4rzveIFCAumJJanZqakFqUXxRaU5qcWHGJk4 OKUaGDl+369y2PLjpFfDmzJlv6qzrQt2zxJ8rKqRPrFqp4OP9u0Zn9v+sBocm3R4j/H98y+j Dtc3dPOVWnof8q+zqc7iu8B9kK8iW2xdgXSlbbNoeOJ1hxllnlGib17emfFCbYXpOaFrmdUv M4sT4qfrFRtNjlx6nGG7xxrb8L5Hy7tFVT/w6Fb4KrEUZyQaajEXFScCAE2eGn5CAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FAsrvuNtSnEoOcch8Xaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmH1hF3PBJpmKRRMOMDcwdoh3MXJySAiYSLzeu4QRwhaTuHBv PVsXIxeHkEA/k8Scr9+YIZy1TBK9q44BVXFwCAvYSmy9HgTSwCugJ9H05DETSJgZyL5/UQsk zCagL/H05XoWEJtTwEbidtcsZhCbRUBV4tycl6wgNrOAsMT3x/dYIGxtiSfvLrBCjLSReDx7 DhuILSRgLfFr6wowW0RASaJh5w4WiDtlJf5dPMM+gVFgFpIrZiFcMQvJ1AWMzKsYBYpScxIr TfUSCwpyUvWS83M3MYKDrjBiB+P/ZVaHGAU4GJV4eFdINIYIsSaWFVfmHmKU4GBWEuFNng0U 4k1JrKxKLcqPLyrNSS0+xCjNwaIkzlvyDiglkJ5YkpqdmlqQWgSTZeLglGpg9JVm1Uvr2Zu5 uI1L6cLixlW5s2PF/T+Gblv81DfH9/9/Bm6JIy35t7V/r5de4y7WsFip3rrl1MytNYHxe+60 h7FfYOtdZWm/mGPG7crdtjOdEq9eqL3adD1CMT9GvnBRVPh9RfcKZzNOa78iti79a4sbNjJv W79f6a3pvaeT56wWl/39PrVciaU4I9FQi7moOBEACJN9CDYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YJUthEwffxqxNCdtuZOFZ7qbHGo Cc: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 19:22:35 -0000 To re-iterate what I said at the mike during the meeting, at this point = we can not support this draft, due to the existence of =93unwilling to = license" declaration on a technology required for compliance. The = discussion on point 1 below during the meeting and on the list has not = changed that situation. Krasimir > On Dec 5, 2014, at 5:36 AM, Sean Turner wrote: >=20 > All, >=20 > At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion = about codecs, which I dubbed "the great codec compromise." The = compromise text that was discussed appears in slides 12-14 at [4] (which = is a slight editorial variation of the text proposed at [2]). >=20 > This message serves to confirm the sense of the room. >=20 > In the room, I heard the following objections and responses (and I=92m = paraphrasing here), which I=92ll take the liberty of categorizing as = IPR, Time, and Trigger: >=20 > 1) IPR: >=20 > Objections: There are still IPR concerns which may restrict what a = particular organization feels comfortable with including in their = browser implementations. >=20 > Response: IPR concerns on this topic are well known. There is even a = draft summarizing the current IPR status for VP8: = draft-benham-rtcweb-vp8litigation. The sense of the room was still that = adopting the compromise text was appropriate. >=20 > 2) Time: >=20 > 2.1) Time to consider decision: >=20 > Objection: The decision to consider the compromise proposal at this = meeting was provided on short notice and did not provide some the = opportunity to attend in person. >=20 > Response: Six months ago the chairs made it clear discussion would be = revisited @ IETF 91 [0]. The first agenda proposal for the WG included = this topic [1], and the topic was never removed by the chairs. More = importantly, all decisions are confirmed on list; in person attendance = is not required to be part of the process. >=20 > 2.2) Time to consider text: >=20 > Objection: The proposed text [2] is too new to be considered. >=20 > Response: The requirement for browsers to support both VP8 and H.264 = was among the options in the straw poll conducted more than six months = ago. All decisions are confirmed on list so there will be ample time to = discuss the proposal. >=20 > 3) Trigger: >=20 > Objection: The =93trigger=94 sentence [3] is all kinds of wrong = because it=92s promising that the future IETF will update this = specification. >=20 > Response: Like any IETF proposal, an RFC that documents the current = proposal can be changed through the consensus process at any other time. >=20 >=20 > After the discussion, some clarifying questions about the hums, and = typing the hum questions on the screen, there was rough consensus in the = room to add (aka =93shove=94) the proposed text into = draft-ietf-rtcweb-video. In keeping with IETF process, I am confirming = this consensus call on the list. >=20 > If anyone has any other issues that they would like to raise please do = by December 19th. >=20 > Cheers, > spt (as chair) >=20 > [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html > [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html > [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html > [3] The one that begins with "If compelling evidence ..." > [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Dec 5 11:24:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147951AD60D for ; Fri, 5 Dec 2014 11:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhwNMaMQQJVb for ; Fri, 5 Dec 2014 11:24:55 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 99CE11AD605 for ; Fri, 5 Dec 2014 11:24:55 -0800 (PST) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 05 Dec 2014 14:24:55 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0210.002; Fri, 5 Dec 2014 14:24:54 -0500 From: Gaelle Martin-Cocher To: Adam Roach , Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) Thread-Index: AQHQDyewEeqVo81nB0ShjNtLfXarlJx+j7gAgAAgMwD//7RIMIAAge4A///FiXCAAQTWgIABqNgwgABbTwD//6xiUA== Date: Fri, 5 Dec 2014 19:24:53 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF359CE7@XMB111CNC.rim.net> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F60A8.3080302@alvestrand.no> <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com> <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net> <547FA924.3000504@mozilla.com> <92D0D52F3A63344CA478CF12DB0648AADF35455C@XMB111CNC.rim.net> <548052E7.1050007@alvestrand.no> <92D0D52F3A63344CA478CF12DB0648AADF359C76@XMB111CNC.rim.net> <548203E2.90602@nostrum.com> In-Reply-To: <548203E2.90602@nostrum.com> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Tullh9jogqT1towyGJdmjxiEKUw Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 19:24:57 -0000 VGhlIGF1ZGlvIGFyY2hpdmUgY2xlYXJseSBzaG93ZWQgdGhhdCBpbmRpdmlkdWFsIHdlcmUgdGFs a2luZyBvbiBiZWhhbGYgb2YgdGhlaXIgY29tcGFueTsgYnV0IGlmIHlvdSBkaXNtaXNzIHRoYXQs IEkgYW0gb2sgdG8gaGF2ZSBpbmRpdmlkdWFscyBhbnN3ZXJpbmcuDQoNCkkgaGF2ZSBub3Qgc2Vl biBtYW55IGVtYWlsIHN0YXRpbmcgIiJJJ20gb2theSB3aXRoIFggaWYgYW5kIG9ubHkgaWYgWSIu IGNhbiB5b3UgcG9pbnQgdGhhdCB0byBtZSwgaW4gdGhlIGNvbnRleHQgb2YgdGhpcyBwcm9wb3Nh bCB3aXRoIHRoZXNlIGNhdGVnb3JpZXM/DQoNCkkgdGhpbmsgd2hhdCBpcyByaWRpY3Vsb3VzIGlz IHRvIHB1c2ggbW9yZSBhY3RvcnMgdG8gYmUgYSB3ZWJSVEMtY29tcGF0aWJsZSBlbmRwb2ludCwg aXQgaXMgdW5jbGVhciB0aGV5IHdpbGwganVzdCBhdm9pZCBvbmUgY29kZWMsIHRoZXkgbWlnaHQg cmVtb3ZlIG11Y2ggbW9yZSBmcm9tIHRoZWlyIGFwcHMvZGV2aWNlcy9icm93c2VycyBldGMuIA0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBZGFtIFJvYWNoIFttYWlsdG86 YWRhbUBub3N0cnVtLmNvbV0gDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDA1LCAyMDE0IDI6MTQg UE0NClRvOiBHYWVsbGUgTWFydGluLUNvY2hlcjsgSGFyYWxkIEFsdmVzdHJhbmQ7IHJ0Y3dlYkBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIEZpbmlzaGluZyB1cCB0aGUgVmlkZW8gQ29k ZWMgZG9jdW1lbnQsIE1USSAoYWdhaW4sIHN0aWxsLCBzb3JyeSkNCg0KT24gMTIvNS8xNCAxMDo1 NiwgR2FlbGxlIE1hcnRpbi1Db2NoZXIgd3JvdGU6DQo+IElzIHRoYXQgYSBnb29nbGUgcG9zaXRp b24gb3IganVzdCBhbiBhc3N1bXB0aW9uPw0KDQpXZSBzcGVhayBhcyBpbmRpdmlkdWFscy4NCg0K DQo+IEFzc3VtaW5nIGJyb3dzZXJzIGhhdmUgdG8gaW1wbGVtZW50IGJvdGggYW5kIHRoYXQgdGhp cyBxdWVzdGlvbiBpcyBvdXQgb2YgdGhlIHdheS4NCg0KSSB3YXMgYWJvdXQgdG8gbWFrZSB0aGUg c2FtZSBwb2ludCB0aGF0IEhhcmFsZCBkaWQsIGJ1dCBoZSBiZWF0IG1lIHRvDQppdDogdGhlIHF1 ZXN0aW9ucyB3ZXJlIGFza2VkIHRvZ2V0aGVyIGJlY2F1c2UgdGhlIG5hdHVyZSBvZiB0aGUgY29t cHJvbWlzZSB3YXMsIGZvciBtYW55IHBlb3BsZSwgIkknbSBva2F5IHdpdGggWCBpZiBhbmQgb25s eSBpZiBZIi4gDQpDaGFyYWN0ZXJpemluZyB0aGlzIGFzIGFuIHVuY29uZGl0aW9uYWwgYWNjZXB0 YW5jZSBvZiBvbmUgd2l0aG91dCB0aGUgb3RoZXIgaXMgcmlkaWN1bG91cy4NCg0KL2ENCg== From nobody Fri Dec 5 11:41:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C881AD654 for ; Fri, 5 Dec 2014 11:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnsiAoqnHvrM for ; Fri, 5 Dec 2014 11:41:50 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E3B1A036B for ; Fri, 5 Dec 2014 11:41:50 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so2472741wid.5 for ; Fri, 05 Dec 2014 11:41:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=76o+SpO06Apcd/jN0VTvLFjaqQ3AjhwQjcQor/zft3k=; b=SEwzOGBEcphvugTBI94TEf8M7c0+cjeaVQzeiyQ6aPnaoMSx4h6/jHWmn4TUjfJ+02 p0cu9fULC+9VhOxnojcS8RjrtR3Wv+XDuslRpKfGLMwlu2vU9me2ARFdACtdqCHAD6Pb Iba/EZGTtzbARG1dwkcumgU2HvKlP2SBOshjhc97+zKIfe3MrLX7XPlCtnWUAKpIdo58 L9v6FKEq//m86Hl+3CUQyF5US0a3JBXV7JGdYQbqSqkMtmFz9XmamISVaFBTFui/23iY 15ZEoJhGMXZ9NeG++reLMnqKAE3a3zhDWwA6WK6HdpGbsjF4TN7Teuu2pAs2JdFZVaaE 2UTA== X-Received: by 10.194.92.116 with SMTP id cl20mr27382984wjb.71.1417808509223; Fri, 05 Dec 2014 11:41:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.211.131 with HTTP; Fri, 5 Dec 2014 11:41:29 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Fri, 5 Dec 2014 11:41:29 -0800 Message-ID: To: "Krasimir D. Kolarov" Content-Type: multipart/alternative; boundary=047d7bd910c28d4eba05097d44ec Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gxMR70-ygqCdd4XzBuCB9_Heyx0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 19:41:53 -0000 --047d7bd910c28d4eba05097d44ec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I also do not support the draft proposal for the following reasons: 1. The proposal imposes a dual MTI obligation on devices and applications. We should expect this recommendation to be widely ignored in practice because it offers no interoperability benefits, while increasing footprint and adding unnecessary liability/fees. The RFC 6919 "MUST (BUT WE KNOW YOU WON'T)" is appropriate here. Definition: The phrase "MUST (BUT WE KNOW YOU WON'T)" is used to indicate requirements that are needed to meet formal review criteria (e.g., mandatory-to-implement security mechanisms), when these mechanisms are too inconvenient for implementers to actually implement. 2. The codec standardization process is important from a legal and IPR disclosure point of view. VP8 has not yet completed this process. On Fri, Dec 5, 2014 at 11:22 AM, Krasimir D. Kolarov wrote: > To re-iterate what I said at the mike during the meeting, at this point w= e > can not support this draft, due to the existence of =E2=80=9Cunwilling to= license" > declaration on a technology required for compliance. The discussion on > point 1 below during the meeting and on the list has not changed that > situation. > > Krasimir > > > > On Dec 5, 2014, at 5:36 AM, Sean Turner wrote: > > > > All, > > > > At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion abou= t > codecs, which I dubbed "the great codec compromise." The compromise text > that was discussed appears in slides 12-14 at [4] (which is a slight > editorial variation of the text proposed at [2]). > > > > This message serves to confirm the sense of the room. > > > > In the room, I heard the following objections and responses (and I=E2= =80=99m > paraphrasing here), which I=E2=80=99ll take the liberty of categorizing a= s IPR, > Time, and Trigger: > > > > 1) IPR: > > > > Objections: There are still IPR concerns which may restrict what a > particular organization feels comfortable with including in their browser > implementations. > > > > Response: IPR concerns on this topic are well known. There is even a > draft summarizing the current IPR status for VP8: > draft-benham-rtcweb-vp8litigation. The sense of the room was still that > adopting the compromise text was appropriate. > > > > 2) Time: > > > > 2.1) Time to consider decision: > > > > Objection: The decision to consider the compromise proposal at this > meeting was provided on short notice and did not provide some the > opportunity to attend in person. > > > > Response: Six months ago the chairs made it clear discussion would be > revisited @ IETF 91 [0]. The first agenda proposal for the WG included th= is > topic [1], and the topic was never removed by the chairs. More > importantly, all decisions are confirmed on list; in person attendance is > not required to be part of the process. > > > > 2.2) Time to consider text: > > > > Objection: The proposed text [2] is too new to be considered. > > > > Response: The requirement for browsers to support both VP8 and H.264 wa= s > among the options in the straw poll conducted more than six months ago. > All decisions are confirmed on list so there will be ample time to discus= s > the proposal. > > > > 3) Trigger: > > > > Objection: The =E2=80=9Ctrigger=E2=80=9D sentence [3] is all kinds of w= rong because it=E2=80=99s > promising that the future IETF will update this specification. > > > > Response: Like any IETF proposal, an RFC that documents the current > proposal can be changed through the consensus process at any other time. > > > > > > After the discussion, some clarifying questions about the hums, and > typing the hum questions on the screen, there was rough consensus in the > room to add (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draft-ie= tf-rtcweb-video. > In keeping with IETF process, I am confirming this consensus call on the > list. > > > > If anyone has any other issues that they would like to raise please do > by December 19th. > > > > Cheers, > > spt (as chair) > > > > [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html > > [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html > > [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html > > [3] The one that begins with "If compelling evidence ..." > > [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf > > _______________________________________________ > > 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 > --047d7bd910c28d4eba05097d44ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also do not support the draft proposal for the foll= owing reasons:

1. The proposal imposes a dual MTI= obligation on devices and applications.=C2=A0=C2=A0We should=C2=A0expect t= his recommendation to be widely ignored in practice because it offers no in= teroperability benefits, while increasing footprint and adding unnecessary= =C2=A0liability/fees. The RFC=C2=A06919 "MUST (BUT WE KNOW YOU WON'= ;T)"=C2=A0is appropriate here.=C2=A0=C2=A0Definition:

=C2=A0=C2=A0 The phrase "MUST (BUT WE KNOW YOU WON'T)&quo= t; is used to indicate
=C2=A0=C2=A0 requirements that are needed to meet= formal review criteria (e.g.,
=C2=A0=C2=A0 mandatory-to-implement secur= ity mechanisms), when these mechanisms
=C2=A0=C2=A0 are too inconvenient= for implementers to actually implement.=C2=A0=C2=A0

2.=C2=A0The codec=C2=A0standardization process is important from a legal= and IPR disclosure point of view.=C2=A0 VP8 has not yet completed this pro= cess.

On Fri, Dec 5, 2014 at 11:22 AM, Krasimir D. Kolarov <= ;kolarov@apple.com> wrote:
To re-iterate what I= said at the mike during the meeting, at this point we can not support this= draft, due to the existence of =E2=80=9Cunwilling to license" declara= tion on a technology required for compliance. The discussion on point 1 bel= ow during the meeting and on the list has not changed that situation.

Krasimir


> On Dec 5, 2014, at 5:36 AM, Sean Turner <TurnerS@ieca.com> wrote:
>
> All,
>
> At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion abo= ut codecs, which I dubbed "the great codec compromise."=C2=A0 The= compromise text that was discussed appears in slides 12-14 at [4] (which i= s a slight editorial variation of the text proposed at [2]).
>
> This message serves to confirm the sense of the room.
>
> In the room, I heard the following objections and responses (and I=E2= =80=99m paraphrasing here), which I=E2=80=99ll take the liberty of categori= zing as IPR, Time, and Trigger:
>
> 1) IPR:
>
> Objections: There are still IPR concerns which may restrict what a par= ticular organization feels comfortable with including in their browser impl= ementations.
>
> Response:=C2=A0 IPR concerns on this topic are well known.=C2=A0 There= is even a draft summarizing the current IPR status for VP8: draft-benham-r= tcweb-vp8litigation.=C2=A0 The sense of the room was still that adopting th= e compromise text was appropriate.
>
> 2) Time:
>
> 2.1) Time to consider decision:
>
> Objection: The decision to consider the compromise proposal at this me= eting was provided on short notice and did not provide some the opportunity= to attend in person.
>
> Response:=C2=A0 Six months ago the chairs made it clear discussion wou= ld be revisited @ IETF 91 [0]. The first agenda proposal for the WG include= d this topic [1], and the topic was never removed by the chairs.=C2=A0 =C2= =A0 More importantly, all decisions are confirmed on list; in person attend= ance is not required to be part of the process.
>
> 2.2) Time to consider text:
>
> Objection: The proposed text [2] is too new to be considered.
>
> Response: The requirement for browsers to support both VP8 and H.264 w= as among the options in the straw poll conducted more than six months ago.= =C2=A0 All decisions are confirmed on list so there will be ample time to d= iscuss the proposal.
>
> 3) Trigger:
>
> Objection: The =E2=80=9Ctrigger=E2=80=9D sentence [3] is all kinds of = wrong because it=E2=80=99s promising that the future IETF will update this = specification.
>
> Response: Like any IETF proposal, an RFC that documents the current pr= oposal can be changed through the consensus process at any other time.
>
>
> After the discussion, some clarifying questions about the hums, and ty= ping the hum questions on the screen, there was rough consensus in the room= to add (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draft-ietf-rtc= web-video.=C2=A0 In keeping with IETF process, I am confirming this consens= us call on the list.
>
> If anyone has any other issues that they would like to raise please do= by December 19th.
>
> Cheers,
> spt (as chair)
>
> [0] http://www.ietf.org/mail-archive/web/rtcweb/c= urrent/msg11194.html
> [1] http://www.ietf.org/mail-archive/web/rtcweb/c= urrent/msg13150.html
> [2] http://www.ietf.org/mail-archive/web/rtcweb/c= urrent/msg13432.html
> [3] The one that begins with "If compelling evidence ..." > [4] http://www.ietf.org/proceedings/91/slides/slid= es-91-rtcweb-7.pdf
> _______________________________________________
> 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

--047d7bd910c28d4eba05097d44ec-- From nobody Fri Dec 5 11:55:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9A01AD7BE for ; Fri, 5 Dec 2014 11:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKCdD5g-kXK9 for ; Fri, 5 Dec 2014 11:55:20 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F131E1AD791 for ; Fri, 5 Dec 2014 11:55:19 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id h15so1327851igd.13 for ; Fri, 05 Dec 2014 11:55:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oCr7muizNnbvjmXrEr78dFL/pt946Ov2k772SjXSYcQ=; b=SMQNLz/IGHpw52FVX4aGOif7Oas1oIG2tkgKvKVtKg97WvLOcvGaCkulbl8JapY66d dFBhjbwivT50f5VX05fqdLcWBlpSMVyfLBbbJ2YE4ECFuSR7OsnpQ8KvP3a04o8E4d02 8IkH8hG+2kgBxSVwQqsTDW8sD/RPDTaKCd/Fw8hgHvbMgi3IuYjeuG66dQWuiH2vQV6e bMRsJBjLwzXdNXMQBjb/jtqYXqRexpBkFXvEGOdcNHfx8EKgLHAgKvt2/0Ob3Mh7mckL Jyi0O4yCrW/hmfmjaZDSPMBtp1Hjtbvn5IX/b9aie+PoMN5jMtPPGnF6rhrcuHYVNgrH XPfQ== MIME-Version: 1.0 X-Received: by 10.42.250.17 with SMTP id mm17mr17021116icb.18.1417809318397; Fri, 05 Dec 2014 11:55:18 -0800 (PST) Received: by 10.43.3.4 with HTTP; Fri, 5 Dec 2014 11:55:18 -0800 (PST) In-Reply-To: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> Date: Fri, 5 Dec 2014 11:55:18 -0800 Message-ID: From: Ted Hardie To: David Singer Content-Type: multipart/alternative; boundary=20cf3036404fc86ed305097d744e Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3AiM9oTuBYtUXiMEG67PBhrE2X8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 19:55:22 -0000 --20cf3036404fc86ed305097d744e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi David, On Fri, Dec 5, 2014 at 11:11 AM, David Singer wrote: > There is a formal notice from a company that they believe they hold IPR > and they are unwilling to license. You and I can dislike the situation, > dislike patent law, dislike the procedures, or anything else, as much as = we > wish, it doesn=E2=80=99t change them. > > For the IETF to insert a MUST into a specification it is instructing > companies, =E2=80=8BThis is fundamentally incorrect. The IETF writes voluntary standa= rds. A MUST in an IETF standard is not an instruction to a company; it is a description of the expected behaviour of an interoperable implementation. You are not required to implement the standard at all. At most, it is a description of what someone who claimed compliance to the standard is expected to have done. And note, "is expected" here has exactly no regulatory force; it is "is expected" by other interoperable implementations.=E2=80=8B > based on no visible analysis, and (unfortunately, since the German case > closed without a clear answer) no formal judgment, to defy the claim and > risk suit. =E2=80=8BThe IETF, as a body, does not undertake those analyses. Working g= roup members may undertake them when deciding whether to implement the standard.= =E2=80=8B > That is clearly formally inappropriate. The most we should do is to use = a > term from RFC 6919 (I=E2=80=99d suggest sections 1 or 6). > > =E2=80=8BApril 1 RFCs are an amusing lot, aren't they? =E2=80=8B =E2=80=8BThe proposed compromise contains multiple methods for handling the= risk you believe present: choose not to implement the standard; choose a different level compliance (endpoint); choose to accept the offer of a binary solution provided by others (as have put forward by both Cisco and Google). The sense of the room (as I heard it as participant from the floor) was that there were lots of people who could work with this compromise, those methods, and their perception of the risk. You are absolutely free to perform what risk analysis you like and to take whatever risk avoidance=E2=80=8B steps you deem appropriate. That might, s= adly, mean you remain on the sidelines as WebRTC moves forward. Whatever your choices there, please represent the IETF process correctly as you do so. regards, Ted Hardie as an individual > > David Singer > Manager, Software Standards, Apple Inc. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf3036404fc86ed305097d744e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi David,
On Fri, Dec 5, 2014 at 11:11 AM, David Singer = <singer@apple.com> wrote:
There is a formal notice from a company that they believe they hold IPR and= they are unwilling to license. You and I can dislike the situation, dislik= e patent law, dislike the procedures, or anything else, as much as we wish,= it doesn=E2=80=99t change them.

For the IETF to insert a MUST into a specification it is instructing compan= ies,

=E2=80=8BThis is fundamentally incorrec= t.=C2=A0 The IETF writes voluntary standards.=C2=A0 A MUST in an IETF stand= ard is not an instruction to a company; it is a description of the expected= behaviour of an interoperable implementation.=C2=A0 You are not required t= o implement the standard at all.=C2=A0 At most, it is a description of what= someone who claimed compliance to the standard is expected to have done.
And note, "is expected" here has exactly no= regulatory force; it is "is expected" by other interoperable imp= lementations.=E2=80=8B

=C2=A0
= based on no visible analysis, and (unfortunately, since the German case cl= osed without a clear answer) no formal judgment, to defy the claim and risk= suit.

=E2=80=8BThe IETF, as a body, does n= ot undertake those analyses.=C2=A0 Working group members may undertake them= when deciding whether to implement the standard.=E2=80=8B
=C2=A0
That is clearly formally inappropriate.=C2= =A0 The most we should do is to use a term from RFC 6919 (I=E2=80=99d sugge= st sections 1 or 6).


=E2=80= =8BApril 1 RFCs are an amusing lot, aren't they?=C2=A0 =E2=80=8B
<= br>
=E2=80=8BThe proposed compromise contains multiple methods for= handling the risk you believe present:=C2=A0 choose not to implement the s= tandard; choose a different level compliance (endpoint); choose to accept t= he offer of a binary solution provided by others (as have put forward by bo= th Cisco and Google).=C2=A0 The sense of the room (as I heard it as partici= pant from the floor) was that there were lots of people who could work with= this compromise, those methods, and their perception of the risk.

<= /div>
You are absolutely free to perform what risk analysis you li= ke and to take whatever risk avoidance=E2=80=8B steps you deem appropriate.= =C2=A0 That might, sadly, mean you remain on the sidelines as WebRTC moves = forward.=C2=A0 Whatever your choices there, please represent the IETF proce= ss correctly as you do so.

regards,

Ted Hard= ie
as an individual

=C2=A0

David Singer
Manager, Software Standards, Apple Inc.

____________________________= ___________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--20cf3036404fc86ed305097d744e-- From nobody Fri Dec 5 11:58:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8DC1A00E8 for ; Fri, 5 Dec 2014 11:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBpFBCw4qteE for ; Fri, 5 Dec 2014 11:58:45 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0574B1A00E1 for ; Fri, 5 Dec 2014 11:58:45 -0800 (PST) Received: from panoramix.jmvalin.ca (173-164-120-204-Oregon.hfc.comcastbusiness.net [173.164.120.204]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 97ACAF22B9; Fri, 5 Dec 2014 11:58:44 -0800 (PST) Message-ID: <54820E74.90201@mozilla.com> Date: Fri, 05 Dec 2014 14:58:44 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sean Turner , rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nH4r3inrKz_wvvn2kyliYidt7C4 Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 19:58:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Considering that: 1) We have committed to an MTI video codec 2) All consensus calls on "VP8 only" and "H.264 only" have failed 3) This is the only proposal that gets support from both camps I strongly support this MTI proposal. Please, let's close this debate once and for all. This compromise is by no means great, but it's much better than anything else we're going to get otherwise (i.e. more wasted time and still no MTI). Jean-Marc On 05/12/14 08:36 AM, Sean Turner wrote: > All, > > At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion > about codecs, which I dubbed "the great codec compromise." The > compromise text that was discussed appears in slides 12-14 at [4] > (which is a slight editorial variation of the text proposed at > [2]). > > This message serves to confirm the sense of the room. > > In the room, I heard the following objections and responses (and > I’m paraphrasing here), which I’ll take the liberty of categorizing > as IPR, Time, and Trigger: > > 1) IPR: > > Objections: There are still IPR concerns which may restrict what a > particular organization feels comfortable with including in their > browser implementations. > > Response: IPR concerns on this topic are well known. There is > even a draft summarizing the current IPR status for VP8: > draft-benham-rtcweb-vp8litigation. The sense of the room was > still that adopting the compromise text was appropriate. > > 2) Time: > > 2.1) Time to consider decision: > > Objection: The decision to consider the compromise proposal at > this meeting was provided on short notice and did not provide some > the opportunity to attend in person. > > Response: Six months ago the chairs made it clear discussion > would be revisited @ IETF 91 [0]. The first agenda proposal for the > WG included this topic [1], and the topic was never removed by the > chairs. More importantly, all decisions are confirmed on list; > in person attendance is not required to be part of the process. > > 2.2) Time to consider text: > > Objection: The proposed text [2] is too new to be considered. > > Response: The requirement for browsers to support both VP8 and > H.264 was among the options in the straw poll conducted more than > six months ago. All decisions are confirmed on list so there will > be ample time to discuss the proposal. > > 3) Trigger: > > Objection: The “trigger” sentence [3] is all kinds of wrong > because it’s promising that the future IETF will update this > specification. > > Response: Like any IETF proposal, an RFC that documents the > current proposal can be changed through the consensus process at > any other time. > > > After the discussion, some clarifying questions about the hums, > and typing the hum questions on the screen, there was rough > consensus in the room to add (aka “shove”) the proposed text into > draft-ietf-rtcweb-video. In keeping with IETF process, I am > confirming this consensus call on the list. > > If anyone has any other issues that they would like to raise > please do by December 19th. > > Cheers, spt (as chair) > > [0] > http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html > [1] > http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html > [2] > http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html > [3] The one that begins with "If compelling evidence ..." [4] > http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUgg5wAAoJEJ6/8sItn9q90aMH+gN/lwv67+DCxVoE1LggbZLK PIwig8wq/+wVW3kY/7wmqt7ZQVlGkxJLq/QaHqSzk3awwPFF8Ed3rrUCd75BK7mY 5BUB17cPfcLK/ehVs41T0jOILOX9aiHXadUebOmIetxJIdkzoJJYbNebA5J2ai+Y XSykzntzNcmCoHFjDXST3JJZtF/Zl/BdQjchvNYdNOCIhrs68oiokyfweg3Kxfrk WT3xmPXcxhkuPKxZNJi225c1zEQA4t2RBtNbpbjbnS63JnvcNJYu0gvR4hsg8/bR gIA+FIip3RRpKxlDoxWQSZhOHh1DQlP+kosDBVkvULre9BBL91yQHqH5Sp4OXIY= =LLMM -----END PGP SIGNATURE----- From nobody Fri Dec 5 11:59:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7AD41AD8E3 for ; Fri, 5 Dec 2014 11:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duAzn5NyZtmH for ; Fri, 5 Dec 2014 11:59:24 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54A5A1A00E8 for ; Fri, 5 Dec 2014 11:59:24 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 934BBDF847812; Fri, 5 Dec 2014 19:59:17 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sB5JxLEl020168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Dec 2014 20:59:21 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 20:59:21 +0100 From: "DRAGE, Keith (Keith)" To: Adam Roach , Sean Turner , "rtcweb@ietf.org" Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEJCGOxi9wNotXUawuapxE0F0cpyBT4OAgAAT+DA= Date: Fri, 5 Dec 2014 19:59:20 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B28DBE8@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <548205C7.3090805@nostrum.com> In-Reply-To: <548205C7.3090805@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kJt_FtcwHM3CRO125T03Ba4t5y0 Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 19:59:25 -0000 In that case you are agreeing with something that did not happen. By no str= etch of the imagination can the result of the RTCWEB session be declared as= "consensus". The chairman declared "rough consensus" in the room, which is an entirely d= ifferent concept. Keith=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 05 December 2014 19:22 > To: Sean Turner; rtcweb@ietf.org > Subject: Re: [rtcweb] confirming sense of the room: mti codec >=20 > On 12/5/14 05:36, Sean Turner wrote: > > After the discussion, some clarifying questions about the=20 > hums, and typing the hum questions on the screen, there was=20 > rough consensus in the room to add (aka "shove") the proposed=20 > text into draft-ietf-rtcweb-video. In keeping with IETF=20 > process, I am confirming this consensus call on the list. >=20 > I believe it should go without saying, but I agree with the=20 > room consensus. >=20 > /a >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From nobody Fri Dec 5 12:05:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448D01AD957 for ; Fri, 5 Dec 2014 12:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AI8Eg9Lc1jJ7 for ; Fri, 5 Dec 2014 12:05:51 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107221AD945 for ; Fri, 5 Dec 2014 12:05:51 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id n15so1149818lbi.16 for ; Fri, 05 Dec 2014 12:05:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HctESGaSb9fk59VsInoUyJhaOtVs8O9S8R3xi73SQno=; b=q+VWJP2yEneLCtJLcOHAzB94n0gbFOH/nShr4rowX7MtYkGtzYWkNeFIyEQCQG9Yrk +FbfP7ARh57WuXLmMgXpMGKy5sU6W4VmuB61WaALO5KrsBA5Hzi1k2nJwrjNU9RE8BgR 6UaWy6iw+RJUUpSpevi2FK7MyZupsA56Q5bmjFoOUnZIiWoXO/kTg0wzpGpAarXqnMPK dzNVg5qds+BXngs7a/U6WcqCbpuAGYrxYBxGlJqb0SVfii/CE+gxKR0SsaB+h1aO8A7p TCPGkFQ63q2UFwO4vM35cth7VDHXWHp9o8qrB8pbaTHXavPotjtdW7MzPtWXChvkAj7x LKtw== MIME-Version: 1.0 X-Received: by 10.152.6.166 with SMTP id c6mr4646524laa.20.1417809949584; Fri, 05 Dec 2014 12:05:49 -0800 (PST) Sender: metajack@gmail.com Received: by 10.25.38.203 with HTTP; Fri, 5 Dec 2014 12:05:49 -0800 (PST) In-Reply-To: <54820E74.90201@mozilla.com> References: <54820E74.90201@mozilla.com> Date: Fri, 5 Dec 2014 13:05:49 -0700 X-Google-Sender-Auth: X9IsQe-FDN16alASVb710yWoPoM Message-ID: From: Jack Moffitt To: Jean-Marc Valin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qaXNZhnOiDWEUWH9SF941Zblpr4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 20:05:52 -0000 > Considering that: > 1) We have committed to an MTI video codec > 2) All consensus calls on "VP8 only" and "H.264 only" have failed > 3) This is the only proposal that gets support from both camps > I strongly support this MTI proposal. +1 jack. From nobody Fri Dec 5 12:18:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCF51A0151 for ; Fri, 5 Dec 2014 12:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfRsuc1bSgpO for ; Fri, 5 Dec 2014 12:18:11 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id C920F1A0143 for ; Fri, 5 Dec 2014 12:18:10 -0800 (PST) Received: from smtp-pop.rim.net (HELO XCT103CNC.rim.net) ([10.65.161.203]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 05 Dec 2014 15:18:01 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT103CNC.rim.net ([fe80::b8:d5e:26a5:f4d6%17]) with mapi id 14.03.0210.002; Fri, 5 Dec 2014 15:18:00 -0500 From: Gaelle Martin-Cocher To: Bernard Aboba , "Krasimir D. Kolarov" Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEJCKBITgiQUj50CzzuygMU2TV5yBtE0AgAAFUYD//648QA== Date: Fri, 5 Dec 2014 20:18:00 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF359DA5@XMB111CNC.rim.net> References: In-Reply-To: Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: multipart/alternative; boundary="_000_92D0D52F3A63344CA478CF12DB0648AADF359DA5XMB111CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4_GWEBtkTQfR4Lj0tRCdinCD0Yo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 20:18:15 -0000 --_000_92D0D52F3A63344CA478CF12DB0648AADF359DA5XMB111CNCrimnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHN1cHBvcnQgdGhlIHByb3Bvc2VkIHRleHQgZWl0aGVyLCBhbmQgKzEgb24gdGhl IHR3byBwb2ludHMgYmVsb3cuDQoNCkkgd291bGQgbGlrZSB0byBwb2ludCBvdXQgZmV3IGlzc3Vl cyBhbmQgcmVxdWVzdCB0aGF0Og0KKGFsbCByZXF1ZXN0cyBhcmUgaW5kZXBlbmRlbnQpDQphKSB3 ZSBoYXZlIGEgZGlzY3Vzc2lvbiBvbiBtYW5kYXRpbmcgY29kZWMgdmVyc3VzIGRlY29kZXIuIFRo ZXJlIHdhcyBhcHBhcmVudGx5IGxpdHRsZSB0byBubyB0aW1lIGF0IHRoZSBtZWV0aW5nIHRvIGRp c2N1c3MgdGhpcyBhbmQgcHJpb3IgZGlzY3Vzc2lvbnMgb24gdGhpcyB0b3BpYyBkaWQgbm90IGlu Y2x1ZGUgdGhlIHRocmVlIGNhdGVnb3JpZXMgdGhhdCBhcmUgbm93IGNvbnNpZGVyZWQuDQpiKSBU aGUgYnJvd3NlciBhbmQgbm9uLWJyb3dzZXIgY2F0ZWdvcmllcyAgYXJlIG5vdCBidW5kbGVkIHRv Z2V0aGVyIHdoZW4gbWFraW5nIHRoZSBkZWNpc2lvbi4gSWYgdGhlcmUgaXMgbm8gaW50ZW50aW9u IHRvIHJldmlzaXQgdGhlIGJyb3dzZXIgY2F0ZWdvcnksIEkgd291bGQgcHJvcG9zZSB0aGF0IG5v bi1icm93c2VyIHNoYWxsIHN1cHBvcnQgSC4yNjQgKHJlYXNvbmluZzogbW9zdCBpZiBub3QgYWxs IGFwcHMgYXJlIFdlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50cyBhbmQgY2FuIGRvIHdoYXRldmVy IHRoZXkgY2hvc2UsIG5vbi1icm93c2VyIGlzIGEgbmFycm93ZXIgY2F0ZWdvcnkgd2hpY2ggY291 bGQgaW5jbHVkZSBkZXZpY2VzIHdoaWNoIGhhdmUgdG8gc3VwcG9ydCBILjI2NCBhbnl3YXkpDQpj KSB0aGUgcmV2aXNpdGluZyBub3RlIHNob3VsZCBub3QgaGF2ZSB0aGUgc2FtZSBydWxlcyBmb3Ig dGhlIHR3byBjb2RlY3MsIGFzIFZQOCBwcm9wb25lbnRzIGFyZSBjbGFpbWluZyB0aGF0IFZQOCBp cyBmcmVlIGFuZCBBVkMgcHJvcG9uZW50cyBhcmUgbm90LCBpbnN0ZWFkIGFyZSBjbGFpbWluZyBB VkMgaXMgbmVlZGVkIGZvciBsZWdhY3kgcmVhc29ucy4gVGhlIG5vdGUgc2hvdWxkIGJlIHJldmlz aXRlZCBiZWZvcmUgdGhlIGRyYWZ0IGJlY29tZXMgYW4gUkZDLg0KDQpHYcOrbGxlDQoNCkZyb206 IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVy bmFyZCBBYm9iYQ0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAwNSwgMjAxNCAyOjQxIFBNDQpUbzog S3Jhc2ltaXIgRC4gS29sYXJvdg0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFty dGN3ZWJdIGNvbmZpcm1pbmcgc2Vuc2Ugb2YgdGhlIHJvb206IG10aSBjb2RlYw0KDQpJIGFsc28g ZG8gbm90IHN1cHBvcnQgdGhlIGRyYWZ0IHByb3Bvc2FsIGZvciB0aGUgZm9sbG93aW5nIHJlYXNv bnM6DQoNCjEuIFRoZSBwcm9wb3NhbCBpbXBvc2VzIGEgZHVhbCBNVEkgb2JsaWdhdGlvbiBvbiBk ZXZpY2VzIGFuZCBhcHBsaWNhdGlvbnMuICBXZSBzaG91bGQgZXhwZWN0IHRoaXMgcmVjb21tZW5k YXRpb24gdG8gYmUgd2lkZWx5IGlnbm9yZWQgaW4gcHJhY3RpY2UgYmVjYXVzZSBpdCBvZmZlcnMg bm8gaW50ZXJvcGVyYWJpbGl0eSBiZW5lZml0cywgd2hpbGUgaW5jcmVhc2luZyBmb290cHJpbnQg YW5kIGFkZGluZyB1bm5lY2Vzc2FyeSBsaWFiaWxpdHkvZmVlcy4gVGhlIFJGQyA2OTE5ICJNVVNU IChCVVQgV0UgS05PVyBZT1UgV09OJ1QpIiBpcyBhcHByb3ByaWF0ZSBoZXJlLiAgRGVmaW5pdGlv bjoNCg0KICAgVGhlIHBocmFzZSAiTVVTVCAoQlVUIFdFIEtOT1cgWU9VIFdPTidUKSIgaXMgdXNl ZCB0byBpbmRpY2F0ZQ0KICAgcmVxdWlyZW1lbnRzIHRoYXQgYXJlIG5lZWRlZCB0byBtZWV0IGZv cm1hbCByZXZpZXcgY3JpdGVyaWEgKGUuZy4sDQogICBtYW5kYXRvcnktdG8taW1wbGVtZW50IHNl Y3VyaXR5IG1lY2hhbmlzbXMpLCB3aGVuIHRoZXNlIG1lY2hhbmlzbXMNCiAgIGFyZSB0b28gaW5j b252ZW5pZW50IGZvciBpbXBsZW1lbnRlcnMgdG8gYWN0dWFsbHkgaW1wbGVtZW50Lg0KDQoyLiBU aGUgY29kZWMgc3RhbmRhcmRpemF0aW9uIHByb2Nlc3MgaXMgaW1wb3J0YW50IGZyb20gYSBsZWdh bCBhbmQgSVBSIGRpc2Nsb3N1cmUgcG9pbnQgb2Ygdmlldy4gIFZQOCBoYXMgbm90IHlldCBjb21w bGV0ZWQgdGhpcyBwcm9jZXNzLg0KDQpPbiBGcmksIERlYyA1LCAyMDE0IGF0IDExOjIyIEFNLCBL cmFzaW1pciBELiBLb2xhcm92IDxrb2xhcm92QGFwcGxlLmNvbTxtYWlsdG86a29sYXJvdkBhcHBs ZS5jb20+PiB3cm90ZToNClRvIHJlLWl0ZXJhdGUgd2hhdCBJIHNhaWQgYXQgdGhlIG1pa2UgZHVy aW5nIHRoZSBtZWV0aW5nLCBhdCB0aGlzIHBvaW50IHdlIGNhbiBub3Qgc3VwcG9ydCB0aGlzIGRy YWZ0LCBkdWUgdG8gdGhlIGV4aXN0ZW5jZSBvZiDigJx1bndpbGxpbmcgdG8gbGljZW5zZSIgZGVj bGFyYXRpb24gb24gYSB0ZWNobm9sb2d5IHJlcXVpcmVkIGZvciBjb21wbGlhbmNlLiBUaGUgZGlz Y3Vzc2lvbiBvbiBwb2ludCAxIGJlbG93IGR1cmluZyB0aGUgbWVldGluZyBhbmQgb24gdGhlIGxp c3QgaGFzIG5vdCBjaGFuZ2VkIHRoYXQgc2l0dWF0aW9uLg0KDQpLcmFzaW1pcg0KDQoNCj4gT24g RGVjIDUsIDIwMTQsIGF0IDU6MzYgQU0sIFNlYW4gVHVybmVyIDxUdXJuZXJTQGllY2EuY29tPG1h aWx0bzpUdXJuZXJTQGllY2EuY29tPj4gd3JvdGU6DQo+DQo+IEFsbCwNCj4NCj4gQXQgdGhlIDJu ZCBSVEN3ZWIgV0cgc2Vzc2lvbiBAIElFVEYgOTEsIHdlIGhhZCBhIGxpdmVseSBkaXNjdXNzaW9u IGFib3V0IGNvZGVjcywgd2hpY2ggSSBkdWJiZWQgInRoZSBncmVhdCBjb2RlYyBjb21wcm9taXNl LiIgIFRoZSBjb21wcm9taXNlIHRleHQgdGhhdCB3YXMgZGlzY3Vzc2VkIGFwcGVhcnMgaW4gc2xp ZGVzIDEyLTE0IGF0IFs0XSAod2hpY2ggaXMgYSBzbGlnaHQgZWRpdG9yaWFsIHZhcmlhdGlvbiBv ZiB0aGUgdGV4dCBwcm9wb3NlZCBhdCBbMl0pLg0KPg0KPiBUaGlzIG1lc3NhZ2Ugc2VydmVzIHRv IGNvbmZpcm0gdGhlIHNlbnNlIG9mIHRoZSByb29tLg0KPg0KPiBJbiB0aGUgcm9vbSwgSSBoZWFy ZCB0aGUgZm9sbG93aW5nIG9iamVjdGlvbnMgYW5kIHJlc3BvbnNlcyAoYW5kIEnigJltIHBhcmFw aHJhc2luZyBoZXJlKSwgd2hpY2ggSeKAmWxsIHRha2UgdGhlIGxpYmVydHkgb2YgY2F0ZWdvcml6 aW5nIGFzIElQUiwgVGltZSwgYW5kIFRyaWdnZXI6DQo+DQo+IDEpIElQUjoNCj4NCj4gT2JqZWN0 aW9uczogVGhlcmUgYXJlIHN0aWxsIElQUiBjb25jZXJucyB3aGljaCBtYXkgcmVzdHJpY3Qgd2hh dCBhIHBhcnRpY3VsYXIgb3JnYW5pemF0aW9uIGZlZWxzIGNvbWZvcnRhYmxlIHdpdGggaW5jbHVk aW5nIGluIHRoZWlyIGJyb3dzZXIgaW1wbGVtZW50YXRpb25zLg0KPg0KPiBSZXNwb25zZTogIElQ UiBjb25jZXJucyBvbiB0aGlzIHRvcGljIGFyZSB3ZWxsIGtub3duLiAgVGhlcmUgaXMgZXZlbiBh IGRyYWZ0IHN1bW1hcml6aW5nIHRoZSBjdXJyZW50IElQUiBzdGF0dXMgZm9yIFZQODogZHJhZnQt YmVuaGFtLXJ0Y3dlYi12cDhsaXRpZ2F0aW9uLiAgVGhlIHNlbnNlIG9mIHRoZSByb29tIHdhcyBz dGlsbCB0aGF0IGFkb3B0aW5nIHRoZSBjb21wcm9taXNlIHRleHQgd2FzIGFwcHJvcHJpYXRlLg0K Pg0KPiAyKSBUaW1lOg0KPg0KPiAyLjEpIFRpbWUgdG8gY29uc2lkZXIgZGVjaXNpb246DQo+DQo+ IE9iamVjdGlvbjogVGhlIGRlY2lzaW9uIHRvIGNvbnNpZGVyIHRoZSBjb21wcm9taXNlIHByb3Bv c2FsIGF0IHRoaXMgbWVldGluZyB3YXMgcHJvdmlkZWQgb24gc2hvcnQgbm90aWNlIGFuZCBkaWQg bm90IHByb3ZpZGUgc29tZSB0aGUgb3Bwb3J0dW5pdHkgdG8gYXR0ZW5kIGluIHBlcnNvbi4NCj4N Cj4gUmVzcG9uc2U6ICBTaXggbW9udGhzIGFnbyB0aGUgY2hhaXJzIG1hZGUgaXQgY2xlYXIgZGlz Y3Vzc2lvbiB3b3VsZCBiZSByZXZpc2l0ZWQgQCBJRVRGIDkxIFswXS4gVGhlIGZpcnN0IGFnZW5k YSBwcm9wb3NhbCBmb3IgdGhlIFdHIGluY2x1ZGVkIHRoaXMgdG9waWMgWzFdLCBhbmQgdGhlIHRv cGljIHdhcyBuZXZlciByZW1vdmVkIGJ5IHRoZSBjaGFpcnMuICAgIE1vcmUgaW1wb3J0YW50bHks IGFsbCBkZWNpc2lvbnMgYXJlIGNvbmZpcm1lZCBvbiBsaXN0OyBpbiBwZXJzb24gYXR0ZW5kYW5j ZSBpcyBub3QgcmVxdWlyZWQgdG8gYmUgcGFydCBvZiB0aGUgcHJvY2Vzcy4NCj4NCj4gMi4yKSBU aW1lIHRvIGNvbnNpZGVyIHRleHQ6DQo+DQo+IE9iamVjdGlvbjogVGhlIHByb3Bvc2VkIHRleHQg WzJdIGlzIHRvbyBuZXcgdG8gYmUgY29uc2lkZXJlZC4NCj4NCj4gUmVzcG9uc2U6IFRoZSByZXF1 aXJlbWVudCBmb3IgYnJvd3NlcnMgdG8gc3VwcG9ydCBib3RoIFZQOCBhbmQgSC4yNjQgd2FzIGFt b25nIHRoZSBvcHRpb25zIGluIHRoZSBzdHJhdyBwb2xsIGNvbmR1Y3RlZCBtb3JlIHRoYW4gc2l4 IG1vbnRocyBhZ28uICBBbGwgZGVjaXNpb25zIGFyZSBjb25maXJtZWQgb24gbGlzdCBzbyB0aGVy ZSB3aWxsIGJlIGFtcGxlIHRpbWUgdG8gZGlzY3VzcyB0aGUgcHJvcG9zYWwuDQo+DQo+IDMpIFRy aWdnZXI6DQo+DQo+IE9iamVjdGlvbjogVGhlIOKAnHRyaWdnZXLigJ0gc2VudGVuY2UgWzNdIGlz IGFsbCBraW5kcyBvZiB3cm9uZyBiZWNhdXNlIGl04oCZcyBwcm9taXNpbmcgdGhhdCB0aGUgZnV0 dXJlIElFVEYgd2lsbCB1cGRhdGUgdGhpcyBzcGVjaWZpY2F0aW9uLg0KPg0KPiBSZXNwb25zZTog TGlrZSBhbnkgSUVURiBwcm9wb3NhbCwgYW4gUkZDIHRoYXQgZG9jdW1lbnRzIHRoZSBjdXJyZW50 IHByb3Bvc2FsIGNhbiBiZSBjaGFuZ2VkIHRocm91Z2ggdGhlIGNvbnNlbnN1cyBwcm9jZXNzIGF0 IGFueSBvdGhlciB0aW1lLg0KPg0KPg0KPiBBZnRlciB0aGUgZGlzY3Vzc2lvbiwgc29tZSBjbGFy aWZ5aW5nIHF1ZXN0aW9ucyBhYm91dCB0aGUgaHVtcywgYW5kIHR5cGluZyB0aGUgaHVtIHF1ZXN0 aW9ucyBvbiB0aGUgc2NyZWVuLCB0aGVyZSB3YXMgcm91Z2ggY29uc2Vuc3VzIGluIHRoZSByb29t IHRvIGFkZCAoYWthIOKAnHNob3Zl4oCdKSB0aGUgcHJvcG9zZWQgdGV4dCBpbnRvIGRyYWZ0LWll dGYtcnRjd2ViLXZpZGVvLiAgSW4ga2VlcGluZyB3aXRoIElFVEYgcHJvY2VzcywgSSBhbSBjb25m aXJtaW5nIHRoaXMgY29uc2Vuc3VzIGNhbGwgb24gdGhlIGxpc3QuDQo+DQo+IElmIGFueW9uZSBo YXMgYW55IG90aGVyIGlzc3VlcyB0aGF0IHRoZXkgd291bGQgbGlrZSB0byByYWlzZSBwbGVhc2Ug ZG8gYnkgRGVjZW1iZXIgMTl0aC4NCj4NCj4gQ2hlZXJzLA0KPiBzcHQgKGFzIGNoYWlyKQ0KPg0K PiBbMF0gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50 L21zZzExMTk0Lmh0bWwNCj4gWzFdIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9ydGN3ZWIvY3VycmVudC9tc2cxMzE1MC5odG1sDQo+IFsyXSBodHRwOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1cnJlbnQvbXNnMTM0MzIuaHRtbA0KPiBbM10gVGhl IG9uZSB0aGF0IGJlZ2lucyB3aXRoICJJZiBjb21wZWxsaW5nIGV2aWRlbmNlIC4uLiINCj4gWzRd IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTEvc2xpZGVzL3NsaWRlcy05MS1ydGN3 ZWItNy5wZGYNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dl YkBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3 ZWINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0 Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K --_000_92D0D52F3A63344CA478CF12DB0648AADF359DA5XMB111CNCrimnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1Bs YWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWls U3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5QbGFpblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1 cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHN1cHBvcnQgdGhl IHByb3Bvc2VkIHRleHQgZWl0aGVyLCBhbmQgJiM0MzsxIG9uIHRoZSB0d28gcG9pbnRzIGJlbG93 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SSB3b3VsZCBsaWtlIHRvIHBvaW50IG91dCBmZXcgaXNzdWVzIGFuZCByZXF1 ZXN0IHRoYXQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPihhbGwgcmVxdWVzdHMgYXJl IGluZGVwZW5kZW50KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hKSB3ZSBoYXZlIGEg ZGlzY3Vzc2lvbiBvbiBtYW5kYXRpbmcgY29kZWMgdmVyc3VzIGRlY29kZXIuIFRoZXJlIHdhcyBh cHBhcmVudGx5IGxpdHRsZSB0byBubyB0aW1lIGF0IHRoZSBtZWV0aW5nIHRvIGRpc2N1c3MgdGhp cyBhbmQgcHJpb3IgZGlzY3Vzc2lvbnMgb24gdGhpcw0KIHRvcGljIGRpZCBub3QgaW5jbHVkZSB0 aGUgdGhyZWUgY2F0ZWdvcmllcyB0aGF0IGFyZSBub3cgY29uc2lkZXJlZC4gPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPmIpIFRoZSBicm93c2VyIGFuZCBub24tYnJvd3NlciBjYXRlZ29y aWVzJm5ic3A7IGFyZSBub3QgYnVuZGxlZCB0b2dldGhlciB3aGVuIG1ha2luZyB0aGUgZGVjaXNp b24uIElmIHRoZXJlIGlzIG5vIGludGVudGlvbiB0byByZXZpc2l0IHRoZSBicm93c2VyIGNhdGVn b3J5LCBJIHdvdWxkDQogcHJvcG9zZSB0aGF0IG5vbi1icm93c2VyIHNoYWxsIHN1cHBvcnQgSC4y NjQgKHJlYXNvbmluZzogbW9zdCBpZiBub3QgYWxsIGFwcHMgYXJlIFdlYlJUQy1jb21wYXRpYmxl IGVuZHBvaW50cyBhbmQgY2FuIGRvIHdoYXRldmVyIHRoZXkgY2hvc2UsIG5vbi1icm93c2VyIGlz IGEgbmFycm93ZXIgY2F0ZWdvcnkgd2hpY2ggY291bGQgaW5jbHVkZSBkZXZpY2VzIHdoaWNoIGhh dmUgdG8gc3VwcG9ydCBILjI2NCBhbnl3YXkpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PmMpIHRoZSByZXZpc2l0aW5nIG5vdGUgc2hvdWxkIG5vdCBoYXZlIHRoZSBzYW1lIHJ1bGVzIGZv ciB0aGUgdHdvIGNvZGVjcywgYXMgVlA4IHByb3BvbmVudHMgYXJlIGNsYWltaW5nIHRoYXQgVlA4 IGlzIGZyZWUgYW5kIEFWQyBwcm9wb25lbnRzIGFyZSBub3QsIGluc3RlYWQNCiBhcmUgY2xhaW1p bmcgQVZDIGlzIG5lZWRlZCBmb3IgbGVnYWN5IHJlYXNvbnMuIFRoZSBub3RlIHNob3VsZCBiZSBy ZXZpc2l0ZWQgYmVmb3JlIHRoZSBkcmFmdCBiZWNvbWVzIGFuIFJGQy4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+R2HD q2xsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFtt YWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJlcm5h cmQgQWJvYmE8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBEZWNlbWJlciAwNSwgMjAxNCAyOjQx IFBNPGJyPg0KPGI+VG86PC9iPiBLcmFzaW1pciBELiBLb2xhcm92PGJyPg0KPGI+Q2M6PC9iPiBy dGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIGNvbmZpcm1p bmcgc2Vuc2Ugb2YgdGhlIHJvb206IG10aSBjb2RlYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFsc28gZG8gbm90IHN1cHBvcnQgdGhlIGRyYWZ0IHByb3Bv c2FsIGZvciB0aGUgZm9sbG93aW5nIHJlYXNvbnM6DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gVGhlIHByb3Bvc2FsIGltcG9zZXMgYSBk dWFsIE1USSBvYmxpZ2F0aW9uIG9uIGRldmljZXMgYW5kIGFwcGxpY2F0aW9ucy4mbmJzcDsmbmJz cDtXZSBzaG91bGQmbmJzcDtleHBlY3QgdGhpcyByZWNvbW1lbmRhdGlvbiB0byBiZSB3aWRlbHkg aWdub3JlZCBpbiBwcmFjdGljZSBiZWNhdXNlIGl0IG9mZmVycyBubyBpbnRlcm9wZXJhYmlsaXR5 IGJlbmVmaXRzLCB3aGlsZSBpbmNyZWFzaW5nIGZvb3RwcmludCBhbmQgYWRkaW5nIHVubmVjZXNz YXJ5Jm5ic3A7bGlhYmlsaXR5L2ZlZXMuDQogVGhlIFJGQyZuYnNwOzY5MTkgJnF1b3Q7TVVTVCAo QlVUIFdFIEtOT1cgWU9VIFdPTidUKSZxdW90OyZuYnNwO2lzIGFwcHJvcHJpYXRlIGhlcmUuJm5i c3A7Jm5ic3A7RGVmaW5pdGlvbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IFRoZSBwaHJhc2UgJnF1b3Q7TVVTVCAoQlVU IFdFIEtOT1cgWU9VIFdPTidUKSZxdW90OyBpcyB1c2VkIHRvIGluZGljYXRlPGJyPg0KJm5ic3A7 Jm5ic3A7IHJlcXVpcmVtZW50cyB0aGF0IGFyZSBuZWVkZWQgdG8gbWVldCBmb3JtYWwgcmV2aWV3 IGNyaXRlcmlhIChlLmcuLDxicj4NCiZuYnNwOyZuYnNwOyBtYW5kYXRvcnktdG8taW1wbGVtZW50 IHNlY3VyaXR5IG1lY2hhbmlzbXMpLCB3aGVuIHRoZXNlIG1lY2hhbmlzbXM8YnI+DQombmJzcDsm bmJzcDsgYXJlIHRvbyBpbmNvbnZlbmllbnQgZm9yIGltcGxlbWVudGVycyB0byBhY3R1YWxseSBp bXBsZW1lbnQuJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjIuJm5ic3A7VGhlIGNvZGVjJm5ic3A7c3RhbmRhcmRpemF0aW9u IHByb2Nlc3MgaXMgaW1wb3J0YW50IGZyb20gYSBsZWdhbCBhbmQgSVBSIGRpc2Nsb3N1cmUgcG9p bnQgb2Ygdmlldy4mbmJzcDsgVlA4IGhhcyBub3QgeWV0IGNvbXBsZXRlZCB0aGlzIHByb2Nlc3Mu DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gRnJpLCBEZWMgNSwgMjAxNCBhdCAxMToyMiBBTSwgS3Jhc2ltaXIgRC4gS29sYXJvdiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmtvbGFyb3ZAYXBwbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+a29sYXJv dkBhcHBsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRvIHJlLWl0ZXJhdGUgd2hhdCBJIHNhaWQgYXQgdGhlIG1pa2UgZHVyaW5nIHRoZSBt ZWV0aW5nLCBhdCB0aGlzIHBvaW50IHdlIGNhbiBub3Qgc3VwcG9ydCB0aGlzIGRyYWZ0LCBkdWUg dG8gdGhlIGV4aXN0ZW5jZSBvZiDigJx1bndpbGxpbmcgdG8gbGljZW5zZSZxdW90OyBkZWNsYXJh dGlvbiBvbiBhIHRlY2hub2xvZ3kgcmVxdWlyZWQgZm9yIGNvbXBsaWFuY2UuIFRoZSBkaXNjdXNz aW9uIG9uIHBvaW50IDEgYmVsb3cgZHVyaW5nDQogdGhlIG1lZXRpbmcgYW5kIG9uIHRoZSBsaXN0 IGhhcyBub3QgY2hhbmdlZCB0aGF0IHNpdHVhdGlvbi48YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+S3Jhc2ltaXI8L3NwYW4+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQomZ3Q7IE9uIERlYyA1LCAyMDE0LCBhdCA1OjM2IEFNLCBTZWFuIFR1cm5lciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOlR1cm5lclNAaWVjYS5jb20iPlR1cm5lclNAaWVjYS5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBbGwsPGJyPg0KJmd0Ozxicj4NCiZndDsgQXQg dGhlIDJuZCBSVEN3ZWIgV0cgc2Vzc2lvbiBAIElFVEYgOTEsIHdlIGhhZCBhIGxpdmVseSBkaXNj dXNzaW9uIGFib3V0IGNvZGVjcywgd2hpY2ggSSBkdWJiZWQgJnF1b3Q7dGhlIGdyZWF0IGNvZGVj IGNvbXByb21pc2UuJnF1b3Q7Jm5ic3A7IFRoZSBjb21wcm9taXNlIHRleHQgdGhhdCB3YXMgZGlz Y3Vzc2VkIGFwcGVhcnMgaW4gc2xpZGVzIDEyLTE0IGF0IFs0XSAod2hpY2ggaXMgYSBzbGlnaHQg ZWRpdG9yaWFsIHZhcmlhdGlvbiBvZiB0aGUgdGV4dCBwcm9wb3NlZA0KIGF0IFsyXSkuPGJyPg0K Jmd0Ozxicj4NCiZndDsgVGhpcyBtZXNzYWdlIHNlcnZlcyB0byBjb25maXJtIHRoZSBzZW5zZSBv ZiB0aGUgcm9vbS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbiB0aGUgcm9vbSwgSSBoZWFyZCB0aGUg Zm9sbG93aW5nIG9iamVjdGlvbnMgYW5kIHJlc3BvbnNlcyAoYW5kIEnigJltIHBhcmFwaHJhc2lu ZyBoZXJlKSwgd2hpY2ggSeKAmWxsIHRha2UgdGhlIGxpYmVydHkgb2YgY2F0ZWdvcml6aW5nIGFz IElQUiwgVGltZSwgYW5kIFRyaWdnZXI6PGJyPg0KJmd0Ozxicj4NCiZndDsgMSkgSVBSOjxicj4N CiZndDs8YnI+DQomZ3Q7IE9iamVjdGlvbnM6IFRoZXJlIGFyZSBzdGlsbCBJUFIgY29uY2VybnMg d2hpY2ggbWF5IHJlc3RyaWN0IHdoYXQgYSBwYXJ0aWN1bGFyIG9yZ2FuaXphdGlvbiBmZWVscyBj b21mb3J0YWJsZSB3aXRoIGluY2x1ZGluZyBpbiB0aGVpciBicm93c2VyIGltcGxlbWVudGF0aW9u cy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBSZXNwb25zZTombmJzcDsgSVBSIGNvbmNlcm5zIG9uIHRo aXMgdG9waWMgYXJlIHdlbGwga25vd24uJm5ic3A7IFRoZXJlIGlzIGV2ZW4gYSBkcmFmdCBzdW1t YXJpemluZyB0aGUgY3VycmVudCBJUFIgc3RhdHVzIGZvciBWUDg6IGRyYWZ0LWJlbmhhbS1ydGN3 ZWItdnA4bGl0aWdhdGlvbi4mbmJzcDsgVGhlIHNlbnNlIG9mIHRoZSByb29tIHdhcyBzdGlsbCB0 aGF0IGFkb3B0aW5nIHRoZSBjb21wcm9taXNlIHRleHQgd2FzIGFwcHJvcHJpYXRlLjxicj4NCiZn dDs8YnI+DQomZ3Q7IDIpIFRpbWU6PGJyPg0KJmd0Ozxicj4NCiZndDsgMi4xKSBUaW1lIHRvIGNv bnNpZGVyIGRlY2lzaW9uOjxicj4NCiZndDs8YnI+DQomZ3Q7IE9iamVjdGlvbjogVGhlIGRlY2lz aW9uIHRvIGNvbnNpZGVyIHRoZSBjb21wcm9taXNlIHByb3Bvc2FsIGF0IHRoaXMgbWVldGluZyB3 YXMgcHJvdmlkZWQgb24gc2hvcnQgbm90aWNlIGFuZCBkaWQgbm90IHByb3ZpZGUgc29tZSB0aGUg b3Bwb3J0dW5pdHkgdG8gYXR0ZW5kIGluIHBlcnNvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBSZXNw b25zZTombmJzcDsgU2l4IG1vbnRocyBhZ28gdGhlIGNoYWlycyBtYWRlIGl0IGNsZWFyIGRpc2N1 c3Npb24gd291bGQgYmUgcmV2aXNpdGVkIEAgSUVURiA5MSBbMF0uIFRoZSBmaXJzdCBhZ2VuZGEg cHJvcG9zYWwgZm9yIHRoZSBXRyBpbmNsdWRlZCB0aGlzIHRvcGljIFsxXSwgYW5kIHRoZSB0b3Bp YyB3YXMgbmV2ZXIgcmVtb3ZlZCBieSB0aGUgY2hhaXJzLiZuYnNwOyAmbmJzcDsgTW9yZSBpbXBv cnRhbnRseSwgYWxsIGRlY2lzaW9ucyBhcmUgY29uZmlybWVkIG9uDQogbGlzdDsgaW4gcGVyc29u IGF0dGVuZGFuY2UgaXMgbm90IHJlcXVpcmVkIHRvIGJlIHBhcnQgb2YgdGhlIHByb2Nlc3MuPGJy Pg0KJmd0Ozxicj4NCiZndDsgMi4yKSBUaW1lIHRvIGNvbnNpZGVyIHRleHQ6PGJyPg0KJmd0Ozxi cj4NCiZndDsgT2JqZWN0aW9uOiBUaGUgcHJvcG9zZWQgdGV4dCBbMl0gaXMgdG9vIG5ldyB0byBi ZSBjb25zaWRlcmVkLjxicj4NCiZndDs8YnI+DQomZ3Q7IFJlc3BvbnNlOiBUaGUgcmVxdWlyZW1l bnQgZm9yIGJyb3dzZXJzIHRvIHN1cHBvcnQgYm90aCBWUDggYW5kIEguMjY0IHdhcyBhbW9uZyB0 aGUgb3B0aW9ucyBpbiB0aGUgc3RyYXcgcG9sbCBjb25kdWN0ZWQgbW9yZSB0aGFuIHNpeCBtb250 aHMgYWdvLiZuYnNwOyBBbGwgZGVjaXNpb25zIGFyZSBjb25maXJtZWQgb24gbGlzdCBzbyB0aGVy ZSB3aWxsIGJlIGFtcGxlIHRpbWUgdG8gZGlzY3VzcyB0aGUgcHJvcG9zYWwuPGJyPg0KJmd0Ozxi cj4NCiZndDsgMykgVHJpZ2dlcjo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPYmplY3Rpb246IFRoZSDi gJx0cmlnZ2Vy4oCdIHNlbnRlbmNlIFszXSBpcyBhbGwga2luZHMgb2Ygd3JvbmcgYmVjYXVzZSBp dOKAmXMgcHJvbWlzaW5nIHRoYXQgdGhlIGZ1dHVyZSBJRVRGIHdpbGwgdXBkYXRlIHRoaXMgc3Bl Y2lmaWNhdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBSZXNwb25zZTogTGlrZSBhbnkgSUVURiBw cm9wb3NhbCwgYW4gUkZDIHRoYXQgZG9jdW1lbnRzIHRoZSBjdXJyZW50IHByb3Bvc2FsIGNhbiBi ZSBjaGFuZ2VkIHRocm91Z2ggdGhlIGNvbnNlbnN1cyBwcm9jZXNzIGF0IGFueSBvdGhlciB0aW1l Ljxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBZnRlciB0aGUgZGlzY3Vzc2lvbiwgc29t ZSBjbGFyaWZ5aW5nIHF1ZXN0aW9ucyBhYm91dCB0aGUgaHVtcywgYW5kIHR5cGluZyB0aGUgaHVt IHF1ZXN0aW9ucyBvbiB0aGUgc2NyZWVuLCB0aGVyZSB3YXMgcm91Z2ggY29uc2Vuc3VzIGluIHRo ZSByb29tIHRvIGFkZCAoYWthIOKAnHNob3Zl4oCdKSB0aGUgcHJvcG9zZWQgdGV4dCBpbnRvIGRy YWZ0LWlldGYtcnRjd2ViLXZpZGVvLiZuYnNwOyBJbiBrZWVwaW5nIHdpdGggSUVURiBwcm9jZXNz LCBJIGFtIGNvbmZpcm1pbmcNCiB0aGlzIGNvbnNlbnN1cyBjYWxsIG9uIHRoZSBsaXN0Ljxicj4N CiZndDs8YnI+DQomZ3Q7IElmIGFueW9uZSBoYXMgYW55IG90aGVyIGlzc3VlcyB0aGF0IHRoZXkg d291bGQgbGlrZSB0byByYWlzZSBwbGVhc2UgZG8gYnkgRGVjZW1iZXIgMTl0aC48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBDaGVlcnMsPGJyPg0KJmd0OyBzcHQgKGFzIGNoYWlyKTxicj4NCiZndDs8YnI+ DQomZ3Q7IFswXSA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv cnRjd2ViL2N1cnJlbnQvbXNnMTExOTQuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50L21zZzExMTk0Lmh0bWw8 L2E+PGJyPg0KJmd0OyBbMV0gPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL3J0Y3dlYi9jdXJyZW50L21zZzEzMTUwLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9ydGN3ZWIvY3VycmVudC9tc2cxMzE1 MC5odG1sPC9hPjxicj4NCiZndDsgWzJdIDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9ydGN3ZWIvY3VycmVudC9tc2cxMzQzMi5odG1sIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1cnJlbnQv bXNnMTM0MzIuaHRtbDwvYT48YnI+DQomZ3Q7IFszXSBUaGUgb25lIHRoYXQgYmVnaW5zIHdpdGgg JnF1b3Q7SWYgY29tcGVsbGluZyBldmlkZW5jZSAuLi4mcXVvdDs8YnI+DQomZ3Q7IFs0XSA8YSBo cmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkxL3NsaWRlcy9zbGlkZXMtOTEt cnRjd2ViLTcucGRmIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL3Byb2Nl ZWRpbmdzLzkxL3NsaWRlcy9zbGlkZXMtOTEtcnRjd2ViLTcucGRmPC9hPjxicj4NCiZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHJ0 Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5v cmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PGJyPg0KPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_92D0D52F3A63344CA478CF12DB0648AADF359DA5XMB111CNCrimnet_-- From nobody Fri Dec 5 12:18:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1504F1A01D5 for ; Fri, 5 Dec 2014 12:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2B-sC-zOrtsq for ; Fri, 5 Dec 2014 12:18:15 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5551A0143 for ; Fri, 5 Dec 2014 12:18:15 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id hs14so1312814lab.11 for ; Fri, 05 Dec 2014 12:18:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hExxraBRyYPpWJbL42r7D93IkZXR3CKzF2qrqHjUMiY=; b=Dgo9YtUp0vtYpVR1lZHrhR8cYY5KYswl+27R2pTcccgkUSDJmzsj2vsFRQ3zlvQDzQ hAHZ2c6L2bgO7Og0rmdgtnW6asqIKZFkPJKIWjTtOcfMlbTraciS6VN22Kz2ZqOHzYIx 9lX7MVQVBiDT5gfAXa/JgvjzZ0z00qmwOITKQ8iKFxzIn/IezMJQVWGebYqGW/avPYgD EIGov36erdBHMwxacWduWyw4RZD4umkV8Wx5MS3Hie51EXRmGWGI1BI/Mb/tqRa8wFzk 8OP0ToGWTKXDizJpGvN/zrQHHS6tWey+PE88xXG+SblONG8Etdu70PEyx/p7Y9PA/fgh K/hw== X-Gm-Message-State: ALoCoQnm0gjSdPCHnZwkb/N4OzQTkPR+Qu4YOlLpBnL/PLJfiLwFEXZV+jurQlYb9flhR02Y4fd8 MIME-Version: 1.0 X-Received: by 10.112.61.169 with SMTP id q9mr4689114lbr.12.1417810693673; Fri, 05 Dec 2014 12:18:13 -0800 (PST) Received: by 10.112.199.69 with HTTP; Fri, 5 Dec 2014 12:18:13 -0800 (PST) In-Reply-To: <07A7CF59-FA04-4B0D-93AC-4106BDE35655@meetecho.com> References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> <07A7CF59-FA04-4B0D-93AC-4106BDE35655@meetecho.com> Date: Fri, 5 Dec 2014 14:18:13 -0600 Message-ID: From: Matt Fredrickson To: Lorenzo Miniero Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8i9ViH8z_MX3-NmuutEoUPLecv4 Cc: "Cullen Jennings \(fluffy\)" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 20:18:19 -0000 Yes, let's adopt it. Matthew Fredrickson On Fri, Dec 5, 2014 at 11:43 AM, Lorenzo Miniero wro= te: > A) Yes, > > L. > > Il 04 dicembre 2014 20:29:52 CET, "Cullen Jennings (fluffy)" > ha scritto: >> >> Having reviewed the fine technical comments on this draft since we asked >> for comments, the chairs have noted that multiple people seem to have re= ad >> the draft. Given this great news we are going make a call for adoption. >> >> If you have an opinion, please email the list by Dec 19 and let us know = if >> you either: >> >> A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG >> document now >> >> B) no, not right now >> >> If we get consensus around A we will work with ADs on milestone. Otherwi= se >> we will encourage the authors to keep working on this draft and continue >> using this email list. We may adopt it later or include the text in othe= r >> drafts. >> >> Thanks, >> The Chairs (Cullen, Sean, Ted) >> >> PS - if you want to send an email that says more than A or B, feel free = to >> change the subject, start a new thread etc. >> >> >> >> >> >> >> >> >> ________________________________ >> >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > -- > Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevit=C3= =A0. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --=20 Matthew Fredrickson Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA From nobody Fri Dec 5 12:24:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674BE1A01F9 for ; Fri, 5 Dec 2014 12:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQgwZvsZjh4T for ; Fri, 5 Dec 2014 12:23:58 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 604601A016A for ; Fri, 5 Dec 2014 12:23:58 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so2572167wiv.8 for ; Fri, 05 Dec 2014 12:23:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=JdvCBXrTxzmhz0egoVrSjYbcXd675Dl4eqqCeG/q2ew=; b=S5ndbWOAaAisZv9Qc0TRZybr7/tZz3Vd9EJ4UvGrp4mNg+HZrGONA3RyR990KlDQTW f7lz9g7+eyEfrsqzCbFqQcxLumkQlkhTVkI/fNf6PBXJ+c37PRyee0L/JhJwnnxD3B2c i9RgKgpFj9UuNS5FfCCmBPFYkYEK4hpjSfK6RdNT6Y6ZGfY7Jjg47+rUvSPjEVYbTAwF JwzF2D9dyFZsZYfQdloF+uPga5ziWFT3qCBMLtuTfpO7PfJ+LMdl4+UuxWFeCbg4CyT+ KA4xk+f7hj7mUD/h1nfmvpaGeD47npG9/T+9c1+JjclRqZSgTYeGB12ky24xHCz6PAtL +77g== X-Gm-Message-State: ALoCoQmMiXCgnZolGF8aeesrTpU+TCe+G3wGI+Wa3KdZYnmRtVBNrV1sM5AJMUQWSfcsSCo+ZbQE MIME-Version: 1.0 X-Received: by 10.194.80.193 with SMTP id t1mr12927933wjx.8.1417811036969; Fri, 05 Dec 2014 12:23:56 -0800 (PST) Received: by 10.194.6.39 with HTTP; Fri, 5 Dec 2014 12:23:56 -0800 (PST) Received: by 10.194.6.39 with HTTP; Fri, 5 Dec 2014 12:23:56 -0800 (PST) In-Reply-To: References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> <07A7CF59-FA04-4B0D-93AC-4106BDE35655@meetecho.com> Date: Fri, 5 Dec 2014 22:23:56 +0200 Message-ID: From: Mohammed Raad To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=047d7bdc8b9037b26a05097ddb31 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jb-9a-VZ8wZ46dVgveHFhcDnHt0 Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 20:24:00 -0000 --047d7bdc8b9037b26a05097ddb31 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm in support of adopting this as a WG document also. Mohammed On 5 Dec 2014 22:18, "Matt Fredrickson" wrote: > Yes, let's adopt it. > > Matthew Fredrickson > > On Fri, Dec 5, 2014 at 11:43 AM, Lorenzo Miniero > wrote: > > A) Yes, > > > > L. > > > > Il 04 dicembre 2014 20:29:52 CET, "Cullen Jennings (fluffy)" > > ha scritto: > >> > >> Having reviewed the fine technical comments on this draft since we ask= ed > >> for comments, the chairs have noted that multiple people seem to have > read > >> the draft. Given this great news we are going make a call for adoption= . > >> > >> If you have an opinion, please email the list by Dec 19 and let us kno= w > if > >> you either: > >> > >> A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG > >> document now > >> > >> B) no, not right now > >> > >> If we get consensus around A we will work with ADs on milestone. > Otherwise > >> we will encourage the authors to keep working on this draft and contin= ue > >> using this email list. We may adopt it later or include the text in > other > >> drafts. > >> > >> Thanks, > >> The Chairs (Cullen, Sean, Ted) > >> > >> PS - if you want to send an email that says more than A or B, feel fre= e > to > >> change the subject, start a new thread etc. > >> > >> > >> > >> > >> > >> > >> > >> > >> ________________________________ > >> > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > -- > > Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevit= =C3=A0. > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > -- > Matthew Fredrickson > Digium, Inc. | Senior Software Developer > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bdc8b9037b26a05097ddb31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm in support of adopting this as a WG document also.

Mohammed

On 5 Dec 2014 22:18, "Matt Fredrickson"= ; <creslin@digium.com> wrot= e:
Yes, let's ad= opt it.

Matthew Fredrickson

On Fri, Dec 5, 2014 at 11:43 AM, Lorenzo Miniero <lorenzo@meetecho.com> wrote:
> A) Yes,
>
> L.
>
> Il 04 dicembre 2014 20:29:52 CET, "Cullen Jennings (fluffy)"=
> <fluffy@cisco.com> ha sc= ritto:
>>
>> Having reviewed the fine technical comments on this draft since we= asked
>> for comments, the chairs have noted that multiple people seem to h= ave read
>> the draft. Given this great news we are going make a call for adop= tion.
>>
>> If you have an opinion, please email the list by Dec 19 and let us= know if
>> you either:
>>
>> A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG=
>> document now
>>
>> B) no, not right now
>>
>> If we get consensus around A we will work with ADs on milestone. O= therwise
>> we will encourage the authors to keep working on this draft and co= ntinue
>> using this email list. We may adopt it later or include the text i= n other
>> drafts.
>>
>> Thanks,
>> The Chairs (Cullen, Sean, Ted)
>>
>> PS - if you want to send an email that says more than A or B, feel= free to
>> change the subject, start a new thread etc.
>>
>>
>>
>>
>>
>>
>>
>>
>> ________________________________
>>
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> --
> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevit= =C3=A0.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>



--
Matthew Fredrickson
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--047d7bdc8b9037b26a05097ddb31-- From nobody Fri Dec 5 12:35:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF621A07BD for ; Fri, 5 Dec 2014 12:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rW7hpyGxTpSh for ; Fri, 5 Dec 2014 12:35:47 -0800 (PST) Received: from smtpdg11.aruba.it (smtpdg6.aruba.it [62.149.158.236]) by ietfa.amsl.com (Postfix) with ESMTP id E3E2D1A03A5 for ; Fri, 5 Dec 2014 12:35:46 -0800 (PST) Received: from rainpc ([79.10.52.197]) by smtpcmd04.ad.aruba.it with bizsmtp id Pwbk1p0054FHDuP01wbkXs; Fri, 05 Dec 2014 21:35:45 +0100 Date: Fri, 5 Dec 2014 21:35:43 +0100 From: Lorenzo Miniero To: Sean Turner Message-ID: <20141205213543.4f59807f@rainpc> In-Reply-To: References: Organization: Meetecho X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VEiKh1Q_LYBFnxbDUYzrhkJK5cA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 20:35:49 -0000 I support the proposal as the lesser of two evils. That said, it's peculiar and a bit depressing that the only ones that are complaining and keeping on wanting to impose on everybody an encumbered codec represent the only missing major browsers in the field, and so organizations that haven't contributed a single line of code so far to what WebRTC is today. All this talk of RFC6919 makes it quite clear that the "must implement both" will be blatantly ignored by H.264 advocates, and so one way or another they'll win anyway. I doubt that solutions that generate VP8 streams only (maybe because they can only do that), for instance, will be able to succeed in an ecosystem where half of the endpoints support both the codecs and half just one (the wrong one, of course), and the outcome is easy enough to guess. Lorenzo On Fri, 5 Dec 2014 08:36:30 -0500 Sean Turner wrote: > All, > > At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about codecs, which I dubbed "the great codec compromise." The compromise text that was discussed appears in slides 12-14 at [4] (which is a slight editorial variation of the text proposed at [2]). > > This message serves to confirm the sense of the room. > > In the room, I heard the following objections and responses (and I’m paraphrasing here), which I’ll take the liberty of categorizing as IPR, Time, and Trigger: > > 1) IPR: > > Objections: There are still IPR concerns which may restrict what a particular organization feels comfortable with including in their browser implementations. > > Response: IPR concerns on this topic are well known. There is even a draft summarizing the current IPR status for VP8: draft-benham-rtcweb-vp8litigation. The sense of the room was still that adopting the compromise text was appropriate. > > 2) Time: > > 2.1) Time to consider decision: > > Objection: The decision to consider the compromise proposal at this meeting was provided on short notice and did not provide some the opportunity to attend in person. > > Response: Six months ago the chairs made it clear discussion would be revisited @ IETF 91 [0]. The first agenda proposal for the WG included this topic [1], and the topic was never removed by the chairs. More importantly, all decisions are confirmed on list; in person attendance is not required to be part of the process. > > 2.2) Time to consider text: > > Objection: The proposed text [2] is too new to be considered. > > Response: The requirement for browsers to support both VP8 and H.264 was among the options in the straw poll conducted more than six months ago. All decisions are confirmed on list so there will be ample time to discuss the proposal. > > 3) Trigger: > > Objection: The “trigger” sentence [3] is all kinds of wrong because it’s promising that the future IETF will update this specification. > > Response: Like any IETF proposal, an RFC that documents the current proposal can be changed through the consensus process at any other time. > > > After the discussion, some clarifying questions about the hums, and typing the hum questions on the screen, there was rough consensus in the room to add (aka “shove”) the proposed text into draft-ietf-rtcweb-video. In keeping with IETF process, I am confirming this consensus call on the list. > > If anyone has any other issues that they would like to raise please do by December 19th. > > Cheers, > spt (as chair) > > [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html > [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html > [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html > [3] The one that begins with "If compelling evidence ..." > [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From nobody Fri Dec 5 12:37:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6963D1A0172 for ; Fri, 5 Dec 2014 12:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hkt0_Py954zY for ; Fri, 5 Dec 2014 12:37:46 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 276881A0673 for ; Fri, 5 Dec 2014 12:37:46 -0800 (PST) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 05 Dec 2014 15:37:44 -0500 Received: from XCT116CNC.rim.net (10.65.161.216) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.210.2; Fri, 5 Dec 2014 15:37:44 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Fri, 5 Dec 2014 15:37:44 -0500 From: Gaelle Martin-Cocher To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) Thread-Index: AQHQDyewEeqVo81nB0ShjNtLfXarlJx+9/iAgAAEnoCAADvngIAA7TwAgAAPMYCAAAL6AIAAA50AgAAFzgCAAAMQAIAAHfKAgAChiICAAG9VAA== Date: Fri, 5 Dec 2014 20:37:43 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF359DEB@XMB111CNC.rim.net> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> <1F326DF9-79C2-4562-853B-240D934EA235@apple.com> <949EF20990823C4C85C18D59AA11AD8B28CDFF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5480CEF2.4020204@mozilla.com> <949EF20990823C4C85C18D59AA11AD8B28CF6B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54816F91.9010108@alvestrand.no> In-Reply-To: <54816F91.9010108@alvestrand.no> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_njr8Lcn6MI3JSEvtgVZSbKlXDo Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 20:37:48 -0000 Harald,=20 Would you mind clarifying if that VP8 WebM CCL agreement is up to date (cop= yright is 2010-2013) and if it covers all the declarations that are listed = in https://tools.ietf.org/html/draft-benham-rtcweb-vp8litigation ? Ga=EBlle -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestran= d Sent: Friday, December 05, 2014 3:41 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, st= ill, sorry) On 12/05/2014 12:02 AM, DRAGE, Keith (Keith) wrote: > Both yours and David's responses to this are outside the IPR gathering ex= ercise that forms part of the standards process. > > The idea of the standards process is that a group of vendors etc write a = standard, they are forced to declare their IPR involved in that standard. I= f the population is sufficiently large you stand a good chance of identifyi= ng all the worldwide IPR relating to that standard. > > The bigger the standards organisation, with the greater coverage of all t= he vendors in that space, the better the process works. > > So at that level, IPR knowledge for codecs is primarily on the decoder sp= ace and what IPR exists there. > > What Tim is saying (and a somewhat parallel situation exists with MPEG LA= ) is that a limited set of organisations will limit your IPR problems and g= ive you some help with the encoder IPR. For VP8 that is limited to Google's= IPR and any background research they may have done. And, of course, the IPR owned by signatories to the license agreement that = Google has sublicensed through the WebM CCL:=20 http://www.webm-ccl.org/vp8/agreement/ > For MPEG LA it is limited to the members of the pool, which is only a s= ubset of those involved in the parallel standards process. Yes it helps, bu= t it does not have the degree of confidence of identifying all the existing= IPR that the standards process would do. > > Regards > > Keith > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Dec 5 12:44:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0501A1A73 for ; Fri, 5 Dec 2014 12:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aWJ6trBNik1 for ; Fri, 5 Dec 2014 12:44:37 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2F51A1A58 for ; Fri, 5 Dec 2014 12:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417812276; x=2281725876; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/k9wkltX6YW4f65YHkWCyj3iMDki+/N1Wjjhg9ogq+c=; b=d9CdlPGmgnA+kKYWnhnwJ9GXUag5JvN/bDr589N9nRh8ZCQqfW2v2EPuRrCRvc1h wMVinsUGCRl3wFEDRBpFXDm4BvPNCtdc/YKns7iU5B9bjYsIjEb9xBjVhNiyB7+b 0tQkueMrhFCj17Hxt9m0mrT6lAnYS929HpszgagnN4n/u2nTwsm0FpW+/E0YOccd cZddnB/Jh3xo0LOWMdNV/fs81bf2NOYkebKqjP73WCZvn1c7lh+lKzGhPp+m6Ebh C78/PqEvg56EJ4nXk6ztxXcR3ChvVQXjSsWAe6zPdXtay90GQV5I6MLkCjTDsuD/ DB3vXkuwu+npIaf2EyNWjA==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 31.5F.06819.43912845; Fri, 5 Dec 2014 12:44:36 -0800 (PST) X-AuditID: 11973e13-f79656d000001aa3-16-548219343317 Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id E7.7B.06091.51912845; Fri, 5 Dec 2014 12:44:05 -0800 (PST) Received: from [17.153.31.85] (unknown [17.153.31.85]) by cardamom.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG400KK8MYCX510@cardamom.apple.com> for rtcweb@ietf.org; Fri, 05 Dec 2014 12:44:36 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: Date: Fri, 05 Dec 2014 12:44:40 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> To: Ted Hardie X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUi2FCYqmsi2RRi8Pi1pcXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuNb/nLXgk2pFa8dN1gbGE3JdjJwcEgImEu+vnWSDsMUkLtxb D2RzcQgJ7GOUmLX5PStM0Z2Oo8wQiYlMErPPzmYESYA5E66ndjFycDALqEtMmZILEuYV0JNo evKYCcQWFoiQONJ5hh3EZhNQlXgw5xgjSDmnQLBE7y13kDALULhhaiNYObOArcTLt1vYIWxt iSfvLrBCjLSRON23hAXihL3MEsdePwc7WkRAWWLvlR1QD8hK/LsIsosLyH7LKvGoZxfTBEbh WQjnzUJy3iwkOxYwMq9iFMpNzMzRzcwz1UssKMhJ1UvOz93ECAri6XbCOxhPr7I6xCjAwajE w7tCojFEiDWxrLgy9xCjNAeLkjjvO16gkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkb/M72X YxMjlorsuhBZo776r5KMX19mSXTV9kKTjQ4pkxwzIg5f+iLu823qxCIp9guPH6Ztl5YT0hWZ os005d4h+UuXJQ8+KRYJavpsdViVSzA14W5S8r+j32stzUPvf71TdrWzgtviGsuxKVdCXkzf dMhQ9+5115gDrypk2cpmvTjY29/VvUuJpTgj0VCLuag4EQBznHGoQwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FAcpysq2RRi8GedhcXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuNb/nLXgk2pFa8dN1gbGE3JdjJwcEgImEnc6jjJD2GISF+6t Z+ti5OIQEpjIJDH77GxGkASYM+F6ahcjBwezgLrElCm5IGFeAT2JpiePmUBsYYEIiSOdZ9hB bDYBVYkHc44xgpRzCgRL9N5yBwmzAIUbpjaClTML2Eq8fLuFHcLWlnjy7gIrxEgbidN9S1gg TtjLLHHs9XM2kISIgLLE3is72CDulJX4d/EM+wRGgVkIF81CctEsJGMXMDKvYhQoSs1JrDTX SywoyEnVS87P3cQIDrrC1B2MjcutDjEKcDAq8fCukGgMEWJNLCuuzD3EKMHBrCTCmzwbKMSb klhZlVqUH19UmpNafIhRmoNFSZw35B1QSiA9sSQ1OzW1ILUIJsvEwSnVwNg8v0+1TnzWiT8l vvdt/rsfq6hiZ5y226724aus5HPKL499qn5TtP+lI/PaNz8YLl5sm/Xp+az9NfsrL/yb0+K5 9coeZb/cg8HLUsIYK1+Xz11iGZT6cbJbTPatvdVXe4vPMbO+in595nVj4t7zl8WEqu5OXvbv 0cpMj/Us6Qr1e6cd2rvCPPOWEktxRqKhFnNRcSIA6cFiFzYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/y0cxWWQjQLUE4TrnHfELKdvM4ag Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 20:44:39 -0000 > On Dec 5, 2014, at 11:55 , Ted Hardie wrote: >=20 > Hi David, >=20 > On Fri, Dec 5, 2014 at 11:11 AM, David Singer = wrote: > There is a formal notice from a company that they believe they hold = IPR and they are unwilling to license. You and I can dislike the = situation, dislike patent law, dislike the procedures, or anything else, = as much as we wish, it doesn=E2=80=99t change them. >=20 > For the IETF to insert a MUST into a specification it is instructing = companies, >=20 > =E2=80=8BThis is fundamentally incorrect. The IETF writes voluntary = standards. A MUST in an IETF standard is not an instruction to a = company; it is a description of the expected behaviour of an = interoperable implementation. You are not required to implement the = standard at all. At most, it is a description of what someone who = claimed compliance to the standard is expected to have done. OK, I apologize for the casual writing. =E2=80=9CIf you claim to = conform definition in this RFC, then you MUST=E2=80=A6=E2=80=9D = is effectively a conditional instruction. Yes, of course you get to = choose whether to implement at all (but you wouldn=E2=80=99t be here if = you hadn=E2=80=99t chosen to implement), and also which definition you = implement to (but see below). > And note, "is expected" here has exactly no regulatory force; it is = "is expected" by other interoperable implementations.=E2=80=8B It might not have regulatory force, but it might have consequences: = notably any IPR grants that are conditioned on =E2=80=9Cconforming = implementations=E2=80=9D, as I pointed out before. If you deliberately = don=E2=80=99t do a =E2=80=9Cmust=E2=80=9D (rather than, for example, = having a bug), your claim of conformance may be suspect and your license = therefore questionable. > based on no visible analysis, and (unfortunately, since the German = case closed without a clear answer) no formal judgment, to defy the = claim and risk suit. >=20 > =E2=80=8BThe IETF, as a body, does not undertake those analyses. = Working group members may undertake them when deciding whether to = implement the standard.=E2=80=8B > =20 > That is clearly formally inappropriate. The most we should do is to = use a term from RFC 6919 (I=E2=80=99d suggest sections 1 or 6). >=20 >=20 > =E2=80=8BApril 1 RFCs are an amusing lot, aren't they? =E2=80=8B Well, but that=E2=80=99s where we seem to be. They are amusing = precisely because they cut =E2=80=98close to the bone=E2=80=99. > =E2=80=8BThe proposed compromise contains multiple methods for = handling the risk you believe present: choose not to implement the = standard; choose a different level compliance (endpoint); This is where we stray into RFC 6919 territory. You=E2=80=99re = suggesting that an acceptable outcome is that some (many?) = implementations of WebRTC in products that are called Browsers might NOT = be, in fact, "WebRTC Browsers=E2=80=9D? This seems to both confuse the = expectation =E2=80=94 be contrary to a straightforward reading =E2=80=94 = and defeat the purpose (of interoperability). I was trying to treat the = specification more straightforwardly than this, and go with obvious = meanings and intentions. If this is the expected outcome we might need a note saying roughly = =E2=80=9CNote that not every WebRTC implementation in a browser is a = WebRTC Browser; some may be WebRTC Endpoints." > choose to accept the offer of a binary solution provided by others (as = have put forward by both Cisco and Google). =20 I didn=E2=80=99t reply to this before: the point of the Cisco offer is = not that it is binary, but that it carries a license. The difficulty = with VP8 is not, per se, in compiling the code, it=E2=80=99s the formal = refusal to license. > The sense of the room (as I heard it as participant from the floor) = was that there were lots of people who could work with this compromise, = those methods, and their perception of the risk. >=20 > You are absolutely free to perform what risk analysis you like and to = take whatever risk avoidance=E2=80=8B steps you deem appropriate. That = might, sadly, mean you remain on the sidelines as WebRTC moves forward. = Whatever your choices there, please represent the IETF process correctly = as you do so. I will try to be as precise as I can. My apologies for the casual = writing. best wishes >=20 > regards, >=20 > Ted Hardie > as an individual >=20 > =20 >=20 > David Singer > Manager, Software Standards, Apple Inc. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 David Singer Manager, Software Standards, Apple Inc. From nobody Fri Dec 5 13:08:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247B51A1AB8 for ; Fri, 5 Dec 2014 13:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOsYj-bQ_iAi for ; Fri, 5 Dec 2014 13:07:59 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 833F81A1A95 for ; Fri, 5 Dec 2014 13:07:59 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id tr6so1505682ieb.35 for ; Fri, 05 Dec 2014 13:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oyTZyxLTdM4uvs+z/FwJr0TzJo54wMTSaQPeq8PXz2g=; b=rd+GBQI7EAJhilJ7bCmFi5Cvt4TK9+usLUNJxL3KXseLTVOhn9kKnfjTe9kJ/BMseT S88ZP0zRIZzHigXNHxkdXdSoOvzGpqaJaOHkwEFo03PoU+vePBeuxCawwty8t9hmipa6 4jBP4yCZHBlkfJsPPS5lk9FWJ9I5lme2p80ICfT7QHDjshWabbCKw2+sfgZEtM6BbGyl JkxQb4uAVyenMpwLhkqFtPQEFKDR6LtuA2B0Nbmcu2D45pDnVBWVSpyo7tfUBrCX12UM TwRGi2syyebsTRCnoy9S2mbVciNC5iS9CZot1RQZHyhI2PQtuLSzACIpRATy17ulHap+ KNtA== MIME-Version: 1.0 X-Received: by 10.107.166.149 with SMTP id p143mr694850ioe.16.1417813678531; Fri, 05 Dec 2014 13:07:58 -0800 (PST) Received: by 10.43.3.4 with HTTP; Fri, 5 Dec 2014 13:07:58 -0800 (PST) In-Reply-To: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> Date: Fri, 5 Dec 2014 13:07:58 -0800 Message-ID: From: Ted Hardie To: David Singer Content-Type: multipart/alternative; boundary=001a1141f3c0aaab1f05097e78c3 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CZcScqdXpBfK2q22_1Jeb32iWsc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 21:08:03 -0000 --001a1141f3c0aaab1f05097e78c3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 5, 2014 at 12:44 PM, David Singer wrote: > > OK, I apologize for the casual writing. =E2=80=9CIf you claim to conform= > definition in this RFC, then you MUST=E2=80=A6=E2=80=9D is effectively a = conditional > instruction. Yes, of course you get to choose whether to implement at al= l > (but you wouldn=E2=80=99t be here if you hadn=E2=80=99t chosen to impleme= nt), and also > which definition you implement to (but see below). > =E2=80=8BMay I take your presence in this discussion as an indication that = you have chosen to implement?=E2=80=8B While I certainly would welcome such good news, there may well be folks here who are deciding whether and what to implement based on these decisions. What I heard in the room was a lot of folks who were willing to make this compromise to move forward, because it helped enable WebRTC as a whole (this was the main thrust of JDR's comments, for example). Speaking personally, I hope that means that the breadth of implementors will increase in the light of the options that will be available. > > And note, "is expected" here has exactly no regulatory force; it is "is > expected" by other interoperable implementations.=E2=80=8B > > It might not have regulatory force, but it might have consequences: > notably any IPR grants that are conditioned on =E2=80=9Cconforming > implementations=E2=80=9D, as I pointed out before. =E2=80=8BYou have pointed out that such IPR grants can exist. I did not se= e you point out=E2=80=8B any that applied to this case. If I missed that pointer= , I would appreciate your sharing it again. > If you deliberately don=E2=80=99t do a =E2=80=9Cmust=E2=80=9D (rather tha= n, for example, having a > bug), your claim of conformance may be suspect and your license therefore > questionable. > > > based on no visible analysis, and (unfortunately, since the German case > closed without a clear answer) no formal judgment, to defy the claim and > risk suit. > > > > =E2=80=8BThe IETF, as a body, does not undertake those analyses. Worki= ng group > members may undertake them when deciding whether to implement the standar= d.=E2=80=8B > > > > That is clearly formally inappropriate. The most we should do is to us= e > a term from RFC 6919 (I=E2=80=99d suggest sections 1 or 6). > > > > > > =E2=80=8BApril 1 RFCs are an amusing lot, aren't they? =E2=80=8B > > Well, but that=E2=80=99s where we seem to be. They are amusing precisely= because > they cut =E2=80=98close to the bone=E2=80=99. > > > =E2=80=8BThe proposed compromise contains multiple methods for handling= the risk > you believe present: choose not to implement the standard; choose a > different level compliance (endpoint); > > This is where we stray into RFC 6919 territory. You=E2=80=99re suggestin= g that an > acceptable outcome is that some (many?) implementations of WebRTC in > products that are called Browsers =E2=80=8BNo, I didn't say that. I noted that someone who is building based= on WebRTC has options here. The endpoint option may be workable for many (especially in the Mobile App space). While I am terribly fond of my browser colleagues, the real uptake here has to be among those who write applications on the WebRTC platform--and making that robust enough and varied enough for their needs is important. Note as well that I, personally, have never advocated for having a single codec available to an app or a browser; the methods for negotiating are a key part of this infrastructure, and they will be key to it moving forward as things progress. We worked toward a mandatory-to-implement to avoid interoperability failure. This compromise gets a pretty good way toward avoiding it=E2=80=8B and past what had been an impasse. Am I thrilled? No= . But it works well enough to be going along with. . > > I didn=E2=80=99t reply to this before: the point of the Cisco offer is no= t that it > is binary, but that it carries a license. The difficulty with VP8 is not= , > per se, in compiling the code, it=E2=80=99s the formal refusal to license= . > > OpenH264 notes that Cisco "will not pass on ... MPEG-LA licensing costs" and, as far as I can see, pretty much stops there=E2=80=8B. Google is also= not passing on its costs in VP8, if there are any. IF you believe that there are other, unbundled rights you need in either, then you should behave accordingly. But the two are exactly parallel: they require the participant to asses the available rights and risks. Others' assessments of those risks apparently differ from yours. > > The sense of the room (as I heard it as participant from the floor) was > that there were lots of people who could work with this compromise, those > methods, and their perception of the risk. > > > > You are absolutely free to perform what risk analysis you like and to > take whatever risk avoidance=E2=80=8B steps you deem appropriate. That m= ight, > sadly, mean you remain on the sidelines as WebRTC moves forward. Whateve= r > your choices there, please represent the IETF process correctly as you do > so. > > I will try to be as precise as I can. My apologies for the casual writin= g. > > =E2=80=8BThank you, and I will try to do the same. regards, Ted Hardie as an individual=E2=80=8B > best wishes > > > > > regards, > > > > Ted Hardie > > as an individual > > > > > > > > David Singer > > Manager, Software Standards, Apple Inc. > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > David Singer > Manager, Software Standards, Apple Inc. > > --001a1141f3c0aaab1f05097e78c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 5, 2014 at 12:44 PM= , David Singer <singer@apple.com> wrote:

OK, I apologize for the casual writing.=C2=A0 =E2=80=9CIf you claim = to conform <this> definition in this RFC, then you MUST=E2=80=A6=E2= =80=9D is effectively a conditional instruction.=C2=A0 Yes, of course you g= et to choose whether to implement at all (but you wouldn=E2=80=99t be here = if you hadn=E2=80=99t chosen to implement), and also which definition you i= mplement to (but see below).

=E2=80=8BMa= y I take your presence in this discussion as an indication that you have ch= osen to implement?=E2=80=8B=C2=A0

While I certainly would welcome s= uch good news, there may well be folks here who are deciding whether and wh= at to implement based on these decisions. What I heard in the room was a lo= t of folks who were willing to make this compromise to move forward, becaus= e it helped enable WebRTC as a whole (this was the main thrust of JDR's= comments, for example).=C2=A0 Speaking personally, I hope that means that = the breadth of implementors will increase in the light of the options that = will be available.


> And note, "is expected" here has exactly no regulatory force= ; it is "is expected" by other interoperable implementations.=E2= =80=8B

It might not have regulatory force, but it might have consequences: = notably any IPR grants that are conditioned on =E2=80=9Cconforming implemen= tations=E2=80=9D, as I pointed out before.

= =E2=80=8BYou have pointed out that such IPR grants can exist.=C2=A0 I did n= ot see you point out=E2=80=8B any that applied to this case.=C2=A0 If I mis= sed that pointer, I would appreciate your sharing it again.
=C2=A0=
If you deliberately= don=E2=80=99t do a =E2=80=9Cmust=E2=80=9D (rather than, for example, havin= g a bug), your claim of conformance may be suspect and your license therefo= re questionable.

> based on no visible analysis, and (unfortunately, since the German cas= e closed without a clear answer) no formal judgment, to defy the claim and = risk suit.
>
> =E2=80=8BThe IETF, as a body, does not undertake those analyses.=C2=A0= Working group members may undertake them when deciding whether to implemen= t the standard.=E2=80=8B
>
> That is clearly formally inappropriate.=C2=A0 The most we should do is= to use a term from RFC 6919 (I=E2=80=99d suggest sections 1 or 6).
>
>
> =E2=80=8BApril 1 RFCs are an amusing lot, aren't they?=C2=A0 =E2= =80=8B

Well, but that=E2=80=99s where we seem to be.=C2=A0 They are amusing= precisely because they cut =E2=80=98close to the bone=E2=80=99.

> =E2=80=8BThe proposed compromise contains multiple methods for handlin= g the risk you believe present:=C2=A0 choose not to implement the standard;= choose a different level compliance (endpoint);

This is where we stray into RFC 6919 territory.=C2=A0 You=E2=80=99re= suggesting that an acceptable outcome is that some (many?) implementations= of WebRTC in products that are called Browsers

=E2=80=8BNo, I didn't say that.=C2=A0 I noted that someone who is = building based on WebRTC has options here.=C2=A0 The endpoint option may be= workable for many (especially in the Mobile App space).

While I am terribly fond of my browser colleagues, the real uptake he= re has to be among those who write applications on the WebRTC platform--and= making that robust enough and varied enough for their needs is important.= =C2=A0

Note as well that I, personally, have never advocated for ha= ving a single codec available to an app or a browser; the methods for negot= iating are a key part of this infrastructure, and they will be key to it mo= ving forward as things progress.=C2=A0 We worked toward a mandatory-to-impl= ement to avoid interoperability failure.=C2=A0 This compromise gets a prett= y good way toward avoiding it=E2=80=8B and past what had been an impasse.= =C2=A0 Am I thrilled?=C2=A0 No.=C2=A0 But it works well enough to be going = along with.

=C2=A0.

I didn=E2=80=99t reply to this before: the point of the Cisco offer = is not that it is binary, but that it carries a license.=C2=A0 The difficul= ty with VP8 is not, per se, in compiling the code, it=E2=80=99s the formal = refusal to license.

OpenH264 notes that= Cisco "will not pass on ... MPEG-LA licensing costs" and, as far= as I can see, pretty much stops there=E2=80=8B.=C2=A0 Google is also not p= assing on its costs in VP8, if there are any.=C2=A0 IF you believe that the= re are other, unbundled rights you need in either, then you should behave a= ccordingly.=C2=A0 But the two are exactly parallel: they require the partic= ipant to asses the available rights and risks.=C2=A0 Others' assessment= s of those risks apparently differ from yours.

=C2=A0
> The sense of the room (as I heard it as participant from the floor) wa= s that there were lots of people who could work with this compromise, those= methods, and their perception of the risk.
>
> You are absolutely free to perform what risk analysis you like and to = take whatever risk avoidance=E2=80=8B steps you deem appropriate.=C2=A0 Tha= t might, sadly, mean you remain on the sidelines as WebRTC moves forward.= =C2=A0 Whatever your choices there, please represent the IETF process corre= ctly as you do so.

I will try to be as precise as I can.=C2=A0 My apologies for the cas= ual writing.


=E2=80=8BThank you, and I will try to d= o the same.

regards,

Ted Hardie
as an individual=E2=80=8B


=C2=A0
best wishes

>
> regards,
>
> Ted Hardie
> as an individual
>
>
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

David Singer
Manager, Software Standards, Apple Inc.


--001a1141f3c0aaab1f05097e78c3-- From nobody Fri Dec 5 13:26:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C11E1A1ABC for ; Fri, 5 Dec 2014 13:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tb8G-m1ktxl for ; Fri, 5 Dec 2014 13:26:04 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C126A1A1B64 for ; Fri, 5 Dec 2014 13:26:03 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so2697512wiv.5 for ; Fri, 05 Dec 2014 13:26:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fzbpy1PaqL7v4H8oiiBEwOnsHD4ufeHbWNtE/mRK4Qo=; b=PbdNXFGY67qObYY3GbupDu3XMATn2pjteJkH/Oubz5sd2IeyBvWpbDshi7UXgy0Ox5 Gbmai8zmpu8DGj1u84cNgIjgnp9PwRaTeF8IiwZ76/hfarxzY5dQj248mu/LGfAKV7NP 4ASlrXfbUM9fxx6VmXed8LYS1mrsGzLAWLKkwSB5LBxOQ5zok4v2ie8/wGQTL2BUpdje LhcMdo+v2UUMEiboDtKZqU5n/eePTP6tXk86IUsBeh6gaxX1tZnDnp/w0mSvYgwjoz2y AcE7R5Ch+Fmh4dc4KHCSTfOwmSW5b7+wcCNl3CnzuphpA2jrgasZpbaD3FvkrgYYoxWK u5/w== X-Received: by 10.194.161.202 with SMTP id xu10mr27684575wjb.4.1417814762551; Fri, 05 Dec 2014 13:26:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.211.131 with HTTP; Fri, 5 Dec 2014 13:25:42 -0800 (PST) In-Reply-To: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> From: Bernard Aboba Date: Fri, 5 Dec 2014 13:25:42 -0800 Message-ID: To: Ted Hardie Content-Type: multipart/alternative; boundary=089e013d1f9c47862b05097eb977 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uecUfiBOWRBp9a5XOvmyzsnolyc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 21:26:07 -0000 --089e013d1f9c47862b05097eb977 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ted Hardie said: "What I heard in the room was a lot of folks who were willing to make this compromise to move forward, because it helped enable WebRTC as a whole (this was the main thrust of JDR's comments, for example). " [BA] What I heard was quite different. A lot of folks were in favor of having *others* undertake a dual MTI obligation so they could benefit. I did not hear a lot of folks claim that *they themselves* were willing to undertake the obligation for their own benefit or the benefit of WebRTC. Big difference. On Fri, Dec 5, 2014 at 1:07 PM, Ted Hardie wrote: > On Fri, Dec 5, 2014 at 12:44 PM, David Singer wrote: > >> >> OK, I apologize for the casual writing. =E2=80=9CIf you claim to confor= m >> definition in this RFC, then you MUST=E2=80=A6=E2=80=9D is effectively a= conditional >> instruction. Yes, of course you get to choose whether to implement at a= ll >> (but you wouldn=E2=80=99t be here if you hadn=E2=80=99t chosen to implem= ent), and also >> which definition you implement to (but see below). >> > > =E2=80=8BMay I take your presence in this discussion as an indication tha= t you > have chosen to implement?=E2=80=8B > > While I certainly would welcome such good news, there may well be folks > here who are deciding whether and what to implement based on these > decisions. What I heard in the room was a lot of folks who were willing t= o > make this compromise to move forward, because it helped enable WebRTC as = a > whole (this was the main thrust of JDR's comments, for example). Speakin= g > personally, I hope that means that the breadth of implementors will > increase in the light of the options that will be available. > > >> > And note, "is expected" here has exactly no regulatory force; it is "i= s >> expected" by other interoperable implementations.=E2=80=8B >> >> It might not have regulatory force, but it might have consequences: >> notably any IPR grants that are conditioned on =E2=80=9Cconforming >> implementations=E2=80=9D, as I pointed out before. > > > =E2=80=8BYou have pointed out that such IPR grants can exist. I did not = see you > point out=E2=80=8B any that applied to this case. If I missed that point= er, I > would appreciate your sharing it again. > > >> If you deliberately don=E2=80=99t do a =E2=80=9Cmust=E2=80=9D (rather th= an, for example, having a >> bug), your claim of conformance may be suspect and your license therefor= e >> questionable. >> >> > based on no visible analysis, and (unfortunately, since the German cas= e >> closed without a clear answer) no formal judgment, to defy the claim and >> risk suit. >> > >> > =E2=80=8BThe IETF, as a body, does not undertake those analyses. Work= ing group >> members may undertake them when deciding whether to implement the standa= rd.=E2=80=8B >> > >> > That is clearly formally inappropriate. The most we should do is to >> use a term from RFC 6919 (I=E2=80=99d suggest sections 1 or 6). >> > >> > >> > =E2=80=8BApril 1 RFCs are an amusing lot, aren't they? =E2=80=8B >> >> Well, but that=E2=80=99s where we seem to be. They are amusing precisel= y because >> they cut =E2=80=98close to the bone=E2=80=99. >> >> > =E2=80=8BThe proposed compromise contains multiple methods for handlin= g the >> risk you believe present: choose not to implement the standard; choose = a >> different level compliance (endpoint); >> >> This is where we stray into RFC 6919 territory. You=E2=80=99re suggesti= ng that >> an acceptable outcome is that some (many?) implementations of WebRTC in >> products that are called Browsers > > > =E2=80=8BNo, I didn't say that. I noted that someone who is building bas= ed on > WebRTC has options here. The endpoint option may be workable for many > (especially in the Mobile App space). > > While I am terribly fond of my browser colleagues, the real uptake here > has to be among those who write applications on the WebRTC platform--and > making that robust enough and varied enough for their needs is important. > > Note as well that I, personally, have never advocated for having a single > codec available to an app or a browser; the methods for negotiating are a > key part of this infrastructure, and they will be key to it moving forwar= d > as things progress. We worked toward a mandatory-to-implement to avoid > interoperability failure. This compromise gets a pretty good way toward > avoiding it=E2=80=8B and past what had been an impasse. Am I thrilled? = No. But > it works well enough to be going along with. > > . > >> >> I didn=E2=80=99t reply to this before: the point of the Cisco offer is n= ot that >> it is binary, but that it carries a license. The difficulty with VP8 is >> not, per se, in compiling the code, it=E2=80=99s the formal refusal to l= icense. >> >> OpenH264 notes that Cisco "will not pass on ... MPEG-LA licensing costs" > and, as far as I can see, pretty much stops there=E2=80=8B. Google is al= so not > passing on its costs in VP8, if there are any. IF you believe that there > are other, unbundled rights you need in either, then you should behave > accordingly. But the two are exactly parallel: they require the > participant to asses the available rights and risks. Others' assessments > of those risks apparently differ from yours. > > > >> > The sense of the room (as I heard it as participant from the floor) wa= s >> that there were lots of people who could work with this compromise, thos= e >> methods, and their perception of the risk. >> > >> > You are absolutely free to perform what risk analysis you like and to >> take whatever risk avoidance=E2=80=8B steps you deem appropriate. That = might, >> sadly, mean you remain on the sidelines as WebRTC moves forward. Whatev= er >> your choices there, please represent the IETF process correctly as you d= o >> so. >> >> I will try to be as precise as I can. My apologies for the casual >> writing. >> >> > =E2=80=8BThank you, and I will try to do the same. > > regards, > > Ted Hardie > as an individual=E2=80=8B > > > > >> best wishes >> >> > >> > regards, >> > >> > Ted Hardie >> > as an individual >> > >> > >> > >> > David Singer >> > Manager, Software Standards, Apple Inc. >> > >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> > >> >> David Singer >> Manager, Software Standards, Apple Inc. >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e013d1f9c47862b05097eb977 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ted Hardie said:

"What= I heard in the room was a lot of folks who were willing to make this compr= omise to move forward, because it helped enable WebRTC as a whole (this was= the main thrust of JDR's comments, for example).=C2=A0"

[BA] What I heard was quite different.=C2=A0 A lot of folks= were in favor of having *others* undertake a dual MTI obligation so they c= ould benefit.=C2=A0 I did not hear a lot of folks claim that *they themselv= es* were willing to undertake the obligation for their own benefit or the b= enefit of WebRTC.=C2=A0 Big difference.

On Fri, Dec 5, 2014 at 1:07 PM, Ted Hard= ie <ted.ietf@gmail.com> wrote:
On Fri, Dec 5, 2014= at 12:44 PM, David Singer <singer@apple.com> wrote:

OK, I apologize for the casual writing.=C2=A0 =E2=80=9CIf you claim = to conform <this> definition in this RFC, then you MUST=E2=80=A6=E2= =80=9D is effectively a conditional instruction.=C2=A0 Yes, of course you g= et to choose whether to implement at all (but you wouldn=E2=80=99t be here = if you hadn=E2=80=99t chosen to implement), and also which definition you i= mplement to (but see below).

=E2= =80=8BMay I take your presence in this discussion as an indication that you= have chosen to implement?=E2=80=8B=C2=A0

While I certainly would w= elcome such good news, there may well be folks here who are deciding whethe= r and what to implement based on these decisions. What I heard in the room = was a lot of folks who were willing to make this compromise to move forward= , because it helped enable WebRTC as a whole (this was the main thrust of J= DR's comments, for example).=C2=A0 Speaking personally, I hope that mea= ns that the breadth of implementors will increase in the light of the optio= ns that will be available.


> And note, "is expected" here has exactly no regulatory force= ; it is "is expected" by other interoperable implementations.=E2= =80=8B

It might not have regulatory force, but it might have consequences: = notably any IPR grants that are conditioned on =E2=80=9Cconforming implemen= tations=E2=80=9D, as I pointed out before.

=E2=80=8BYou have pointed out that such IPR grants can exist.=C2=A0 = I did not see you point out=E2=80=8B any that applied to this case.=C2=A0 I= f I missed that pointer, I would appreciate your sharing it again.
=C2=A0
If you deliberately don=E2=80=99t do a = =E2=80=9Cmust=E2=80=9D (rather than, for example, having a bug), your claim= of conformance may be suspect and your license therefore questionable.

> based on no visible analysis, and (unfortunately, since the German cas= e closed without a clear answer) no formal judgment, to defy the claim and = risk suit.
>
> =E2=80=8BThe IETF, as a body, does not undertake those analyses.=C2=A0= Working group members may undertake them when deciding whether to implemen= t the standard.=E2=80=8B
>
> That is clearly formally inappropriate.=C2=A0 The most we should do is= to use a term from RFC 6919 (I=E2=80=99d suggest sections 1 or 6).
>
>
> =E2=80=8BApril 1 RFCs are an amusing lot, aren't they?=C2=A0 =E2= =80=8B

Well, but that=E2=80=99s where we seem to be.=C2=A0 They are amusing= precisely because they cut =E2=80=98close to the bone=E2=80=99.

> =E2=80=8BThe proposed compromise contains multiple methods for handlin= g the risk you believe present:=C2=A0 choose not to implement the standard;= choose a different level compliance (endpoint);

This is where we stray into RFC 6919 territory.=C2=A0 You=E2=80=99re= suggesting that an acceptable outcome is that some (many?) implementations= of WebRTC in products that are called Browsers
=E2=80=8BNo, I didn't say that.=C2=A0 I noted that someone = who is building based on WebRTC has options here.=C2=A0 The endpoint option= may be workable for many (especially in the Mobile App space).

While I am terribly fond of my browser colleagues, the real up= take here has to be among those who write applications on the WebRTC platfo= rm--and making that robust enough and varied enough for their needs is impo= rtant.=C2=A0

Note as well that I, personally, have never advocated = for having a single codec available to an app or a browser; the methods for= negotiating are a key part of this infrastructure, and they will be key to= it moving forward as things progress.=C2=A0 We worked toward a mandatory-t= o-implement to avoid interoperability failure.=C2=A0 This compromise gets a= pretty good way toward avoiding it=E2=80=8B and past what had been an impa= sse.=C2=A0 Am I thrilled?=C2=A0 No.=C2=A0 But it works well enough to be go= ing along with.

=C2=A0.

I didn=E2=80=99t reply to this before: the point of the Cisco offer = is not that it is binary, but that it carries a license.=C2=A0 The difficul= ty with VP8 is not, per se, in compiling the code, it=E2=80=99s the formal = refusal to license.

OpenH264 notes that Cis= co "will not pass on ... MPEG-LA licensing costs" and, as far as = I can see, pretty much stops there=E2=80=8B.=C2=A0 Google is also not passi= ng on its costs in VP8, if there are any.=C2=A0 IF you believe that there a= re other, unbundled rights you need in either, then you should behave accor= dingly.=C2=A0 But the two are exactly parallel: they require the participan= t to asses the available rights and risks.=C2=A0 Others' assessments of= those risks apparently differ from yours.

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-= left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-le= ft-style:solid"> > The sense of the room (as I heard it as participant from the floor) wa= s that there were lots of people who could work with this compromise, those= methods, and their perception of the risk.
>
> You are absolutely free to perform what risk analysis you like and to = take whatever risk avoidance=E2=80=8B steps you deem appropriate.=C2=A0 Tha= t might, sadly, mean you remain on the sidelines as WebRTC moves forward.= =C2=A0 Whatever your choices there, please represent the IETF process corre= ctly as you do so.

I will try to be as precise as I can.=C2=A0 My apologies for the cas= ual writing.


=E2=80=8BThank you, and I will t= ry to do the same.

regards,

Ted Hardie<= br>
as an individual=E2=80=8B


=C2=A0
best wishes

>
> regards,
>
> Ted Hardie
> as an individual
>
>
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

David Singer
Manager, Software Standards, Apple Inc.



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--089e013d1f9c47862b05097eb977-- From nobody Fri Dec 5 13:30:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828E51A1B7B for ; Fri, 5 Dec 2014 13:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p95dYymcP33O for ; Fri, 5 Dec 2014 13:30:18 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2731A1B04 for ; Fri, 5 Dec 2014 13:30:18 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so2692296wid.11 for ; Fri, 05 Dec 2014 13:30:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fznTHJr8v17QB9sFXlEpCcUTlHGwxeWWWw+Pfs7/wUQ=; b=GetBW74L4ePXOz7gALfReOHbMmcjyYcpisd7Wtdh751B9EESiTf3jJrff5XHdt8uC8 omTRDgmopDoipQB3kmLnPZ0Tg479xZrnlqoZoK9hFXbak7VIF1cErd9Nv96c3usan+ls +w1uYjte5w+T/S/w8znJMhrkvioomYelyt+8ApW+dyOPw5xVMup3aHulAMzbQaT9+q1t yKk/CExQjA4GlhdbFT1YgBII5nSNepnlLPkAih2SB/6mlD1RRMy3XI7efotC2QQii+iO bZhSqbFIzQGddT3kCSV/B4IByUfzqMepU/Wzz7tvu1AUNgf7qL9YRpCeQ/h/yj08B0I6 xX2A== X-Gm-Message-State: ALoCoQnS/ZX21hmU+zvLCW2PFgSlREl2LuYk3/e/SCdzNhjJW6nb5nXbkul+YjzXSdYZeMmKt9Uz MIME-Version: 1.0 X-Received: by 10.180.76.211 with SMTP id m19mr7122841wiw.73.1417815016757; Fri, 05 Dec 2014 13:30:16 -0800 (PST) Received: by 10.194.6.39 with HTTP; Fri, 5 Dec 2014 13:30:16 -0800 (PST) Received: by 10.194.6.39 with HTTP; Fri, 5 Dec 2014 13:30:16 -0800 (PST) In-Reply-To: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> Date: Fri, 5 Dec 2014 23:30:16 +0200 Message-ID: From: Mohammed Raad To: Ted Hardie Content-Type: multipart/alternative; boundary=f46d043c7ab26e734e05097ec815 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Zj9yQOGZAj4_kVakTdxrzvjHyUA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 21:30:21 -0000 --f46d043c7ab26e734e05097ec815 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David, What's missing from this thread is input from Nokia. I found it interesting that the same list of patents submitted to the IETF was omitted from the "unwilling to license" declaration made to ISO and IEC. My understanding of the compromise made by the people at the meeting is that they either do not believe that the declaration made is credible or that it is in some other way irrelevant. It's interesting that you seem to be trying to "save" the people who made this decision and their employers from it. Mohammed On 5 Dec 2014 23:08, "Ted Hardie" wrote: > On Fri, Dec 5, 2014 at 12:44 PM, David Singer wrote: > >> >> OK, I apologize for the casual writing. =E2=80=9CIf you claim to confor= m >> definition in this RFC, then you MUST=E2=80=A6=E2=80=9D is effectively a= conditional >> instruction. Yes, of course you get to choose whether to implement at a= ll >> (but you wouldn=E2=80=99t be here if you hadn=E2=80=99t chosen to implem= ent), and also >> which definition you implement to (but see below). >> > > =E2=80=8BMay I take your presence in this discussion as an indication tha= t you > have chosen to implement?=E2=80=8B > > While I certainly would welcome such good news, there may well be folks > here who are deciding whether and what to implement based on these > decisions. What I heard in the room was a lot of folks who were willing t= o > make this compromise to move forward, because it helped enable WebRTC as = a > whole (this was the main thrust of JDR's comments, for example). Speakin= g > personally, I hope that means that the breadth of implementors will > increase in the light of the options that will be available. > > >> > And note, "is expected" here has exactly no regulatory force; it is "i= s >> expected" by other interoperable implementations.=E2=80=8B >> >> It might not have regulatory force, but it might have consequences: >> notably any IPR grants that are conditioned on =E2=80=9Cconforming >> implementations=E2=80=9D, as I pointed out before. > > > =E2=80=8BYou have pointed out that such IPR grants can exist. I did not = see you > point out=E2=80=8B any that applied to this case. If I missed that point= er, I > would appreciate your sharing it again. > > >> If you deliberately don=E2=80=99t do a =E2=80=9Cmust=E2=80=9D (rather th= an, for example, having a >> bug), your claim of conformance may be suspect and your license therefor= e >> questionable. >> >> > based on no visible analysis, and (unfortunately, since the German cas= e >> closed without a clear answer) no formal judgment, to defy the claim and >> risk suit. >> > >> > =E2=80=8BThe IETF, as a body, does not undertake those analyses. Work= ing group >> members may undertake them when deciding whether to implement the standa= rd.=E2=80=8B >> > >> > That is clearly formally inappropriate. The most we should do is to >> use a term from RFC 6919 (I=E2=80=99d suggest sections 1 or 6). >> > >> > >> > =E2=80=8BApril 1 RFCs are an amusing lot, aren't they? =E2=80=8B >> >> Well, but that=E2=80=99s where we seem to be. They are amusing precisel= y because >> they cut =E2=80=98close to the bone=E2=80=99. >> >> > =E2=80=8BThe proposed compromise contains multiple methods for handlin= g the >> risk you believe present: choose not to implement the standard; choose = a >> different level compliance (endpoint); >> >> This is where we stray into RFC 6919 territory. You=E2=80=99re suggesti= ng that >> an acceptable outcome is that some (many?) implementations of WebRTC in >> products that are called Browsers > > > =E2=80=8BNo, I didn't say that. I noted that someone who is building bas= ed on > WebRTC has options here. The endpoint option may be workable for many > (especially in the Mobile App space). > > While I am terribly fond of my browser colleagues, the real uptake here > has to be among those who write applications on the WebRTC platform--and > making that robust enough and varied enough for their needs is important. > > Note as well that I, personally, have never advocated for having a single > codec available to an app or a browser; the methods for negotiating are a > key part of this infrastructure, and they will be key to it moving forwar= d > as things progress. We worked toward a mandatory-to-implement to avoid > interoperability failure. This compromise gets a pretty good way toward > avoiding it=E2=80=8B and past what had been an impasse. Am I thrilled? = No. But > it works well enough to be going along with. > > . > >> >> I didn=E2=80=99t reply to this before: the point of the Cisco offer is n= ot that >> it is binary, but that it carries a license. The difficulty with VP8 is >> not, per se, in compiling the code, it=E2=80=99s the formal refusal to l= icense. >> >> OpenH264 notes that Cisco "will not pass on ... MPEG-LA licensing costs" > and, as far as I can see, pretty much stops there=E2=80=8B. Google is al= so not > passing on its costs in VP8, if there are any. IF you believe that there > are other, unbundled rights you need in either, then you should behave > accordingly. But the two are exactly parallel: they require the > participant to asses the available rights and risks. Others' assessments > of those risks apparently differ from yours. > > > >> > The sense of the room (as I heard it as participant from the floor) wa= s >> that there were lots of people who could work with this compromise, thos= e >> methods, and their perception of the risk. >> > >> > You are absolutely free to perform what risk analysis you like and to >> take whatever risk avoidance=E2=80=8B steps you deem appropriate. That = might, >> sadly, mean you remain on the sidelines as WebRTC moves forward. Whatev= er >> your choices there, please represent the IETF process correctly as you d= o >> so. >> >> I will try to be as precise as I can. My apologies for the casual >> writing. >> >> > =E2=80=8BThank you, and I will try to do the same. > > regards, > > Ted Hardie > as an individual=E2=80=8B > > > > >> best wishes >> >> > >> > regards, >> > >> > Ted Hardie >> > as an individual >> > >> > >> > >> > David Singer >> > Manager, Software Standards, Apple Inc. >> > >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> > >> >> David Singer >> Manager, Software Standards, Apple Inc. >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d043c7ab26e734e05097ec815 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

David,

What's missing from this thread is input from Nokia. I f= ound it interesting that the same list of patents submitted to the IETF was= omitted from the "unwilling to license" declaration made to ISO = and IEC. My understanding of the compromise made by the people at the meeti= ng is that they either do not believe that the declaration made is credible= or that it is in some other way irrelevant. It's interesting that you = seem to be trying to "save" the people who made this decision and= their employers from it.

Mohammed

On 5 Dec 2014 23:08, "Ted Hardie" <= ted.ietf@gmail.com> wrote:
On Fri, Dec 5, 2014 at 12:44 PM, David Singer <singer@= apple.com> wrote:

OK, I apologize for the casual writing.=C2=A0 =E2=80=9CIf you claim = to conform <this> definition in this RFC, then you MUST=E2=80=A6=E2= =80=9D is effectively a conditional instruction.=C2=A0 Yes, of course you g= et to choose whether to implement at all (but you wouldn=E2=80=99t be here = if you hadn=E2=80=99t chosen to implement), and also which definition you i= mplement to (but see below).

=E2=80=8BMa= y I take your presence in this discussion as an indication that you have ch= osen to implement?=E2=80=8B=C2=A0

While I certainly would welcome s= uch good news, there may well be folks here who are deciding whether and wh= at to implement based on these decisions. What I heard in the room was a lo= t of folks who were willing to make this compromise to move forward, becaus= e it helped enable WebRTC as a whole (this was the main thrust of JDR's= comments, for example).=C2=A0 Speaking personally, I hope that means that = the breadth of implementors will increase in the light of the options that = will be available.


> And note, "is expected" here has exactly no regulatory force= ; it is "is expected" by other interoperable implementations.=E2= =80=8B

It might not have regulatory force, but it might have consequences: = notably any IPR grants that are conditioned on =E2=80=9Cconforming implemen= tations=E2=80=9D, as I pointed out before.

= =E2=80=8BYou have pointed out that such IPR grants can exist.=C2=A0 I did n= ot see you point out=E2=80=8B any that applied to this case.=C2=A0 If I mis= sed that pointer, I would appreciate your sharing it again.
=C2=A0=
If you deliberately= don=E2=80=99t do a =E2=80=9Cmust=E2=80=9D (rather than, for example, havin= g a bug), your claim of conformance may be suspect and your license therefo= re questionable.

> based on no visible analysis, and (unfortunately, since the German cas= e closed without a clear answer) no formal judgment, to defy the claim and = risk suit.
>
> =E2=80=8BThe IETF, as a body, does not undertake those analyses.=C2=A0= Working group members may undertake them when deciding whether to implemen= t the standard.=E2=80=8B
>
> That is clearly formally inappropriate.=C2=A0 The most we should do is= to use a term from RFC 6919 (I=E2=80=99d suggest sections 1 or 6).
>
>
> =E2=80=8BApril 1 RFCs are an amusing lot, aren't they?=C2=A0 =E2= =80=8B

Well, but that=E2=80=99s where we seem to be.=C2=A0 They are amusing= precisely because they cut =E2=80=98close to the bone=E2=80=99.

> =E2=80=8BThe proposed compromise contains multiple methods for handlin= g the risk you believe present:=C2=A0 choose not to implement the standard;= choose a different level compliance (endpoint);

This is where we stray into RFC 6919 territory.=C2=A0 You=E2=80=99re= suggesting that an acceptable outcome is that some (many?) implementations= of WebRTC in products that are called Browsers

=E2=80=8BNo, I didn't say that.=C2=A0 I noted that someone who is = building based on WebRTC has options here.=C2=A0 The endpoint option may be= workable for many (especially in the Mobile App space).

While I am terribly fond of my browser colleagues, the real uptake he= re has to be among those who write applications on the WebRTC platform--and= making that robust enough and varied enough for their needs is important.= =C2=A0

Note as well that I, personally, have never advocated for ha= ving a single codec available to an app or a browser; the methods for negot= iating are a key part of this infrastructure, and they will be key to it mo= ving forward as things progress.=C2=A0 We worked toward a mandatory-to-impl= ement to avoid interoperability failure.=C2=A0 This compromise gets a prett= y good way toward avoiding it=E2=80=8B and past what had been an impasse.= =C2=A0 Am I thrilled?=C2=A0 No.=C2=A0 But it works well enough to be going = along with.

=C2=A0.

I didn=E2=80=99t reply to this before: the point of the Cisco offer = is not that it is binary, but that it carries a license.=C2=A0 The difficul= ty with VP8 is not, per se, in compiling the code, it=E2=80=99s the formal = refusal to license.

OpenH264 notes that Cisco &quo= t;will not pass on ... MPEG-LA licensing costs" and, as far as I can s= ee, pretty much stops there=E2=80=8B.=C2=A0 Google is also not passing on i= ts costs in VP8, if there are any.=C2=A0 IF you believe that there are othe= r, unbundled rights you need in either, then you should behave accordingly.= =C2=A0 But the two are exactly parallel: they require the participant to as= ses the available rights and risks.=C2=A0 Others' assessments of those = risks apparently differ from yours.

=C2=A0
> The sense of the room (as I heard it as participant from the floor) wa= s that there were lots of people who could work with this compromise, those= methods, and their perception of the risk.
>
> You are absolutely free to perform what risk analysis you like and to = take whatever risk avoidance=E2=80=8B steps you deem appropriate.=C2=A0 Tha= t might, sadly, mean you remain on the sidelines as WebRTC moves forward.= =C2=A0 Whatever your choices there, please represent the IETF process corre= ctly as you do so.

I will try to be as precise as I can.=C2=A0 My apologies for the cas= ual writing.


=E2=80=8BThank you, and I will try to d= o the same.

regards,

Ted Hardie
as an individual=E2=80=8B


=C2=A0
best wishes

>
> regards,
>
> Ted Hardie
> as an individual
>
>
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

David Singer
Manager, Software Standards, Apple Inc.



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--f46d043c7ab26e734e05097ec815-- From nobody Fri Dec 5 13:42:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B611A6EE4 for ; Fri, 5 Dec 2014 13:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6mrsVHQVaTJ for ; Fri, 5 Dec 2014 13:42:52 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AAAA1A1B37 for ; Fri, 5 Dec 2014 13:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417815771; x=2281729371; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=s/SYrAfZpvKk7Hm7KPCX+xAA4WEvp0w0oVgmWMhxjuU=; b=EbzPpBYzXo/dys6315S9u1VNqkvMaqSnwW1shepRww7s7Pcj00JfERPIY02ni1TL JMlPjJYGcuBkSFiceVfZ53qEPqkoDIi/97rjb/Z42mhnQBPzluBAjpQKR1i0zxBa K4Lfm/QQpcpAwNReNt5Q4EjLAm7lGRn4wO6oOfbk0w2wWfsmC7XI2aYU/06vptep 1QKXcTt/UDE4/CYlqMkI/nEPfDF7Vl9I23JF2+byjB/nky7lkvHrOCFDVDkiH/ya faJgIuNbsTY1w4rwHHtqZw9jDw//BXkoWI8j10pCplaOlB/YOIhL+Xj3AMVIlVh4 9ELkxFe72todoNrG6msuiw==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id BA.1A.12074.BD622845; Fri, 5 Dec 2014 13:42:51 -0800 (PST) X-AuditID: 11973e12-f79f86d000002f2a-78-548226db9a66 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 7F.D5.05775.7C622845; Fri, 5 Dec 2014 13:42:31 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG400226PNFVE40@marigold.apple.com> for rtcweb@ietf.org; Fri, 05 Dec 2014 13:42:51 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: Date: Fri, 05 Dec 2014 13:42:50 -0800 Content-transfer-encoding: quoted-printable Message-id: <2CCC7F59-6EB2-4F11-A63E-40C89350E8F2@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> To: Ted Hardie X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FAYpXtbrSnEoO+drsXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuPHiJFPBEuWKeVv+sDcwLpPpYuTkkBAwkei+tJ4JwhaTuHBv PVsXIxeHkMBeRomjPzazwBRt3rabCSIxiUli6vRnzBDOfCaJxj9bGbsYOTiYBdQlpkzJBWng FdCTaHryGGyqsECExJHOM+wgNpuAqsSDOccYQWxOgWCJZUfngC1gAYrvu3KfGcRmFrCVePl2 CzuErS3x5N0FVoiZNhJfpq6F2rudReJo21uwBSICyhJ7r+xgg7hUVuLfRYhlEgJvWSUe/nKc wCg8C+G8WUjOm4VkxQJG5lWMQrmJmTm6mXkmeokFBTmpesn5uZsYQWE83U5oB+OpVVaHGAU4 GJV4eFdINIYIsSaWFVfmHmKU5mBREud9xwsUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwBg3 T/aYyPGLb72r4tnYDE5mTb5b3+Lg1vUh+GbY7PetXzre5SZVlq5IFDv8dWLv48yL3btKUne/ 4g33aTF9yFP9g3Ov4jZnhwU58fs3ak+cpbR7XWrgl61eQZ9aS45OalzzJPnW1e8e3MY3jtgl O91omfqB13aax9HGdykHpN49fX2S87fHBV8lluKMREMt5qLiRADeot1hRAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcontcrSnEYM51Fou1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcePFSaaCJcoV87b8YW9gXCbTxcjJISFgIrF5224mCFtM4sK9 9WxdjFwcQgKTmCSmTn/GDOHMZ5Jo/LOVsYuRg4NZQF1iypRckAZeAT2JpiePwZqFBSIkjnSe YQex2QRUJR7MOcYIYnMKBEssOzqHBcRmAYrvu3KfGcRmFrCVePl2CzuErS3x5N0FVoiZNhJf pq6F2rudReJo21uwBSICyhJ7r+xgg7hUVuLfxTPsExgFZiGcNAvJSbOQjF3AyLyKUaAoNSex 0kwvsaAgJ1UvOT93EyM48AqjdjA2LLc6xCjAwajEw7tCojFEiDWxrLgy9xCjBAezkghv8myg EG9KYmVValF+fFFpTmrxIUZpDhYlcd64d0ApgfTEktTs1NSC1CKYLBMHp1QDo5PS37Y9PF25 L0yPFEzzzRZ4mvsiylYlvHvF6aScA3teBgnkxe/YsY739OUmqzOlH5lrpn2oqFiSGlloGHVY 2jFN8K+7q+3H2b8yc1fwrQvMzJVh4ua8EMV0ScutuNveqHpX6PRg9vNy6zNSXj18VH1ygtZ5 NfE9nJOY1/SdkjPWT9feNTVCiaU4I9FQi7moOBEAcoijhDgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2qCeibCvd61GW2sSeCDArRo8u14 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 21:42:54 -0000 > On Dec 5, 2014, at 13:07 , Ted Hardie wrote: >=20 > On Fri, Dec 5, 2014 at 12:44 PM, David Singer = wrote: >=20 > OK, I apologize for the casual writing. =E2=80=9CIf you claim to = conform definition in this RFC, then you MUST=E2=80=A6=E2=80=9D = is effectively a conditional instruction. Yes, of course you get to = choose whether to implement at all (but you wouldn=E2=80=99t be here if = you hadn=E2=80=99t chosen to implement), and also which definition you = implement to (but see below). >=20 > =E2=80=8BMay I take your presence in this discussion as an indication = that you have chosen to implement?=E2=80=8B =20 Alas, no. My job is to manage the standards landscape, and not = products. It=E2=80=99s another assumed conditional (!) =E2=80=9CIf my = company (or indeed anyone) were to want to implement, could we/they, = would we/they?" > =E2=80=8BYou have pointed out that such IPR grants can exist. I did = not see you point out=E2=80=8B any that applied to this case. If I = missed that pointer, I would appreciate your sharing it again. If I find one, I will. At this point, I merely point out that they are = not unusual. > > =E2=80=8BThe proposed compromise contains multiple methods for = handling the risk you believe present: choose not to implement the = standard; choose a different level compliance (endpoint); >=20 > This is where we stray into RFC 6919 territory. You=E2=80=99re = suggesting that an acceptable outcome is that some (many?) = implementations of WebRTC in products that are called Browsers >=20 > =E2=80=8BNo, I didn't say that. I noted that someone who is building = based on WebRTC has options here. The endpoint option may be workable = for many (especially in the Mobile App space).=20 well, OK, but it does seem that if we went ahead with this text, you are = saying that a browser would have a 4th option, over the three I already = pointed out: 1) Implement VP8 and defy the =E2=80=9Cunwilling to license=E2=80=9D 2) Don=E2=80=99t implement it, defy the =E2=80=9Cmust=E2=80=9D in the = spec. 3) Don=E2=80=99t claim to do WebRTC at all and now=20 4) Though being a browser and doing WebRTC, claim only to be a WebRTC = Endpoint, not a WebRTC Browser. I simply don=E2=80=99t see how this helps anything. It=E2=80=99s = confusing and doesn=E2=80=99t advance interoperability at all. We may = as well delete the WebRTC Browser clause, and call everything an = endpoint, if it=E2=80=99s a myth that browsers that implement WebRTC = will be conformant to the WebRTC Browser requirements. Or, as I said, = put a 6919 clause 1 reference next to the MUST in the webrtc browser = case. :-) > While I am terribly fond of my browser colleagues, the real uptake = here has to be among those who write applications on the WebRTC = platform--and making that robust enough and varied enough for their = needs is important. =20 I thought the principle platform was envisaged to be the WebRTC browser = =E2=80=94 something that allows embedding of webrtc in arbitrary web = pages? Yes, we expect to interop with more focused endpoints. The = applications don=E2=80=99t supply the codecs, do they (assuming by = =E2=80=98application=E2=80=99 you mean the collection of HTML, JS, CSS = and the like)? > I didn=E2=80=99t reply to this before: the point of the Cisco offer is = not that it is binary, but that it carries a license. The difficulty = with VP8 is not, per se, in compiling the code, it=E2=80=99s the formal = refusal to license. >=20 > OpenH264 notes that Cisco "will not pass on ... MPEG-LA licensing = costs" and, as far as I can see, pretty much stops there=E2=80=8B. = Google is also not passing on its costs in VP8, if there are any. IF = you believe that there are other, unbundled rights you need in either, = then you should behave accordingly. But the two are exactly parallel: = they require the participant to asses the available rights and risks. = Others' assessments of those risks apparently differ from yours. It really is not similar. Maybe there are licenses that one or other = does not carry: in the Cisco case, we are unaware of any =E2=80=9Cunwilli= ng to license=E2=80=9D, whereas for VP8 there is a clear statement that = no license can be had. Agreed, whether you actually need a license or = not is a separate question. David Singer Manager, Software Standards, Apple Inc. From nobody Fri Dec 5 14:28:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5CD1A6F84 for ; Fri, 5 Dec 2014 14:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLaZVv9ia9w4 for ; Fri, 5 Dec 2014 14:28:53 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 144341A1B54 for ; Fri, 5 Dec 2014 14:28:52 -0800 (PST) Received: from Orochi.local ([12.216.224.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB5MSoig049862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2014 16:28:50 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [12.216.224.110] claimed to be Orochi.local Message-ID: <5482319E.1060501@nostrum.com> Date: Fri, 05 Dec 2014 14:28:46 -0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Bernard Aboba , Ted Hardie References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8-MnKWOQnc6PigAtnrIp-go9g68 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 22:28:54 -0000 On 12/5/14 13:25, Bernard Aboba wrote: > [BA] What I heard was quite different. A lot of folks were in favor > of having *others* undertake a dual MTI obligation so they could > benefit. I did not hear a lot of folks claim that *they themselves* > were willing to undertake the obligation for their own benefit or the > benefit of WebRTC. Big difference. Hi there. /a From nobody Fri Dec 5 14:32:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D051A1F02 for ; Fri, 5 Dec 2014 14:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnUpik4CDQ9t for ; Fri, 5 Dec 2014 14:32:29 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B9FC1A1EF6 for ; Fri, 5 Dec 2014 14:32:29 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id h15so71891igd.2 for ; Fri, 05 Dec 2014 14:32:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TURlcERDzVXxouDwe1xBmYNRk5Wq8cSzgkKJ6b+5Fto=; b=K+1gdVeCmzv+xHxv0MThBvdocSyW3cYkbzbLdLTRXN2SyOU5eQ++mbUL5g4ku+/Ldi 7aEBHExGD1ewU14SdoU3zb2ryVgZwj+3PHLIUvC9FYzmB6T6R0ClADcY6mBl13W388kR jMaux+xhrDJo9iNuTjFfl7sTF9RfCGTxRfuGAE3Wb9SoJ5qZUz3JNrUGrj1mpmCYhEqt iqUhERw3s16WDPdN4zUGONl0makiSFo02JBALje+z3QMfbA1OY8FbUfPuMVQs+qNRoJr 1Pdg4viF0RrA/74e+HtTX4mmVUeaapOWf+1ZgioJwKtd6l//owwccmDCy+DkSZYZsOSf +6cA== MIME-Version: 1.0 X-Received: by 10.42.68.203 with SMTP id y11mr17451436ici.62.1417818748603; Fri, 05 Dec 2014 14:32:28 -0800 (PST) Received: by 10.43.3.4 with HTTP; Fri, 5 Dec 2014 14:32:28 -0800 (PST) In-Reply-To: <2CCC7F59-6EB2-4F11-A63E-40C89350E8F2@apple.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> <2CCC7F59-6EB2-4F11-A63E-40C89350E8F2@apple.com> Date: Fri, 5 Dec 2014 14:32:28 -0800 Message-ID: From: Ted Hardie To: David Singer Content-Type: multipart/alternative; boundary=20cf30334b5fddd31205097fa65a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AnZ-OFKHxAsSg0zhS-KbOLwP9UY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 22:32:32 -0000 --20cf30334b5fddd31205097fa65a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi David, On Fri, Dec 5, 2014 at 1:42 PM, David Singer wrote: > > =E2=80=8B > =E2=80=8B(Much snipped)=E2=80=8B > > > > While I am terribly fond of my browser colleagues, the real uptake here > has to be among those who write applications on the WebRTC platform--and > making that robust enough and varied enough for their needs is important. > > I thought the principle platform was envisaged to be the WebRTC browser = =E2=80=94 > something that allows embedding of webrtc in arbitrary web pages? =E2=80=8BThat's certainly a model, and on platforms which provide robust ac= cess to the necessary substrates, it may well be popular. But it's not the only model--a mobile app can be distributed with a set of encoders and decoders if the platform does not provide them (or, indeed, it could make up any other deficits of the substrate in a particular OS). =E2=80=8BBecause the Mah-jong =E2=80=8Bapplication which substitutes player= 's faces for the tile backs isn't expecting to handle arbitrary JS, or interoperate with other applications other than browsers, the endpoint approach is valuable for it. > Yes, we expect to interop with more focused endpoints. The applications > don=E2=80=99t supply the codecs, do they (assuming by =E2=80=98applicatio= n=E2=80=99 you mean the > collection of HTML, JS, CSS and the like)? > > That's the "application" inside the browser or conforming mobile web platform; it's not the only application type that might be doing WebRTC.=E2= =80=8B > > I didn=E2=80=99t reply to this before: the point of the Cisco offer is = not that > it is binary, but that it carries a license. The difficulty with VP8 is > not, per se, in compiling the code, it=E2=80=99s the formal refusal to li= cense. > > > > OpenH264 notes that Cisco "will not pass on ... MPEG-LA licensing costs= " > and, as far as I can see, pretty much stops there=E2=80=8B. Google is al= so not > passing on its costs in VP8, if there are any. IF you believe that there > are other, unbundled rights you need in either, then you should behave > accordingly. But the two are exactly parallel: they require the > participant to asses the available rights and risks. Others' assessments > of those risks apparently differ from yours. > > It really is not similar. Maybe there are licenses that one or other doe= s > not carry: in the Cisco case, we are unaware of any =E2=80=9Cunwilling t= o > license=E2=80=9D, whereas for VP8 there is a clear statement that no lice= nse can be > had. =E2=80=8BIn both cases, the participant needs to assess whether they know o= f all the salient IPR, whether they have all the licenses for that IPR which they need. While I am not a lawyer, I imagine that in both cases that would involve making a determination of the relevance of the claim as well as an analysis of its license terms. It also involves an assessment of the risk that there are other claims which may later arise. To my lay person's eyes, the two assessments do look pretty similar. It appears, honestly, that you disagree with the results' of others assessments, rather than that the assessments do not need to take place in both cases. But I may be misunderstanding your point. regards, Ted Hardie as an individual > Agreed, whether you actually need a license or not is a separate question= . > > > David Singer > Manager, Software Standards, Apple Inc. > > --20cf30334b5fddd31205097fa65a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi David,
On Fri, Dec 5, 2014 at 1:42 PM, David Singer <= span dir=3D"ltr"><= singer@apple.com> wrote:

=E2=80=8B
=E2= =80=8B(Much snipped)=E2=80=8B


> While I am terribly fond of my browser colleagues, the real uptake her= e has to be among those who write applications on the WebRTC platform--and = making that robust enough and varied enough for their needs is important.
I thought the principle platform was envisaged to be the WebRTC brow= ser =E2=80=94 something that allows embedding of webrtc in arbitrary web pa= ges?

=E2=80=8BThat's certainly a model, = and on platforms which provide robust access to the necessary substrates, i= t may well be popular.=C2=A0 But it's not the only model--a mobile app = can be distributed with a=C2=A0 set of encoders and decoders if the platfor= m does not provide them (or, indeed, it could make up any other deficits of= the substrate in a particular OS).
=E2=80=8BBecause the= Mah-jong =E2=80=8Bapplication which substitutes player's faces for the= tile backs isn't expecting to handle arbitrary JS, or interoperate wit= h other applications other than browsers, the endpoint approach is valuable= for it.
=C2=A0
=C2=A0 Yes, we= expect to interop with more focused endpoints. The applications don=E2=80= =99t supply the codecs, do they (assuming by =E2=80=98application=E2=80=99 = you mean the collection of HTML, JS, CSS and the like)?

That's the &quo= t;application" inside the browser or conforming mobile web platform; i= t's not the only application type that might be doing WebRTC.=E2=80=8B<= /div>=C2=A0
> I didn=E2=80=99t reply to this before: the point of the Cisco offer is= not that it is binary, but that it carries a license.=C2=A0 The difficulty= with VP8 is not, per se, in compiling the code, it=E2=80=99s the formal re= fusal to license.
>
> OpenH264 notes that Cisco "will not pass on ... MPEG-LA licensing= costs" and, as far as I can see, pretty much stops there=E2=80=8B.=C2= =A0 Google is also not passing on its costs in VP8, if there are any.=C2=A0= IF you believe that there are other, unbundled rights you need in either, = then you should behave accordingly.=C2=A0 But the two are exactly parallel:= they require the participant to asses the available rights and risks.=C2= =A0 Others' assessments of those risks apparently differ from yours.
It really is not similar.=C2=A0 Maybe there are licenses that one or= other does not carry:=C2=A0 in the Cisco case, we are unaware of any =E2= =80=9Cunwilling to license=E2=80=9D, whereas for VP8 there is a clear state= ment that no license can be had.=C2=A0

=E2= =80=8BIn both cases, the participant needs to assess whether they know of a= ll the salient IPR, whether they have all the licenses for that IPR which t= hey need.=C2=A0=C2=A0 While I am not a lawyer, I imagine that in both cases= that would involve making a determination of the relevance of the claim as= well as an analysis of its license terms.=C2=A0 It also involves an assess= ment of the risk that there are other claims which may later arise.

= To my lay person's eyes, the two assessments do look pretty similar.=C2= =A0 It appears, honestly, that you disagree with the results' of others= assessments, rather than that the assessments do not need to take place in= both cases.=C2=A0 But I may be misunderstanding your point.

<= div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-siz= e:small">regards,

Ted Hardie
as an individual
=


=C2=A0
Agreed, whether y= ou actually need a license or not is a separate question.


David Singer
Manager, Software Standards, Apple Inc.


--20cf30334b5fddd31205097fa65a-- From nobody Fri Dec 5 15:13:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEEB1A212D for ; Fri, 5 Dec 2014 15:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGHvrtqjKwIx for ; Fri, 5 Dec 2014 15:13:50 -0800 (PST) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F8A1A6FE3 for ; Fri, 5 Dec 2014 15:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417821229; x=2281734829; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xINHHmbCgWGi4EWfXY2RLdxy3ViTkRE975lSJ7w2R6A=; b=EBSaHDo37yGS3CjDdFcU+/24ZvZJBFfWl87nNhpTq+oYADeBd/LfQIwCnqVWCOWC QcTmcZOOH4E4I7g0HrOxsCLVHXjmb8XdDc2Y43tYnxKBxMgt2yoAs43JDtyPDYdQ zOosrkrx+opgwlec8+AKgP55lxGlxVZsitzMgpnVv7d6YOvaTWL+uqb7Mg2l+FET UShvLOtpOYpTc9MzAKdYMbw3cUfFBrIHPDebbLt0XJZvn12kcEw1F5xHTWkgoig8 K70ZXQZJDCxYDZg00WFyWq87Hjm/KPAUcHMZwuXF9j1ZXXdJKqghH+iDHXZ/Hjz5 sewXfWzWfimPk3xxjTrHew==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 34.FE.26546.D2C32845; Fri, 5 Dec 2014 15:13:49 -0800 (PST) X-AuditID: 11973e11-f79af6d0000067b2-cb-54823c2db3a9 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 41.95.06123.F2C32845; Fri, 5 Dec 2014 15:13:51 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG4002ZNTV1VE70@marigold.apple.com> for rtcweb@ietf.org; Fri, 05 Dec 2014 15:13:49 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: Date: Fri, 05 Dec 2014 15:13:48 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> <2CCC7F59-6EB2-4F11-A63E-40C89350E8F2@apple.com> To: Ted Hardie X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUi2FAYoatr0xRi8LhX3WLtv3Z2B0aPJUt+ MgUwRnHZpKTmZJalFunbJXBltF19wVTwW6TiRvd39gbG6wJdjJwcEgImEqdvnmaFsMUkLtxb zwZiCwnsZZSYcCsRpqZxxzSgOBdQfBKTxMIf75khiuYzSRx959bFyMHBLKAuMWVKLkiYV0BP ounJYyYQW1ggQuJI5xl2EJtNQFXiwZxjjCA2p0CwxIRl98BqWIDir+7+ALOZBWwlXr7dwg5h a0s8eXeBFWKmjcTjhw2MEDdsZJVYcGINWEJEQFli75UdbBCHykr8uwiyjAvIfssqMfXuE+YJ jMKzEO6bheS+WUh2LGBkXsUolJuYmaObmWekl1hQkJOql5yfu4kRFMTT7QR3MB5fZXWIUYCD UYmHd4VEY4gQa2JZcWXuIUZpDhYlcd53vEAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjMUl nTP0FmpafmrcyfnZPONkpM8q5ZtBeWJXNhhfEI/Lnrjt48S+E182zZWTK2QuDrCfwPcsNkd1 EstUyU3VjbFn2uWKS1dW7npifCG6QmjVB862K8IJqmGv1Yqv7LCJazx15e20O6EvS17NPDxZ 8dGfDZGre2+e63grpnfsW52riEzC7CpVMyWW4oxEQy3mouJEAE2TlTlDAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FDcoqtv0xRi8P+qjMXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKaLv6gqngt0jFje7v7A2M1wW6GDk5JARMJBp3TGODsMUkLtxb D2RzcQgJTGKSWPjjPTNIQkhgPpPE0XduXYwcHMwC6hJTpuSChHkF9CSanjxmArGFBSIkjnSe YQex2QRUJR7MOcYIYnMKBEtMWHYPrIYFKP7q7g8wm1nAVuLl2y3sELa2xJN3F1ghZtpIPH7Y wAhxw0ZWiQUn1oAlRASUJfZe2QF1qKzEv4tn2CcwCsxCOGkWkpNmIRm7gJF5FaNAUWpOYqWp XmJBQU6qXnJ+7iZGcNgVRuxg/L/M6hCjAAejEg/vConGECHWxLLiytxDjBIczEoivMmzgUK8 KYmVValF+fFFpTmpxYcYpTlYlMR5S94BpQTSE0tSs1NTC1KLYLJMHJxSDYxr/Z+81Ldhe/VC WMlw+Z15V85Ua3yc86m458+f3N6v38K+qX13vbwwMCDKYV8qm1N5gN/T6ypa+WqxV6ZMfqTP b6/LEHeevcOmY1HLysjJMzu4Nm9Pzz1/2329nLKQePa/w3ff93keCvT7PSe08+j+DaxHZ/s+ /tdmmDWj8dS25LBpr3suhnxRYinOSDTUYi4qTgQA4WLsVTcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EueLa36FskHChaAP891vLRlCoJ8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 23:13:51 -0000 Hi Ted > On Dec 5, 2014, at 14:32 , Ted Hardie wrote: >=20 > Hi David, >=20 > On Fri, Dec 5, 2014 at 1:42 PM, David Singer wrote: >=20 > =E2=80=8B > =E2=80=8B(Much snipped)=E2=80=8B >=20 >> It really is not similar. Maybe there are licenses that one or other = does not carry: in the Cisco case, we are unaware of any =E2=80=9Cunwilli= ng to license=E2=80=9D, whereas for VP8 there is a clear statement that = no license can be had.=20 >>=20 > =E2=80=8BIn both cases, the participant needs to assess whether they = know of all the salient IPR, whether they have all the licenses for that = IPR which they need. While I am not a lawyer, I imagine that in both = cases that would involve making a determination of the relevance of the = claim as well as an analysis of its license terms. It also involves an = assessment of the risk that there are other claims which may later = arise. >=20 > To my lay person's eyes, the two assessments do look pretty similar. = It appears, honestly, that you disagree with the results' of others = assessments, rather than that the assessments do not need to take place = in both cases. But I may be misunderstanding your point. OK, let me see if I can persuade you of a qualitative difference. For = each =E2=80=98must=E2=80=99, what is the nature and availability of = licenses that I might need from those claiming IPR? * H.264: all those claiming IPR offer licenses, though most of them ask = for payment * VP8: almost all offer licenses that are either free or effectively so = (pre-paid, in the case of the MPEG-LA), but there is one for which no = license is available (and it=E2=80=99s not an insignificant company, or = one not active in the field, or a small set of patents) For me, that is a major difference. Clearly for others (e.g. Ron who = has said as much), the cost is more significant than the license = availability. I think inserting the =E2=80=98must=E2=80=99 here means that companies = will either ignore it, or claim not to be a WebRTC Browser, neither of = which advance the cause of interoperability at all. If, in fact, we = expect there to be a significant number of WebRTC Endpoints, and that we = expect that they will be sometimes at both ends of a call, then this = tentative agreement already has given up on ensuring interop, and I = suggest we simply move to the webRTC Endpoint requirements and delete = the webRTC Browser one. (We could enhance it in various ways: add a = =E2=80=98recommend both at least for decode=E2=80=99, for example.) David Singer Manager, Software Standards, Apple Inc. From nobody Fri Dec 5 15:26:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39CA1A6FEB for ; Fri, 5 Dec 2014 15:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ljlqa0igBv6A for ; Fri, 5 Dec 2014 15:26:29 -0800 (PST) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0331A1EEA for ; Fri, 5 Dec 2014 15:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417821989; x=2281735589; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5vKY0GhZOgKgbc1SFc8PwWW2+ol17JbqCYC+46j30ZA=; b=mz25aYjJgVg9hAyPqz5oWVotEaJZtmobro9UqR5GG8fDELF/DRrzDU+aDiFNoXgW ckZ5iBc7DykaEuj7wXcXbrfkGkmh+QqC9BbKY+eIkSpBRkmCK569YJT3UQRJa0qF lqYGQwipzmnkL1lNvkhYQb3Dc7XTTapn/aKZlNn1TRdrf1t232qOwgPrsQ1RsDvJ 3KGIY8CHPdhzX2R+Xk0oh3LiE+xB6Z9i5JkgYQCzp8SasiuY8vZSjwGNQ2qQgBVK njdReOIxaX007ccRaAVLS1bJSHcW3PLO1W0Q4gFjAdmqQzdvqww94d9mNQfxRtjv 4mLrM6A+P64mzVflULDv2g==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 75.61.26546.42F32845; Fri, 5 Dec 2014 15:26:28 -0800 (PST) X-AuditID: 11973e11-f79af6d0000067b2-8f-54823f24c19f Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id D5.11.05439.A2F32845; Fri, 5 Dec 2014 15:26:34 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG400LRMUG42R20@marigold.apple.com> for rtcweb@ietf.org; Fri, 05 Dec 2014 15:26:28 -0800 (PST) Content-type: text/plain; charset=windows-1252 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <54820E74.90201@mozilla.com> Date: Fri, 05 Dec 2014 15:26:28 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <54820E74.90201@mozilla.com> To: Jean-Marc Valin X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUi2FAYrKti3xRisO6zjcXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK6O++zF5wgalixYF1TA2MnUxdjJwcEgImEp++32eDsMUkLtxb D2RzcQgJ7GWU+D6piQ2mqH/eXBaIxCQmicdznzBDOPOZJJZ8PwdUxcHBLKAncf+iFkgDL5DZ 9OQxE0hYWMBWYuv1IJAwm4CqxIM5xxhBbE4BTYn3+2azg5SwAMXfvU8ECTMLGEucOHyABcLW lnjy7gIrxEQbiUd7NrKClAsJREn8/OAJEhYBmnLnxyp2iCtlJf5dPMMOcpiEwEtWiXWLfrFO YBSehXDbLCS3zUKyYQEj8ypGodzEzBzdzDwjvcSCgpxUveT83E2MoACebie4g/H4KqtDjAIc jEo8vCskGkOEWBPLiitzDzFKc7AoifOa2DSFCAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAM O62/siNMNvi5znybtcIVh7pTK3XMAhZdr6n8LOLc+vwz9+X4o/dXXDRdcadlfvnn0/6WEz0n KUgfS0rfGNzpVLv14tu1PqJlVcpNC87O2hRjonvlkkuO26PZO5pUPn45bGRY8PRF2Jo/qtPN vzz6YZT7If/e0q733ffs/lk7nrbtmhCvl5aoxFKckWioxVxUnAgAyuqQZUECAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUi2FDcoqtl3xRisHGBicXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK6O++zF5wgalixYF1TA2MnUxdjJwcEgImEv3z5rJA2GISF+6t Z+ti5OIQEpjEJPF47hNmCGc+k8SS7+eAMhwczAJ6EvcvaoE08AKZTU8eM4GEhQVsJbZeDwIJ swmoSjyYc4wRxOYU0JR4v282O0gJC1D83ftEkDCzgLHEicMHWCBsbYkn7y6wQky0kXi0ZyMr SLmQQJTEzw+eIGERoCl3fqxih7hSVuLfxTPsExgFZiGcMwvJObOQDF3AyLyKUaAoNSex0lgv saAgJ1UvOT93EyM44AqDdzD+WWZ1iFGAg1GJh3eFRGOIEGtiWXFl7iFGCQ5mJRHe5NlAId6U xMqq1KL8+KLSnNTiQ4zSHCxK4rwV74BSAumJJanZqakFqUUwWSYOTqkGxmD2bMkfR28/+vvc U80+8/m1fp73AT3eJdq8x917Zgcdk73Ec3yNWStjwbr7eg9VEjrWSHj/cFs/qf2vU6ZsnqZL +FOupvSOpvca58NUeOpcK4+x5H6atOih9sylHLt1JrYbNitafzrCP3t9VPzfs5I22nqqnUFG 7s1iHJeZXVgETy54pz5LiaU4I9FQi7moOBEAJO8XWjQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Pudks0SAuncMeqXk7uDS9KB-4ks Cc: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 23:26:30 -0000 > On Dec 5, 2014, at 11:58 , Jean-Marc Valin = wrote: > 3) This is the only proposal that gets support from both camps if you could speak only for yourself, and not others, that might be = better. You=92re claiming support by other people here. David Singer Manager, Software Standards, Apple Inc. From nobody Fri Dec 5 15:33:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706111A6FF1 for ; Fri, 5 Dec 2014 15:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.18 X-Spam-Level: X-Spam-Status: No, score=0.18 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mValClMsimva for ; Fri, 5 Dec 2014 15:33:28 -0800 (PST) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3352F1A6FEB for ; Fri, 5 Dec 2014 15:33:27 -0800 (PST) Received: from userPC (unknown [122.166.157.84]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 6F36C1908852; Fri, 5 Dec 2014 23:33:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1417822402; bh=jutCslM7AkU8igG6t53c2p3MD1Nc6GLQUetcbB6XvZ8=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=gGKcFjzz9jowGqL4IrcCGxD7u2qeu/Zl+rLHV85bcQyfbocRjaXOhqouk6C+biXmJ swTu1RhYzIyM6Rt8DtlIok3jnIrZfjn7SdK+4he4CSuAGjJVtNKEE1ki/pMDuI33ly GYwZmtzSGgIEi6E9zNa8nWVik8PSYNYPQLdr/0QQ= From: "Parthasarathi R" To: "'Mohammed Raad'" , References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> <07A7CF59-FA04-4B0D-93AC-4106BDE35655@meetecho.com> In-Reply-To: Date: Sat, 6 Dec 2014 05:03:09 +0530 Message-ID: <010201d010e3$d7196250$854c26f0$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0103_01D01111.F0D19E50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAQyWv9CV6qlQ6SSBuoduYedvOhgwAGk9CA Content-Language: en-us X-CTCH-RefID: str=0001.0A020202.548240C3.00AC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.92 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xY8aDiwSr8LtvuwqlPwQepRiwSI Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 23:33:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0103_01D01111.F0D19E50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable +1 =20 From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Mohammed Raad Sent: Saturday, December 06, 2014 1:54 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] Call for adoption of = draft-alvestrand-rtcweb-gateways =20 I'm in support of adopting this as a WG document also. Mohammed On 5 Dec 2014 22:18, "Matt Fredrickson" wrote: Yes, let's adopt it. Matthew Fredrickson On Fri, Dec 5, 2014 at 11:43 AM, Lorenzo Miniero = wrote: > A) Yes, > > L. > > Il 04 dicembre 2014 20:29:52 CET, "Cullen Jennings (fluffy)" > ha scritto: >> >> Having reviewed the fine technical comments on this draft since we = asked >> for comments, the chairs have noted that multiple people seem to have = read >> the draft. Given this great news we are going make a call for = adoption. >> >> If you have an opinion, please email the list by Dec 19 and let us = know if >> you either: >> >> A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG >> document now >> >> B) no, not right now >> >> If we get consensus around A we will work with ADs on milestone. = Otherwise >> we will encourage the authors to keep working on this draft and = continue >> using this email list. We may adopt it later or include the text in = other >> drafts. >> >> Thanks, >> The Chairs (Cullen, Sean, Ted) >> >> PS - if you want to send an email that says more than A or B, feel = free to >> change the subject, start a new thread etc. >> >> >> >> >> >> >> >> >> ________________________________ >> >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > -- > Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la = brevit=C3=A0. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Matthew Fredrickson Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb ------=_NextPart_000_0103_01D01111.F0D19E50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

+1

 

From:= rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Mohammed Raad
Sent: Saturday, December 06, 2014 1:54 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways

 

I'm in support of adopting this as a WG document also.

Mohammed

On 5 Dec 2014 22:18, "Matt Fredrickson" = <creslin@digium.com> = wrote:

Yes, let's adopt it.

Matthew Fredrickson

On Fri, Dec 5, 2014 at 11:43 AM, Lorenzo Miniero <lorenzo@meetecho.com> = wrote:
> A) Yes,
>
> L.
>
> Il 04 dicembre 2014 20:29:52 CET, "Cullen Jennings = (fluffy)"
> <fluffy@cisco.com> ha = scritto:
>>
>> Having reviewed the fine technical comments on this draft since = we asked
>> for comments, the chairs have noted that multiple people seem = to have read
>> the draft. Given this great news we are going make a call for adoption.
>>
>> If you have an opinion, please email the list by Dec 19 and let = us know if
>> you either:
>>
>> A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a = WG
>> document now
>>
>> B) no, not right now
>>
>> If we get consensus around A we will work with ADs on = milestone. Otherwise
>> we will encourage the authors to keep working on this draft and continue
>> using this email list. We may adopt it later or include the = text in other
>> drafts.
>>
>> Thanks,
>> The Chairs (Cullen, Sean, Ted)
>>
>> PS - if you want to send an email that says more than A or B, = feel free to
>> change the subject, start a new thread etc.
>>
>>
>>
>>
>>
>>
>>
>>
>> ________________________________
>>
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> --
> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la = brevit=C3=A0.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>



--
Matthew Fredrickson
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

------=_NextPart_000_0103_01D01111.F0D19E50-- From nobody Fri Dec 5 15:57:14 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1732D1A7015 for ; Fri, 5 Dec 2014 15:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YilMoBv9Zrct for ; Fri, 5 Dec 2014 15:57:11 -0800 (PST) Received: from nm12-vm4.bullet.mail.ir2.yahoo.com (nm12-vm4.bullet.mail.ir2.yahoo.com [212.82.96.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0A11A6FEF for ; Fri, 5 Dec 2014 15:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s2048; t=1417823829; bh=i2AYbyPWFrjdCNxhSx0h0kfFVdqumKiUcoImdjB26NM=; h=References:In-Reply-To:Cc:From:Subject:Date:To:From:Subject; b=QbeMuTPvlHR33HDNXWMIjLyZMNFqE8ZejPYJo+djCzlECHq3uyiEo2V5O9ospsS9wEHznWtBTC8hEG0H1+R1cLzsZjbKZCBRvMt/rbtS+qi5sdhcSX3WQifJQsjuFIaatATLoXOXNrKVNjKWRpen66SPid4LaCmgprKQaoRUz/YVrbIUj/toUuJ18n5oM3mtyXoy665nBA3dDhunv6DSgWFT9RdEWovkgenJprRp8J57lI8VNxCc0TJjN+d2ZkPhPjTcYCxE83dn2nynRrKvfZE7sf+RL79jfMiD0jqdEz50e1BXpF7vR1oVQ0vnRxzFhU0kw4yl3aoBW/msSd2vgQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.fr; b=h0zi5JdnuOeZyt5PG/AwXitrh5fQMot+bFg/iM9gn4MOViKwy2YUCtCBMxDTiLTB/ASJe8aOQG692Mi9XKG9ul2Nf1TWs7D+ZD4daI6J4M6PtcuonbICA8U8aXBZ33CgYnSfv3mP5/ZKjQpavHa7ux8GpCnJXS82SZfvPGfgqxIHWo2B7djhxT7NJh4xNNlXji+wcs33hQW9MOmQ5OPwmzPQ6DBMXYGZtCz/CRdgKSTAp+t7avI8rxFSAWRICl4Tbqmii/Gjhc2WR21BHny7zkmuTI20KgqDMnWuapDbqjARiwvxiBBYfBquRXzTzd/sR5qVIaIjfC8hse47UBP8WA==; Received: from [212.82.98.51] by nm12.bullet.mail.ir2.yahoo.com with NNFMP; 05 Dec 2014 23:57:09 -0000 Received: from [46.228.39.111] by tm4.bullet.mail.ir2.yahoo.com with NNFMP; 05 Dec 2014 23:57:09 -0000 Received: from [127.0.0.1] by smtp148.mail.ir2.yahoo.com with NNFMP; 05 Dec 2014 23:57:09 -0000 X-Yahoo-Newman-Id: 33577.87845.bm@smtp148.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: yhpGBiQVM1kuvwG0AJjsVk1RJjD4WQQYM7.N.v.V7WeQ0dN SVAd1TQ7uc2OulaQP7kAqgPwQnch3zTjFK52o1Ol0xvjdtiFS3BCIT._iG1s mG3rE6KDVp2ye6Z6FRRn9IZVuVe3JlxfrkulWrqHs7ECtvEMh7XkSgitJVCB o22Q82edGp2CStamFxmMgTm108b0LN3rKaxRSRfo1jFzpv23.dpzZsbPSXZw r8yR1ie86qij._Jl5PxzGCosbRWf2YDVk8J0FOBJ0bMlAlokn.B9PJiSWf81 ZwZIO4XydNTyVm9jnrTMLKBXgmNAJ8oCMP2ZfiVQTUhKWMYXWkpNzz69jwkJ Dlpcx.3f5xZ9ZIYOOK4dOcyXViUX2kNlQDCmTWO4F4cYGu5Lm4hi_2_5aQPz p7HzO2Vb3L_v0nyikR3WxuQJcsjV9ylLbI2N.Md4EP6B6wcrocPz3DOahV.W sMzOIXJKjBymEZwiQO5jGGcblUPjR_K4xwxLfFkNHOJHYuu6fujGBG2NVoIL h.fQ6.Hs01vGpha00dPY7Do9n X-Yahoo-SMTP: Dix.ZgGswBADJg.if3NVG_xX0Xc- References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> <07A7CF59-FA04-4B0D-93AC-4106BDE35655@meetecho.com> <010201d010e3$d7196250$854c26f0$@co.in> Mime-Version: 1.0 (1.0) In-Reply-To: <010201d010e3$d7196250$854c26f0$@co.in> Content-Type: multipart/alternative; boundary=Apple-Mail-7059D15C-BCB9-43FE-A65E-29219E4ADF38 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (12B411) From: Bossiel Date: Sat, 6 Dec 2014 00:57:08 +0100 To: Parthasarathi R Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xclWeM_tjI0dwOfWVe6WFPaFFEo Cc: "" Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2014 23:57:13 -0000 --Apple-Mail-7059D15C-BCB9-43FE-A65E-29219E4ADF38 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 Sent from my iPhone > On Dec 6, 2014, at 00:33, Parthasarathi R wro= te: >=20 > +1 > =20 > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Mohammed Raad > Sent: Saturday, December 06, 2014 1:54 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateway= s > =20 > I'm in support of adopting this as a WG document also. >=20 > Mohammed >=20 > On 5 Dec 2014 22:18, "Matt Fredrickson" wrote: > Yes, let's adopt it. >=20 > Matthew Fredrickson >=20 > On Fri, Dec 5, 2014 at 11:43 AM, Lorenzo Miniero wr= ote: > > A) Yes, > > > > L. > > > > Il 04 dicembre 2014 20:29:52 CET, "Cullen Jennings (fluffy)" > > ha scritto: > >> > >> Having reviewed the fine technical comments on this draft since we aske= d > >> for comments, the chairs have noted that multiple people seem to have r= ead > >> the draft. Given this great news we are going make a call for adoption.= > >> > >> If you have an opinion, please email the list by Dec 19 and let us know= if > >> you either: > >> > >> A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG > >> document now > >> > >> B) no, not right now > >> > >> If we get consensus around A we will work with ADs on milestone. Otherw= ise > >> we will encourage the authors to keep working on this draft and continu= e > >> using this email list. We may adopt it later or include the text in oth= er > >> drafts. > >> > >> Thanks, > >> The Chairs (Cullen, Sean, Ted) > >> > >> PS - if you want to send an email that says more than A or B, feel free= to > >> change the subject, start a new thread etc. > >> > >> > >> > >> > >> > >> > >> > >> > >> ________________________________ > >> > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > -- > > Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevit=C3= =A0. > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > >=20 >=20 >=20 > -- > Matthew Fredrickson > Digium, Inc. | Senior Software Developer > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >=20 > _______________________________________________ > 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 --Apple-Mail-7059D15C-BCB9-43FE-A65E-29219E4ADF38 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1

Sent from my iPhone

On Dec 6, 2014, at 00:33, Parthasarathi R <partha@parthasarathi.co.in> wrote:

+1

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Mohammed Raad
Sent: Saturday, December 06, 2014 1:54 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways

 

I'm in support of adopting this as a WG document also.

Mohammed

On 5 Dec 2014 22:18, "Matt Fredrickson" <creslin@digium.com> wrote:

=

Yes, let's adopt it.

Matthew Fredrickson

On Fri, Dec 5, 2014 at 11:43 AM, Lorenzo Miniero <lorenzo@meetecho.com> wrote:
> A) Yes,
>
> L.
>
> Il 04 dicembre 2014 20:29:52 CET, "Cullen Jennings (fluffy)"
> <fluffy@cisco.com> ha scr= itto:
>>
>> Having reviewed the fine technical comments on this draft since we asked
>> for comments, the chairs have noted that multiple people seem to ha= ve read
>> the draft. Given this great news we are going make a call for adoption.
>>
>> If you have an opinion, please email the list by Dec 19 and let us know if
>> you either:
>>
>> A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG<= br> >> document now
>>
>> B) no, not right now
>>
>> If we get consensus around A we will work with ADs on milestone. Otherwise
>> we will encourage the authors to keep working on this draft and continue
>> using this email list. We may adopt it later or include the text in= other
>> drafts.
>>
>> Thanks,
>> The Chairs (Cullen, Sean, Ted)
>>
>> PS - if you want to send an email that says more than A or B, feel free to
>> change the subject, start a new thread etc.
>>
>>
>>
>>
>>
>>
>>
>>
>> ________________________________
>>
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> --
> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevit=C3= =A0.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>



--
Matthew Fredrickson
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/rtcweb

____________________= ___________________________
rtcweb mailing list
rtcweb@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org= /mailman/listinfo/rtcweb
= --Apple-Mail-7059D15C-BCB9-43FE-A65E-29219E4ADF38-- From nobody Fri Dec 5 16:07:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BD21A86FD for ; Fri, 5 Dec 2014 16:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzUciS6q983f for ; Fri, 5 Dec 2014 16:07:53 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579F31A86F2 for ; Fri, 5 Dec 2014 16:07:53 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id h15so157674igd.8 for ; Fri, 05 Dec 2014 16:07:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vBHxWJZsPMVSUTmynRBKsaZVXc9zTLUazsAkATZfYUs=; b=i6nYMUQs0h4uh4xzZyXNKrAFC6ArSsNtyZtgVb1HtPZZWPaGEZS3cm3HkVpA3XwjdP fbEnu+ZaZ40eX1mYfSWJp1RVyiBcoRexMbOIZN2WIU6w7cV1ft2PpCW9J4XrjNgNTVG7 7hWu0ZAQvUOzMzSym07Ezw+kJ1kzfjgJDThnhzTQMs07zxPm7GxJQNAb51Ubc69DTJnX BT5MPeXQ7/7V9FJaEnCYZSY0Z38wjJZuhhUC7yWsmilPCfiidDvfklWx4SGFc+6RgVl3 rtzeVNw3d7NsFagAkasm0L9dMmd5jESJQNNKV2KLEkImNPiC8m8FvC5A70mYRAtnTyMx 7reg== MIME-Version: 1.0 X-Received: by 10.42.250.17 with SMTP id mm17mr17780557icb.18.1417824472395; Fri, 05 Dec 2014 16:07:52 -0800 (PST) Received: by 10.43.3.4 with HTTP; Fri, 5 Dec 2014 16:07:52 -0800 (PST) In-Reply-To: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> <2CCC7F59-6EB2-4F11-A63E-40C89350E8F2@apple.com> Date: Fri, 5 Dec 2014 16:07:52 -0800 Message-ID: From: Ted Hardie To: David Singer Content-Type: multipart/alternative; boundary=20cf3036404f07f4b6050980fc6d Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zcMSsmAezEOl1AaLL7DfbrodYjc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 00:07:56 -0000 --20cf3036404f07f4b6050980fc6d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 5, 2014 at 3:13 PM, David Singer wrote: > > OK, let me see if I can persuade you of a qualitative difference. For > each =E2=80=98must=E2=80=99, > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > what is the nature and availability of licenses that I might need from > those claiming IPR? > > =E2=80=8BIs that the right question? I think that "=E2=80=8B=E2=80=8B=E2= =80=8B=E2=80=8B=E2=80=8Bwhat is the nature and availability of licenses that I might need from those whose IPR I believe I must use?" might be closer, but, again, I am not a lawyer. Seeking a license for everything claimed is at best highly conservative; it might even be expensive and unnecessary. This is, in any case, exactly what I pointed out earlier: each participant must make this same assessment for each of the cases. > * H.264: all those claiming IPR offer licenses, though most of them ask > for payment > =E2=80=8BNote that this may be the case for common encoders and decoders, b= ut anyone coming up with their own code (especially on the encoder side) would have =E2=80=8Bto conduct the analysis for themselves. * VP8: almost all offer licenses that are either free or effectively so > (pre-paid, in the case of the MPEG-LA), but there is one for which no > license is available (and it=E2=80=99s not an insignificant company, or o= ne not > active in the field, or a small set of patents) > > =E2=80=8B=E2=80=8BThere has been one assertion of non-licensable patents = to be named later (MPEG) and one set of patents (often asserted in multiple countries) named to the IETF in the following IPR declaration: https://datatracker.ietf.org/ipr/2035/ . As noted above, I am not a lawyer, but I invite folks to have their lawyers wade through that; it may be shallower water than it first appears. For me, that is a major difference. Clearly for others (e.g. Ron who has > said as much), the cost is more significant than the license availability= . > > I think inserting the =E2=80=98must=E2=80=99 here means that companies wi= ll either ignore > it =E2=80=8BI don't have a crystal ball myself, but I note at least two compan= ies that make browsers have said that they will comply if this the standard. There may be others that do not, of course, and if they had been intending to consider it, it is obviously something that they would need to add to the consideration. But your conclusion is not the same as others', at least according to my hearing or my reading of the work at Chrome and Firefox.=E2= =80=8B =E2=80=8Bregards, Ted Hardie as an individual=E2=80=8B --20cf3036404f07f4b6050980fc6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 5, 2014 at 3:13 PM,= David Singer <singer@apple.com> wrote:

OK, let me see if I can persuade you of a qualitative difference.=C2= =A0 For each =E2=80=98must=E2=80=99,
=E2=80=8B=E2= =80=8B
=E2=80=8B=E2=80=8B
what is the na= ture and availability of licenses that I might need from those claiming IPR= ?


=E2=80=8BIs that the right question?=C2= =A0 I think that "=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8Bwhat is= the nature and availability of licenses that I might need from those whose= IPR I believe I must use?" might be closer, but, again, I am not a la= wyer.=C2=A0 Seeking a license for everything claimed is at best highly cons= ervative; it might even be expensive and unnecessary.

This is, in a= ny case, exactly what I pointed out earlier:=C2=A0 each participant must ma= ke this same assessment for each of the cases.=C2=A0
=C2=A0
=
* H.264: all those claiming IPR offer licenses, though most of them ask for= payment
=C2=A0
=E2=80=8BNote that= this may be the case for common encoders and decoders, but anyone coming u= p with their own code (especially on the encoder side) would have =E2=80=8B= to conduct the analysis for themselves.=C2=A0

* VP8: almost all offer licenses that are either free or effectively so (pr= e-paid, in the case of the MPEG-LA), but there is one for which no license = is available (and it=E2=80=99s not an insignificant company, or one not act= ive in the field, or a small set of patents)

=E2=80=8B=E2=80=8BThere has been one assert= ion of non-licensable patents to be named later (MPEG) and one set of paten= ts (often asserted in multiple countries)=C2=A0 named to the IETF in the fo= llowing IPR declaration:=C2=A0 https://datatracker.ietf.org/ipr/2035/ . As not= ed above, I am not a lawyer, but I invite folks to have their lawyers wade = through that; it may be shallower water than it first appears.

=


=
For me, that is a major difference.=C2=A0 Clearly for others (e.g. Ron who = has said as much), the cost is more significant than the license availabili= ty.

I think inserting the =E2=80=98must=E2=80=99 here means that companies will= either ignore it

=E2=80=8BI don't hav= e a crystal ball myself, but I note at least two companies that make browse= rs have said that they will comply if this the standard.=C2=A0 There may be= others that do not, of course, and if they had been intending to consider = it, it is obviously something that they would need to add to the considerat= ion.=C2=A0=C2=A0 But your conclusion is not the same as others', at lea= st according to my hearing or my reading of the work at Chrome and Firefox.= =E2=80=8B
=C2=A0
=E2=80=8Bregards,

Ted Hardie
<= /div>
as an individual=E2=80=8B


--20cf3036404f07f4b6050980fc6d-- From nobody Fri Dec 5 17:05:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FBE1A8773 for ; Fri, 5 Dec 2014 17:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf56hW9uVzp8 for ; Fri, 5 Dec 2014 17:05:10 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3471A876A for ; Fri, 5 Dec 2014 17:05:10 -0800 (PST) Received: from Orochi.local (ip-64-134-138-182.public.wayport.net [64.134.138.182]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB6154eJ062673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2014 19:05:05 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host ip-64-134-138-182.public.wayport.net [64.134.138.182] claimed to be Orochi.local Message-ID: <5482563C.2020404@nostrum.com> Date: Fri, 05 Dec 2014 17:05:00 -0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , Sean Turner , "rtcweb@ietf.org" References: <548205C7.3090805@nostrum.com> <949EF20990823C4C85C18D59AA11AD8B28DBE8@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B28DBE8@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------040508010306020608040505" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Fm73YDRM41UY7rzqcRLSAANv4ds Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 01:05:12 -0000 This is a multi-part message in MIME format. --------------040508010306020608040505 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/5/14 11:59, DRAGE, Keith (Keith) wrote: > In that case you are agreeing with something that did not happen. By no stretch of the imagination can the result of the RTCWEB session be declared as "consensus". I guess I should have picked up from the other thread that it's pedantry hour. I'll play one round on-list. The common English definition I'm familiar with for "consensus" is the one described by Merriam-Webster online 1b: " the judgment arrived at by most of those concerned." I recognize that in the game of pedantry, this is simply moving my pawn out from its starting ranks at the beginning of the tournament. If you'd like to continue the match by, say, quibbling over the meaning of "most" in that context, please call me on +1 650 903 0800, extension 863. I'm sure this is neither topical for this list, nor of interest to its members, and I suspect we can conclude the matter much more quickly in real-time. /a --------------040508010306020608040505 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 12/5/14 11:59, DRAGE, Keith (Keith) wrote:
In that case you are agreeing with something that did not happen. By no stretch of the imagination can the result of the RTCWEB session be declared as "consensus".

I guess I should have picked up from the other thread that it's pedantry hour. I'll play one round on-list.

The common English definition I'm familiar with for "consensus" is the one described by Merriam-Webster online 1b: " the judgment arrived at by most of those concerned."

I recognize that in the game of pedantry, this is simply moving my pawn out from its starting ranks at the beginning of the tournament. If you'd like to continue the match by, say, quibbling over the meaning of "most" in that context, please call me on +1 650 903 0800, extension 863. I'm sure this is neither topical for this list, nor of interest to its members, and I suspect we can conclude the matter much more quickly in real-time.

/a
--------------040508010306020608040505-- From nobody Fri Dec 5 17:50:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7FB1A87DE for ; Fri, 5 Dec 2014 17:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyN7tGVptwGx for ; Fri, 5 Dec 2014 17:50:17 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D62A1A87D4 for ; Fri, 5 Dec 2014 17:50:17 -0800 (PST) Received: from Orochi.local (ip-64-134-138-182.public.wayport.net [64.134.138.182]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB61oEfu066168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2014 19:50:15 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host ip-64-134-138-182.public.wayport.net [64.134.138.182] claimed to be Orochi.local Message-ID: <548260D2.2020703@nostrum.com> Date: Fri, 05 Dec 2014 17:50:10 -0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: David Singer , Jean-Marc Valin References: <54820E74.90201@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4TnLe9PuECaLbTQA1W6VhAUg8vc Cc: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 01:50:18 -0000 On 12/5/14 15:26, David Singer wrote: >> On Dec 5, 2014, at 11:58 , Jean-Marc Valin wrote: >> 3) This is the only proposal that gets support from both camps > if you could speak only for yourself, and not others, that might be better. You’re claiming support by other people here. > If I read Jean-Marc's statement correctly, it's not speaking on behalf of other people; it's using what they have already said, on the record [1], as a valid part of his rationale. I'd like to reinforce this sentiment. I support this proposal not because I think it is the best solution, but because it is the first MTI video codec proposal that the actual implementors in this technology space have even remotely agreed on since the discussion began. I support this proposal primarily because it is the only solution we have yet seen that has a credible chance of succeeding. That's a powerful reason -- at least, for those people invested in this technology -- but it necessarily involves pointing to the positions of others. This is not the same as making statements on their behalf, as you claim; it is merely acknowledging that they've already made such statements. /a ____ [1] I'm not going through the effort of gathering citations here, as I would expect that you, and all other involved participants, are sufficiently familiar with the ongoing conversation to make doing so unnecessary. If you'd like to make the claim such positions have *not* been asserted by the parties in question, I'll happily point you to a trove of relevant emails, meeting minutes, slide decks, and audio recordings. From nobody Fri Dec 5 17:58:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6821A1B9B for ; Fri, 5 Dec 2014 17:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcBFt-6_WF10 for ; Fri, 5 Dec 2014 17:58:06 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C51B1A00B7 for ; Fri, 5 Dec 2014 17:58:06 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id et14so1773545pad.1 for ; Fri, 05 Dec 2014 17:58:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=tvdCpMQWKPPU+pEBgPmFE4slfhvFg3toXZ2lvQC83p8=; b=UDYo9bg/oqpGztIC64xE4EH7hjB9608Ms4DCTaePF4QyC/iKQc3q2+z4rDSAbKchvg Z5sfWJDq9k3ZtoAW9uE/hQBsBPfX3R+m4ZoyDM6sTyxub7x5X4MpGu71JMIqL73VH4B/ 1yTDOXs/xHB+oWaUP8qLekYIxCFt+oD9Li6Z8xdJxK8fI3Hyw+EQCdjd4NVKJaz1+eJB ajjiKlfEWuWTFesH0BpAECNsBPzPZby58s+/6C0qGz8J0pTUR6dtzMNnktkZXFSKmbRY PKU0wqoJ1hyHQAYggBIzg9dg8HkbXCtTTz/CVYMbEpPaocovTB4fcyh/Q0mCLgXl3Iya w2Iw== X-Received: by 10.68.97.131 with SMTP id ea3mr40205694pbb.144.1417831085252; Fri, 05 Dec 2014 17:58:05 -0800 (PST) Received: from [10.203.138.154] (mobile-166-171-251-160.mycingular.net. [166.171.251.160]) by mx.google.com with ESMTPSA id fe5sm19503122pdb.77.2014.12.05.17.58.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Dec 2014 17:58:03 -0800 (PST) References: <54820E74.90201@mozilla.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <496F8147-8A3D-477A-A17C-24110304CAAF@gmail.com> X-Mailer: iPhone Mail (12B435) From: Bernard Aboba Date: Fri, 5 Dec 2014 17:58:00 -0800 To: David Singer Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cgDy89Cbnq-lWzTV6lGWHKoExD4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 01:58:08 -0000 I would also distinguish between "I am willing to support dual MTI in our pr= oduct" and "I have no intention to implement it in our product but am happy t= o impose the burden on someone else." =20 > On Dec 5, 2014, at 3:26 PM, David Singer wrote: >=20 >=20 >> On Dec 5, 2014, at 11:58 , Jean-Marc Valin wrote: >> 3) This is the only proposal that gets support from both camps >=20 > if you could speak only for yourself, and not others, that might be better= . You=E2=80=99re claiming support by other people here. >=20 >=20 > David Singer > Manager, Software Standards, Apple Inc. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Dec 5 17:59:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9CA1A1BD1 for ; Fri, 5 Dec 2014 17:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8Uzf-_JCwoA for ; Fri, 5 Dec 2014 17:58:57 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994E21A00B7 for ; Fri, 5 Dec 2014 17:58:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417831137; x=2281744737; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=40uSRtfB97L/u4ZQ7pAtjI1Hof1/ldqQtocKOLp3rpU=; b=V6kebH/qtwjSKi2iP7L5QUIZ/kmYrvXv8Ka/yH7AEnXnCPDyRd8+6v1SbS8uQ7Xz ZZ2tN/b019Pt+an1mN5CJT5OrbvQYtdQVx4CWmS0I8eg5Z9Jf4vYo67q8MEfaVgF VjmpkABJYyhILZ064miF1m44eg+dZFwuuJg/D9NWknS2GHgXdx/XprW53dejrDlB 4lig8s0eeQt1L0Er17nmtDwRkWIXmtJLucCKSDHg1chXPcps0fGufGL2kFTiu42b EYbbChL1OgqGZnUS0WWKjWEHTUKbEQYXEHWXmvKtxtdvwcBpoWrz19JzRulT/ijr /Oza7p5d3Tl+0ZRPOO4v3g==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 11.FC.06819.1E262845; Fri, 5 Dec 2014 17:58:57 -0800 (PST) X-AuditID: 11973e13-f79656d000001aa3-fd-548262e1295f Received: from chicory.apple.com (chicory.apple.com [17.128.115.99]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 09.34.05998.1F262845; Fri, 5 Dec 2014 17:59:13 -0800 (PST) Received: from [17.153.27.20] (unknown [17.153.27.20]) by chicory.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG5004X71I58030@chicory.apple.com> for rtcweb@ietf.org; Fri, 05 Dec 2014 17:58:56 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <548260D2.2020703@nostrum.com> Date: Fri, 05 Dec 2014 17:58:53 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <54820E74.90201@mozilla.com> <548260D2.2020703@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUi2FAYrvswqSnEYPtMRou1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8eZ0P1PBB66KLfOPsDYwXuPoYuTkkBAwkbi47xQzhC0mceHe ejYQW0hgL6PEnx/pMDU9E78DxbmA4v1MEreu32GFc9qWHwbq5uBgFlCXmDIlF6SBV0BPounJ YyaQsLCArcTW60EgYTYBVYkHc44xgticAtoS8+7dZQexWYDiKw7PYAKxmQWsJP6efsIIYWtL PHl3gRVipI3EqtmroG5Ywyhx5DjEoSICihJth29CPSAr8e/iGXaQIgmBl6wS/w8+Y5rAKDwL 4bxZSM6bhWTHAkbmVYxCuYmZObqZeaZ6iQUFOal6yfm5mxhBQTzdTngH4+lVVocYBTgYlXh4 V0g0hgixJpYVV+YeYpTmYFES5022bwoREkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLhS4ded Z7kPY7+r//KVDcm8XRKVaCnNd/umftiV601OBh3iV9fkxWv/df/EZaz+xe/nD5b+K+95eDc0 Kiy5Hsro/1mX7ddpl+npX0/V7vrOk/z4sA7DhDLJbb1vK2pykx8IiFekrrsj9OCGyPkPvBWF EdLWPV+LqjxNFdr0T3Levu7s/MY8WImlOCPRUIu5qDgRAL8+fdRDAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FCcrPsxqSnE4PJnfYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8eZ0P1PBB66KLfOPsDYwXuPoYuTkkBAwkeiZ+J0NwhaTuHBv PZDNxSEk0M8kcev6HVY4p235YeYuRg4OZgF1iSlTckEaeAX0JJqePGYCCQsL2EpsvR4EEmYT UJV4MOcYI4jNKaAtMe/eXXYQmwUovuLwDCYQm1nASuLv6SeMELa2xJN3F1ghRtpIrJq9CuqG NYwSR46vBztOREBRou3wTWaIQ2Ul/l08wz6BUWAWwkWzkFw0C8nYBYzMqxgFilJzEitN9BIL CnJS9ZLzczcxgsOuMHwH479lVocYBTgYlXh4V0g0hgixJpYVV+YeYpTgYFYS4U2eDRTiTUms rEotyo8vKs1JLT7EKM3BoiTO2/wOKCWQnliSmp2aWpBaBJNl4uCUamAU3hnXm3LtXr7s4/Xz nNnevunjaOoQSW5rkT98/MLsZ9I29fsWJ9Rf6+q7snfhky9WP4+8dGNbunxnH9fV9ELGPkbJ i2+u3atlv7tr0YKv5y7MNNz+0Hy/eKZSU8KRmbmnw10M/opXfGdMX2r76PWnl+YO/qrCJ1Yw vVB5aCg5+cXDO28uFC53UGIpzkg01GIuKk4EAAE/baY3AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zq7ND8fnHlJhMdLerptBjWE2PFo Cc: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 01:58:58 -0000 > On Dec 5, 2014, at 17:50 , Adam Roach wrote: >=20 > On 12/5/14 15:26, David Singer wrote: >>> On Dec 5, 2014, at 11:58 , Jean-Marc Valin = wrote: >>> 3) This is the only proposal that gets support from both camps >> if you could speak only for yourself, and not others, that might be = better. You=E2=80=99re claiming support by other people here. >>=20 >=20 > If I read Jean-Marc's statement correctly, it's not speaking on behalf = of other people; it's using what they have already said, on the record = [1], as a valid part of his rationale. >=20 > I'd like to reinforce this sentiment. I support this proposal not = because I think it is the best solution, but because it is the first MTI = video codec proposal that the actual implementors in this technology = space have even remotely agreed on since the discussion began. I support = this proposal primarily because it is the only solution we have yet seen = that has a credible chance of succeeding. OK, we are potential implementor, and so are Blackberry, and we don=E2=80=99= t agree.=20 You seem to hypothesize two camps only and that this has support of = both. You are therefore trying to claim a state of consensus which does = not exist. There was pushback both in the room and on the list. David Singer Manager, Software Standards, Apple Inc. From nobody Fri Dec 5 18:23:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D30F1A8A11 for ; Fri, 5 Dec 2014 18:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeuiirF_q8Uq for ; Fri, 5 Dec 2014 18:23:09 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBC71A8A4E for ; Fri, 5 Dec 2014 18:23:08 -0800 (PST) Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 05 Dec 2014 21:23:04 -0500 Received: from XCT111CNC.rim.net (10.65.161.211) by XCT101CNC.rim.net (10.65.161.201) with Microsoft SMTP Server (TLS) id 14.3.210.2; Fri, 5 Dec 2014 21:23:03 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT111CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Fri, 5 Dec 2014 21:23:03 -0500 From: Andrew Allen To: Adam Roach , David Singer , Jean-Marc Valin Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEJCKEBti1FXXNkmH1ALOez9gJ5yBvm8AgAA6CwCAACgmAP//s+Mw Date: Sat, 6 Dec 2014 02:23:02 +0000 Message-ID: References: <54820E74.90201@mozilla.com> <548260D2.2020703@nostrum.com> In-Reply-To: <548260D2.2020703@nostrum.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1x80-atyqGNQmR_TIQkybRWGMMo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 02:23:11 -0000 QWRhbSwNCg0KSG93ZXZlciBpZiB5b3UgbG9vayBhdCBpdCBhbm90aGVyIHdheToNCg0KQSBtYWpv cml0eSBvZiB0aGUgbWFya2V0IHNoYXJlIG9mIHRoZSBkZXNrdG9wIGJyb3dzZXIgbWFya2V0IChN aWNyb3NvZnQgYW5kIEFwcGxlKSBhcmUgYWdhaW5zdCB0aGlzIGFuZCBhIHNpZ25pZmljYW50IHNo YXJlIG9mIHRoZSBtb2JpbGUgYnJvd3NlciBtYXJrZXQgKEFwcGxlLCBNaWNyb3NvZnQgYW5kIEJs YWNrQmVycnkpIGFyZSBhZ2FpbnN0IHRoaXMuDQoNClRoYXQgZG9lc27igJl0IHNlZW0gdG8gbWUg YXMgbWFqb3IgcHJvZ3Jlc3MgdG93YXJkcyBjb25zZW5zdXMgYnkgdGhlIHBlb3BsZSB3aG8gYXJl IHN1cHBvc2VkIHRvIGFjdHVhbGx5IGNvbXBseSB3aXRoIHRoZSB0d28gTVRJIGRlY2lzaW9uIGlu IG9yZGVyIHRvIGVuc3VyZSBpbnRlcm9wZXJhYmlsaXR5LiBBdCBsZWFzdCBub3QgaW4gdGhlIHJl YWwgd29ybGQgb2Ygc2hpcHBpbmcgcHJvZHVjdCB3aGVyZSBpdCByZWFsbHkgbWF0dGVycy4NCg0K QW5kcmV3DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBydGN3ZWIgW21haWx0 bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkYW0gUm9hY2gNClNlbnQ6 IEZyaWRheSwgRGVjZW1iZXIgMDUsIDIwMTQgODo1MCBQTQ0KVG86IERhdmlkIFNpbmdlcjsgSmVh bi1NYXJjIFZhbGluDQpDYzogcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0g Y29uZmlybWluZyBzZW5zZSBvZiB0aGUgcm9vbTogbXRpIGNvZGVjDQoNCk9uIDEyLzUvMTQgMTU6 MjYsIERhdmlkIFNpbmdlciB3cm90ZToNCj4+IE9uIERlYyA1LCAyMDE0LCBhdCAxMTo1OCAsIEpl YW4tTWFyYyBWYWxpbiA8am12YWxpbkBtb3ppbGxhLmNvbT4gd3JvdGU6DQo+PiAzKSBUaGlzIGlz IHRoZSBvbmx5IHByb3Bvc2FsIHRoYXQgZ2V0cyBzdXBwb3J0IGZyb20gYm90aCBjYW1wcw0KPiBp ZiB5b3UgY291bGQgc3BlYWsgb25seSBmb3IgeW91cnNlbGYsIGFuZCBub3Qgb3RoZXJzLCB0aGF0 IG1pZ2h0IGJlIGJldHRlci4gIFlvdeKAmXJlIGNsYWltaW5nIHN1cHBvcnQgYnkgb3RoZXIgcGVv cGxlIGhlcmUuDQo+DQoNCklmIEkgcmVhZCBKZWFuLU1hcmMncyBzdGF0ZW1lbnQgY29ycmVjdGx5 LCBpdCdzIG5vdCBzcGVha2luZyBvbiBiZWhhbGYgb2Ygb3RoZXIgcGVvcGxlOyBpdCdzIHVzaW5n IHdoYXQgdGhleSBoYXZlIGFscmVhZHkgc2FpZCwgb24gdGhlIHJlY29yZCBbMV0sIGFzIGEgdmFs aWQgcGFydCBvZiBoaXMgcmF0aW9uYWxlLg0KDQpJJ2QgbGlrZSB0byByZWluZm9yY2UgdGhpcyBz ZW50aW1lbnQuIEkgc3VwcG9ydCB0aGlzIHByb3Bvc2FsIG5vdCBiZWNhdXNlIEkgdGhpbmsgaXQg aXMgdGhlIGJlc3Qgc29sdXRpb24sIGJ1dCBiZWNhdXNlIGl0IGlzIHRoZSBmaXJzdCBNVEkgdmlk ZW8gY29kZWMgcHJvcG9zYWwgdGhhdCB0aGUgYWN0dWFsIGltcGxlbWVudG9ycyBpbiB0aGlzIHRl Y2hub2xvZ3kgc3BhY2UgaGF2ZSBldmVuIHJlbW90ZWx5IGFncmVlZCBvbiBzaW5jZSB0aGUgZGlz Y3Vzc2lvbiBiZWdhbi4gSSBzdXBwb3J0IHRoaXMgcHJvcG9zYWwgcHJpbWFyaWx5IGJlY2F1c2Ug aXQgaXMgdGhlIG9ubHkgc29sdXRpb24gd2UgaGF2ZSB5ZXQgc2VlbiB0aGF0IGhhcyBhIGNyZWRp YmxlIGNoYW5jZSBvZiBzdWNjZWVkaW5nLg0KDQpUaGF0J3MgYSBwb3dlcmZ1bCByZWFzb24gLS0g YXQgbGVhc3QsIGZvciB0aG9zZSBwZW9wbGUgaW52ZXN0ZWQgaW4gdGhpcyB0ZWNobm9sb2d5IC0t IGJ1dCBpdCBuZWNlc3NhcmlseSBpbnZvbHZlcyBwb2ludGluZyB0byB0aGUgcG9zaXRpb25zIG9m IG90aGVycy4gVGhpcyBpcyBub3QgdGhlIHNhbWUgYXMgbWFraW5nIHN0YXRlbWVudHMgb24gdGhl aXIgYmVoYWxmLCBhcyB5b3UgY2xhaW07IGl0IGlzIG1lcmVseSBhY2tub3dsZWRnaW5nIHRoYXQg dGhleSd2ZSBhbHJlYWR5IG1hZGUgc3VjaCBzdGF0ZW1lbnRzLg0KDQovYQ0KDQoNCl9fX18NClsx XSBJJ20gbm90IGdvaW5nIHRocm91Z2ggdGhlIGVmZm9ydCBvZiBnYXRoZXJpbmcgY2l0YXRpb25z IGhlcmUsIGFzIEkgd291bGQgZXhwZWN0IHRoYXQgeW91LCBhbmQgYWxsIG90aGVyIGludm9sdmVk IHBhcnRpY2lwYW50cywgYXJlIHN1ZmZpY2llbnRseSBmYW1pbGlhciB3aXRoIHRoZSBvbmdvaW5n IGNvbnZlcnNhdGlvbiB0byBtYWtlIGRvaW5nIHNvIHVubmVjZXNzYXJ5LiBJZiB5b3UnZCBsaWtl IHRvIG1ha2UgdGhlIGNsYWltIHN1Y2ggcG9zaXRpb25zIGhhdmUgKm5vdCogYmVlbiBhc3NlcnRl ZCBieSB0aGUgcGFydGllcyBpbiBxdWVzdGlvbiwgSSdsbCBoYXBwaWx5IHBvaW50IHlvdSB0byBh IHRyb3ZlIG9mIHJlbGV2YW50IGVtYWlscywgbWVldGluZyBtaW51dGVzLCBzbGlkZSBkZWNrcywg YW5kIGF1ZGlvIHJlY29yZGluZ3MuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo= From nobody Fri Dec 5 19:32:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85881A8A9F for ; Fri, 5 Dec 2014 19:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vb4lstph2NBx for ; Fri, 5 Dec 2014 19:32:02 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C2E1A8A9E for ; Fri, 5 Dec 2014 19:32:02 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kq14so1861566pab.20 for ; Fri, 05 Dec 2014 19:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bSxSEMQ+s0nZviOva3nbyy3GqoYV6o+UJQTcgPRbj04=; b=05afhHppmUm7QavFYbfJQMUDaIe6fWhIvXrZ3aGR8LUQSW9pag8oIRO13H62tr8GTf Qhy4HTUAl8V3NXyw4cywtBxwp5pQUlanGdMI3sEn2Ju5M2zhvMMJdFvpR3P1kacfeL8N Zr0/MnN2uGLZzoEi4fgxHw3YlgxtZMyWjhuELdtnJkjqY+HiB4Re8jwRvss1XNL8DVTF hj7jGvOdLEK7kYfdZfT+zlaXw99aJ/JY+ZTtZjgaqTzSQCRB4IBW4Ba1msjsgLtgbX9J SlG41ovy/KUCo8Ia0wpVd4o6XyPIpOnD+FA6BKYVL6Jh1r+VCfQQcjSdIDn8Eiiv/eex /LgQ== X-Received: by 10.66.66.102 with SMTP id e6mr34882834pat.6.1417836721565; Fri, 05 Dec 2014 19:32:01 -0800 (PST) Received: from [192.168.1.137] (c-71-227-237-49.hsd1.wa.comcast.net. [71.227.237.49]) by mx.google.com with ESMTPSA id gx5sm14911269pbb.96.2014.12.05.19.32.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Dec 2014 19:32:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12B435) In-Reply-To: Date: Fri, 5 Dec 2014 19:31:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <94C89195-99FC-4807-B00B-1A94701C8724@gmail.com> References: <54820E74.90201@mozilla.com> <548260D2.2020703@nostrum.com> To: David Singer Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4_yQQBXye4nes8SKyA0_S33TFbg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 03:32:04 -0000 On Dec 5, 2014, at 17:50 , Adam Roach wrote >>>> On Dec 5, 2014, at 11:58 , Jean-Marc Valin wrote:= >>>> 3) This is the only proposal that gets support from both camps >>=20 >> If I read Jean-Marc's statement correctly, it's not speaking on behalf of= other people; it's using what they have already said, on the record [1], as= a valid part of his rationale. [BA] While this does appear to be a statement from an implementer about supp= ort in their own product, it does not correctly characterize the nature of t= he "consensus" as a whole. The "consensus" here did not involve acceptance b= y RTCWEB implementers of the necessity for them to support both H.264 and VP= 8. Had such a proposal been made it most probably would have failed. Instea= d the "consensus" call involved imposing an obligation on a subset of implem= enters without their agreement. There is a term for *that*, but it isn't "c= onsensus" - the 13 colonies called it "taxation without representation".=20 From nobody Fri Dec 5 20:19:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13E51A8AB7 for ; Fri, 5 Dec 2014 20:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCZBmMfru96U for ; Fri, 5 Dec 2014 20:19:21 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE821A8AB5 for ; Fri, 5 Dec 2014 20:19:20 -0800 (PST) Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail07.adl2.internode.on.net with ESMTP; 06 Dec 2014 14:49:19 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id EA8DCFFED0 for ; Sat, 6 Dec 2014 14:49:06 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zJOpD09D1kjj for ; Sat, 6 Dec 2014 14:49:05 +1030 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 9EBD7FFDA9 for ; Sat, 6 Dec 2014 14:49:05 +1030 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 9040280470; Sat, 6 Dec 2014 14:49:05 +1030 (ACDT) Date: Sat, 6 Dec 2014 14:49:05 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141206041905.GA19538@hex.shelbyville.oz> References: <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> <2CCC7F59-6EB2-4F11-A63E-40C89350E8F2@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4fQHquaCHOkr0_u_k4Po8VC955c Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 04:19:23 -0000 On Fri, Dec 05, 2014 at 03:13:48PM -0800, David Singer wrote: > Hi Ted > > > On Dec 5, 2014, at 14:32 , Ted Hardie wrote: > > > > Hi David, > > > > On Fri, Dec 5, 2014 at 1:42 PM, David Singer wrote: > > > > > > (Much snipped) > > > >> It really is not similar. Maybe there are licenses that one or other does not carry: in the Cisco case, we are unaware of any “unwilling to licenseâ€, whereas for VP8 there is a clear statement that no license can be had. > >> > > In both cases, the participant needs to assess whether they know of all the salient IPR, whether they have all the licenses for that IPR which they need. While I am not a lawyer, I imagine that in both cases that would involve making a determination of the relevance of the claim as well as an analysis of its license terms. It also involves an assessment of the risk that there are other claims which may later arise. > > > > To my lay person's eyes, the two assessments do look pretty similar. It appears, honestly, that you disagree with the results' of others assessments, rather than that the assessments do not need to take place in both cases. But I may be misunderstanding your point. > > OK, let me see if I can persuade you of a qualitative difference. For > each ‘must’, what is the nature and availability of licenses that I > might need from those claiming IPR? > > * H.264: all those claiming IPR offer licenses, though most of them > ask for payment * VP8: almost all offer licenses that are either free > or effectively so (pre-paid, in the case of the MPEG-LA), but there is > one for which no license is available (and it’s not an insignificant > company, or one not active in the field, or a small set of patents) Ted was doing such a good job explaining this, that I was just going to leave it to him. But if you're going to call me out to be your champion, to make your point here, then ... ok :> > For me, that is a major difference. Clearly for others (e.g. Ron who > has said as much), the cost is more significant than the license > availability. No. You've clearly missed the point here, and you've missed it on the order of Astronomical Units, not Barns. You're going have to repeat Free Software 101 I'm afraid. I've never said anything of the sort. Let me see if I can explain to you the qualitative difference ... I'd gladly pay to be able to use VP8. This isn't about money at all. There simply is no amount of money that can remove the real crippling costs of being burdened with or indentured to H.264 at present. This is about Freedom. The availability of a license for Freedom even. The freedom to not have to count and track the users of my software. The freedom to not have to ask permission to do what I need to do. The freedom to not have to worry about anticompetitive patent abuse. The freedom to interoperate with anyone else who values freedom. The freedom to actually be able to get on with doing genuinely interesting things instead of dealing with dinosaur legalese from companies that no longer know how to do that. I could go on, but that's probably enough for you to be able to google the concept from there as your first homework assignment. Do you want to know the really fun part about where I learned how important these things were? You're going to get a kick out of this. Go find a manual for an apple][ and turn to the back page! When you're done studying its schematics and the source for its ROM, we can get together for a beer and reminisce about where it All Went So Sadly Wrong. :) > I think inserting the ‘must’ here means that companies will either > ignore it, or claim not to be a WebRTC Browser, neither of which > advance the cause of interoperability at all. So far we have something like 75% or more of the browser user market share on board. The only players in that game who aren't, are a company that won't even tell us whether they plan to implement this or not (which clearly makes their opinion vitally important!), and another company who at some point at least seemed quite determined to fork this effort and go off and do something completely different all on their own. That seems like a pretty good base to start from to me. Maybe the holdouts will want to come play with us eventually, and maybe they won't. But we can't wait for them forever while they learn to tie their shoelaces. Enough people made that mistake with SIP, let's not repeat it again here. Fiducially, Ron From nobody Fri Dec 5 20:24:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4605A1A8AB9 for ; Fri, 5 Dec 2014 20:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZK68t6sW_aPF for ; Fri, 5 Dec 2014 20:24:16 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497891A8ABB for ; Fri, 5 Dec 2014 20:24:16 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id l18so2408068wgh.12 for ; Fri, 05 Dec 2014 20:24:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VFui9UXAQe4jP1NS37gbPLZUApxTsBxJUvFD2sm6p1Q=; b=CYPDNLkgc0TnvZmiq+jZUjXrFbKmebQ5+MEDHzopHtY+RfZXgwHDHr8Sll475BEEec 8OCaPtvvR95OkhdBus+HvnJCE6iRf6hW3ZuQ2njHYOnPteZMjKcZT2xKDrgjFhy4cTCJ +42nT78Zj5sufkBxydkX/y5xFihJLfMcvwYjwPRP1MD3pjd4rEvIz8dSgnc7GbvZSfan ok8z8q4jNu57iqql5xyCaMm1/R9Wuz7z4Y/uoi0KR+WEXvDK9Rq6KGCjpx0FzQUroNtP Eh/XBA9x6NRVeS06WH+ng0H5R+IHvsog41ILtoRgmyT2mDTDZZeQ3Wm0KC7Vw1irvydt Wceg== X-Gm-Message-State: ALoCoQn2/dHQ8vsxjhDG63Oy0MdK67JmdsGKbr8VWw1/5PtD3PiEWeUvYyNNMlccp1l7RMANG3Ro MIME-Version: 1.0 X-Received: by 10.180.107.136 with SMTP id hc8mr8941330wib.32.1417839854880; Fri, 05 Dec 2014 20:24:14 -0800 (PST) Received: by 10.194.6.39 with HTTP; Fri, 5 Dec 2014 20:24:14 -0800 (PST) Received: by 10.194.6.39 with HTTP; Fri, 5 Dec 2014 20:24:14 -0800 (PST) In-Reply-To: <20141206041905.GA19538@hex.shelbyville.oz> References: <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> <2CCC7F59-6EB2-4F11-A63E-40C89350E8F2@apple.com> <20141206041905.GA19538@hex.shelbyville.oz> Date: Sat, 6 Dec 2014 06:24:14 +0200 Message-ID: From: Mohammed Raad To: Ron Content-Type: multipart/alternative; boundary=e89a8f3bad45e620380509849018 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lVwrUY_N-qYsX60EIfqTzJ8cNTQ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 04:24:19 -0000 --e89a8f3bad45e620380509849018 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bravo! On 6 Dec 2014 06:19, "Ron" wrote: > On Fri, Dec 05, 2014 at 03:13:48PM -0800, David Singer wrote: > > Hi Ted > > > > > On Dec 5, 2014, at 14:32 , Ted Hardie wrote: > > > > > > Hi David, > > > > > > On Fri, Dec 5, 2014 at 1:42 PM, David Singer wrote= : > > > > > > > > > (Much snipped) > > > > > >> It really is not similar. Maybe there are licenses that one or othe= r > does not carry: in the Cisco case, we are unaware of any =E2=80=9Cunwill= ing to > license=E2=80=9D, whereas for VP8 there is a clear statement that no lice= nse can be > had. > > >> > > > In both cases, the participant needs to assess whether they know of > all the salient IPR, whether they have all the licenses for that IPR whic= h > they need. While I am not a lawyer, I imagine that in both cases that > would involve making a determination of the relevance of the claim as wel= l > as an analysis of its license terms. It also involves an assessment of t= he > risk that there are other claims which may later arise. > > > > > > To my lay person's eyes, the two assessments do look pretty similar. > It appears, honestly, that you disagree with the results' of others > assessments, rather than that the assessments do not need to take place i= n > both cases. But I may be misunderstanding your point. > > > > OK, let me see if I can persuade you of a qualitative difference. For > > each =E2=80=98must=E2=80=99, what is the nature and availability of lic= enses that I > > might need from those claiming IPR? > > > > * H.264: all those claiming IPR offer licenses, though most of them > > ask for payment * VP8: almost all offer licenses that are either free > > or effectively so (pre-paid, in the case of the MPEG-LA), but there is > > one for which no license is available (and it=E2=80=99s not an insignif= icant > > company, or one not active in the field, or a small set of patents) > > > Ted was doing such a good job explaining this, that I was just going to > leave it to him. But if you're going to call me out to be your champion, > to make your point here, then ... ok :> > > > For me, that is a major difference. Clearly for others (e.g. Ron who > > has said as much), the cost is more significant than the license > > availability. > > No. You've clearly missed the point here, and you've missed it on the > order of Astronomical Units, not Barns. You're going have to repeat > Free Software 101 I'm afraid. I've never said anything of the sort. > > Let me see if I can explain to you the qualitative difference ... > > I'd gladly pay to be able to use VP8. This isn't about money at all. > There simply is no amount of money that can remove the real crippling > costs of being burdened with or indentured to H.264 at present. > > This is about Freedom. The availability of a license for Freedom even. > > The freedom to not have to count and track the users of my software. > The freedom to not have to ask permission to do what I need to do. > The freedom to not have to worry about anticompetitive patent abuse. > The freedom to interoperate with anyone else who values freedom. > The freedom to actually be able to get on with doing genuinely > interesting things instead of dealing with dinosaur legalese from > companies that no longer know how to do that. > > I could go on, but that's probably enough for you to be able to > google the concept from there as your first homework assignment. > > > Do you want to know the really fun part about where I learned how > important these things were? You're going to get a kick out of > this. Go find a manual for an apple][ and turn to the back page! > > When you're done studying its schematics and the source for its > ROM, we can get together for a beer and reminisce about where it > All Went So Sadly Wrong. :) > > > > I think inserting the =E2=80=98must=E2=80=99 here means that companies = will either > > ignore it, or claim not to be a WebRTC Browser, neither of which > > advance the cause of interoperability at all. > > So far we have something like 75% or more of the browser user market > share on board. The only players in that game who aren't, are a > company that won't even tell us whether they plan to implement this > or not (which clearly makes their opinion vitally important!), and > another company who at some point at least seemed quite determined > to fork this effort and go off and do something completely different > all on their own. > > That seems like a pretty good base to start from to me. > > Maybe the holdouts will want to come play with us eventually, and > maybe they won't. But we can't wait for them forever while they > learn to tie their shoelaces. Enough people made that mistake > with SIP, let's not repeat it again here. > > > Fiducially, > Ron > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --e89a8f3bad45e620380509849018 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Bravo!

On 6 Dec 2014 06:19, "Ron" <ron@debian.org> wrote:
On Fri, Dec 05, 2014 at 03:13:48PM -08= 00, David Singer wrote:
> Hi Ted
>
> > On Dec 5, 2014, at 14:32 , Ted Hardie <ted.ietf@gmail.com> wrote:
> >
> > Hi David,
> >
> > On Fri, Dec 5, 2014 at 1:42 PM, David Singer <singer@apple.com> wrote:
> >
> >
> > (Much snipped)
> >
> >> It really is not similar.=C2=A0 Maybe there are licenses that= one or other does not carry:=C2=A0 in the Cisco case, we are unaware of an= y =E2=80=9Cunwilling to license=E2=80=9D, whereas for VP8 there is a clear = statement that no license can be had.
> >>
> > In both cases, the participant needs to assess whether they know = of all the salient IPR, whether they have all the licenses for that IPR whi= ch they need.=C2=A0 =C2=A0While I am not a lawyer, I imagine that in both c= ases that would involve making a determination of the relevance of the clai= m as well as an analysis of its license terms.=C2=A0 It also involves an as= sessment of the risk that there are other claims which may later arise.
> >
> > To my lay person's eyes, the two assessments do look pretty s= imilar.=C2=A0 It appears, honestly, that you disagree with the results'= of others assessments, rather than that the assessments do not need to tak= e place in both cases.=C2=A0 But I may be misunderstanding your point.
>
> OK, let me see if I can persuade you of a qualitative difference.=C2= =A0 For
> each =E2=80=98must=E2=80=99, what is the nature and availability of li= censes that I
> might need from those claiming IPR?
>
> * H.264: all those claiming IPR offer licenses, though most of them > ask for payment * VP8: almost all offer licenses that are either free<= br> > or effectively so (pre-paid, in the case of the MPEG-LA), but there is=
> one for which no license is available (and it=E2=80=99s not an insigni= ficant
> company, or one not active in the field, or a small set of patents)

Ted was doing such a good job explaining this, that I was just going to
leave it to him.=C2=A0 But if you're going to call me out to be your ch= ampion,
to make your point here, then ...=C2=A0 ok :>

> For me, that is a major difference.=C2=A0 Clearly for others (e.g. Ron= who
> has said as much), the cost is more significant than the license
> availability.

No.=C2=A0 You've clearly missed the point here, and you've missed i= t on the
order of Astronomical Units, not Barns.=C2=A0 You're going have to repe= at
Free Software 101 I'm afraid.=C2=A0 I've never said anything of the= sort.

Let me see if I can explain to you the qualitative difference ...

I'd gladly pay to be able to use VP8.=C2=A0 This isn't about money = at all.
There simply is no amount of money that can remove the real crippling
costs of being burdened with or indentured to H.264 at present.

This is about Freedom.=C2=A0 The availability of a license for Freedom even= .

The freedom to not have to count and track the users of my software.
The freedom to not have to ask permission to do what I need to do.
The freedom to not have to worry about anticompetitive patent abuse.
The freedom to interoperate with anyone else who values freedom.
The freedom to actually be able to get on with doing genuinely
interesting things instead of dealing with dinosaur legalese from
companies that no longer know how to do that.

I could go on, but that's probably enough for you to be able to
google the concept from there as your first homework assignment.


Do you want to know the really fun part about where I learned how
important these things were?=C2=A0 You're going to get a kick out of this.=C2=A0 Go find a manual for an apple][ and turn to the back page!

When you're done studying its schematics and the source for its
ROM, we can get together for a beer and reminisce about where it
All Went So Sadly Wrong. :)


> I think inserting the =E2=80=98must=E2=80=99 here means that companies= will either
> ignore it, or claim not to be a WebRTC Browser, neither of which
> advance the cause of interoperability at all.

So far we have something like 75% or more of the browser user market
share on board.=C2=A0 The only players in that game who aren't, are a company that won't even tell us whether they plan to implement this
or not (which clearly makes their opinion vitally important!), and
another company who at some point at least seemed quite determined
to fork this effort and go off and do something completely different
all on their own.

That seems like a pretty good base to start from to me.

Maybe the holdouts will want to come play with us eventually, and
maybe they won't.=C2=A0 But we can't wait for them forever while th= ey
learn to tie their shoelaces.=C2=A0 Enough people made that mistake
with SIP, let's not repeat it again here.


=C2=A0 Fiducially,
=C2=A0 Ron


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--e89a8f3bad45e620380509849018-- From nobody Fri Dec 5 21:09:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5811A88C5 for ; Fri, 5 Dec 2014 21:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGOKO-xwWrDs for ; Fri, 5 Dec 2014 21:09:46 -0800 (PST) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 215F21A8AC3 for ; Fri, 5 Dec 2014 21:09:46 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id h15so373878igd.13 for ; Fri, 05 Dec 2014 21:09:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=StALJ6s4ifbue6uIKUc9Ab49OFIs06T6a5EDaZ/doDg=; b=jmMiRKGMkSaJEGRq7f9yDKcvQ6pkjK56nSK8vE7LsnWlNpLDgeyiUknNifZcVTaCxt G7mJeIYBmJwYhWAoOcWlB9t9RKwjatfRCR66Yyf3BvKTWM9LbaWixiImyn9im51h7MLD ECZwDD/99vc2LCWs0UY+0qgR/ACwAWo7tjLZcwx6IcSLUJnC5ylydKuAThXWsKdcd6Ge eHKIL/nepXjybnKrbQHlmPEtKwOPbXzzPxwmS/wrrO4Q39kqyonOk8NYxqkVyQ5vQHIj 5ovGYNpktb8G3/cnBrzOoHGthRqgAre3LDIYwVQXYKTCV3re+asHVn3dlK9J2Skn7leX mBZw== X-Gm-Message-State: ALoCoQkdRjTAbfAfzYgLF7MaGOj2iG0aT9qkelh42w14gGULlwah/1d6bj/A7PBYWxDMJ0KzwwH8 X-Received: by 10.50.43.231 with SMTP id z7mr5917589igl.36.1417842585424; Fri, 05 Dec 2014 21:09:45 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id f187sm17086457ioe.11.2014.12.05.21.09.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Dec 2014 21:09:44 -0800 (PST) Message-ID: <54828F6C.90401@bbs.darktech.org> Date: Sat, 06 Dec 2014 00:09:00 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54820E74.90201@mozilla.com> <548260D2.2020703@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/oCo4C9edDvJSq-D0mkRu66ZySOI Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 05:09:49 -0000 Andrew, I don't know where you're getting your numbers from, but according to http://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Summary_table Chrome, Firefox and Opera make up the majority market-share on the desktop and mobile. Most sources seem to agree that IE is on the decline, while Safari is increasing slowly. Gili On 05/12/2014 9:23 PM, Andrew Allen wrote: > Adam, > > However if you look at it another way: > > A majority of the market share of the desktop browser market (Microsoft and Apple) are against this and a significant share of the mobile browser market (Apple, Microsoft and BlackBerry) are against this. > > That doesn’t seem to me as major progress towards consensus by the people who are supposed to actually comply with the two MTI decision in order to ensure interoperability. At least not in the real world of shipping product where it really matters. > > Andrew > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Friday, December 05, 2014 8:50 PM > To: David Singer; Jean-Marc Valin > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] confirming sense of the room: mti codec > > On 12/5/14 15:26, David Singer wrote: >>> On Dec 5, 2014, at 11:58 , Jean-Marc Valin wrote: >>> 3) This is the only proposal that gets support from both camps >> if you could speak only for yourself, and not others, that might be better. You’re claiming support by other people here. >> > If I read Jean-Marc's statement correctly, it's not speaking on behalf of other people; it's using what they have already said, on the record [1], as a valid part of his rationale. > > I'd like to reinforce this sentiment. I support this proposal not because I think it is the best solution, but because it is the first MTI video codec proposal that the actual implementors in this technology space have even remotely agreed on since the discussion began. I support this proposal primarily because it is the only solution we have yet seen that has a credible chance of succeeding. > > That's a powerful reason -- at least, for those people invested in this technology -- but it necessarily involves pointing to the positions of others. This is not the same as making statements on their behalf, as you claim; it is merely acknowledging that they've already made such statements. > > /a > > > ____ > [1] I'm not going through the effort of gathering citations here, as I would expect that you, and all other involved participants, are sufficiently familiar with the ongoing conversation to make doing so unnecessary. If you'd like to make the claim such positions have *not* been asserted by the parties in question, I'll happily point you to a trove of relevant emails, meeting minutes, slide decks, and audio recordings. > > _______________________________________________ > 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 From nobody Fri Dec 5 21:27:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A876F1A8AC3 for ; Fri, 5 Dec 2014 21:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJFHeQDmNW1h for ; Fri, 5 Dec 2014 21:27:52 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F7781A8AC2 for ; Fri, 5 Dec 2014 21:27:52 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id u10so1523293lbd.20 for ; Fri, 05 Dec 2014 21:27:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eQe8fuL4wLVjySxPjV+6VQrBtCDPojkTDgplBN65yTI=; b=LVj1yurYNPh7sGK3ZTgqR85mVCJoGUAutslnBWGMbmDjdWO5GOqn3jmL2rnJ3iluHN vMvcAtXhG/0zcT2tOIPYHt+fXtj3/0/n8f1ez2DjX/DvwABNTHj/LoIDHw0n4syLotuh tzo7AkpZDMV60B6gT6CZYduqTY91prU0EtrDvVCYRlJsEXcdI7binNFE0ubSnC6oH3gG 18HvJ1XrLEpys4lhHsSPJHV1yZaQIU/3Atmjj2PLeGnJYSRkbf+SJ84xyb3GQU5maOTB NKAxB9DZZ87KBlrb8qD/JXnpPhRUkg7TOv4tNebgUNOIOxCTRqa1D+fiYD7jPBT+9BpK CFgw== MIME-Version: 1.0 X-Received: by 10.152.25.168 with SMTP id d8mr6127091lag.41.1417843670803; Fri, 05 Dec 2014 21:27:50 -0800 (PST) Received: by 10.112.188.229 with HTTP; Fri, 5 Dec 2014 21:27:50 -0800 (PST) In-Reply-To: <94C89195-99FC-4807-B00B-1A94701C8724@gmail.com> References: <54820E74.90201@mozilla.com> <548260D2.2020703@nostrum.com> <94C89195-99FC-4807-B00B-1A94701C8724@gmail.com> Date: Fri, 5 Dec 2014 21:27:50 -0800 Message-ID: From: Monty Montgomery To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IQwCAe98y4CrbzeaZcelpsDHBqI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 05:27:53 -0000 >There is a term for *that*, but it isn't "consensus" - the 13 colonies called it "taxation without representation". There's a difference between 'not represented' and 'holding a minority opinion'. Monty From nobody Fri Dec 5 21:40:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9DC61A8BB3 for ; Fri, 5 Dec 2014 21:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAXudJupiG4i for ; Fri, 5 Dec 2014 21:40:52 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 30D761A8AFC for ; Fri, 5 Dec 2014 21:40:35 -0800 (PST) Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 06 Dec 2014 00:40:20 -0500 Received: from XCT116CNC.rim.net (10.65.161.216) by XCT108CNC.rim.net (10.65.161.208) with Microsoft SMTP Server (TLS) id 14.3.210.2; Sat, 6 Dec 2014 00:40:19 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Sat, 6 Dec 2014 00:40:19 -0500 From: Andrew Allen To: Adam Roach , Gaelle Martin-Cocher , Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) Thread-Index: AQHQDyew2za5sQikUES+QP80tOoCX5x+j7gAgAAgMwCAAChyAIAADcQAgAAeaYCAAKv2gIAB/3mAgAAErgCAAFtGaw== Date: Sat, 6 Dec 2014 05:40:18 +0000 Message-ID: <20141206054017.5955730.89689.3585@blackberry.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F60A8.3080302@alvestrand.no> <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com> <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net> <547FA924.3000504@mozilla.com> <92D0D52F3A63344CA478CF12DB0648AADF35455C@XMB111CNC.rim.net> <548052E7.1050007@alvestrand.no> <92D0D52F3A63344CA478CF12DB0648AADF359C76@XMB111CNC.rim.net>, <548203E2.90602@nostrum.com> In-Reply-To: <548203E2.90602@nostrum.com> Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_201412060540175955730896893585blackberrycom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CMzBHYbADxjxe8ZJQuARbbQ40qo Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 05:40:54 -0000 --_000_201412060540175955730896893585blackberrycom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As Harald already admitted this entire debate has been about companies busi= ness interests and not technical merits. There is ABSOLUTELY NO TECHNICAL R= EASON to have 2 MTI video codecs. This has been company business interest f= rom the start. Just about every comment I see in this thread is about what advances or dis= advantages a particular company that the individual works for. Sent from my BlackBerry 10 smartphone. From: Adam Roach Sent: Friday, December 5, 2014 14:14 To: Gaelle Martin-Cocher; Harald Alvestrand; rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, st= ill, sorry) On 12/5/14 10:56, Gaelle Martin-Cocher wrote: > Is that a google position or just an assumption? We speak as individuals. > Assuming browsers have to implement both and that this question is out of= the way. I was about to make the same point that Harald did, but he beat me to it: the questions were asked together because the nature of the compromise was, for many people, "I'm okay with X if and only if Y". Characterizing this as an unconditional acceptance of one without the other is ridiculous. /a _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_201412060540175955730896893585blackberrycom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


Sent from my BlackBerry 10 smartphone.
From: Adam Roach
Sent: Friday, December 5, 2014 14:14
To: Gaelle Martin-Cocher; Harald Alvestrand; rtcweb@ietf.org
Subject: Re: [rtcweb] Finishing up the Video Codec document, MT= I (again, still, sorry)

On 12/5/14 10:56, Gaelle Martin-Cocher wrote:
> Is that a google position or just an assumption?

We speak as individuals.


> Assuming browsers have to implement both and that this question is out= of the way.

I was about to make the same point that Harald did, but he beat me to
it: the questions were asked together because the nature of the
compromise was, for many people, "I'm okay with X if and only if Y&quo= t;.
Characterizing this as an unconditional acceptance of one without the
other is ridiculous.

/a

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb
 --_000_201412060540175955730896893585blackberrycom_-- From nobody Fri Dec 5 22:01:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434F91A07BD for ; Fri, 5 Dec 2014 22:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRJozWAAfbYT for ; Fri, 5 Dec 2014 22:01:39 -0800 (PST) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1221A0181 for ; Fri, 5 Dec 2014 22:01:39 -0800 (PST) Received: by mail-pd0-f169.google.com with SMTP id z10so1985701pdj.28 for ; Fri, 05 Dec 2014 22:01:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=/+U04pGa6JVhuw1qlM9HVeZ6StYlksOFfdHXKOe88JU=; b=gHj3wdXPzIPCn6lkgwWsAxkOqBs+oe8ar/D0xPjyu0XZl3lD/JZcH0+GUe1xfpUdDQ d6L+kzfsd5bMkBpN3Y3aW4GlDdaZLvIz7jECT+ODJ/ia2X8dYFGI42V/tqGRLiyMyFIr 50jGSUaeVRsn4u97Z1QBoqbDCdjyXPlcP+OyQxhCZOTkdAotX+6A2Mkq45/9bTiO3Uq2 0DcAhHDxr7Tf/oTJZC4oxT8bpPCwlRVJvuMh0cN2AoQQItqcYVrOiDW8zo0KVNIQvOX7 k8I1D+l7GFiIaeYcI85MB48uH2d1tqGqy9d9e2TpZagTfRUeJQnvTCpZw9Z2rJhdXgOq cDtg== X-Received: by 10.70.54.1 with SMTP id f1mr1913111pdp.63.1417845698397; Fri, 05 Dec 2014 22:01:38 -0800 (PST) Received: from [10.203.138.154] (mobile-166-171-251-160.mycingular.net. [166.171.251.160]) by mx.google.com with ESMTPSA id do16sm10873400pac.48.2014.12.05.22.01.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Dec 2014 22:01:07 -0800 (PST) References: <54820E74.90201@mozilla.com> <548260D2.2020703@nostrum.com> <94C89195-99FC-4807-B00B-1A94701C8724@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B435) From: Bernard Aboba Date: Fri, 5 Dec 2014 22:01:02 -0800 To: Monty Montgomery Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/SdsjkZ1nFYQJE2JRxvQRQvrWHpM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 06:01:40 -0000 On Dec 5, 2014, at 9:27 PM, Monty Montgomery =20 > There's a difference between 'not represented' and 'holding a minority opi= nion'. [BA] Rather than applying equally to all RTCWEB implementers, the dual MTI r= equirement is applied unequally to implementers of a JS API specification cr= eated in another SDO. The W3C gets to decide the requirements for implement= ers of their specifications, not the IETF. So no, this isn't just an IETF co= nsensus issue.= From nobody Sat Dec 6 00:33:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9731A8F4E for ; Sat, 6 Dec 2014 00:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gCBNBxQVadl for ; Sat, 6 Dec 2014 00:33:19 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 318EA1A005F for ; Sat, 6 Dec 2014 00:33:18 -0800 (PST) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 06 Dec 2014 03:33:12 -0500 Received: from XCT116CNC.rim.net (10.65.161.216) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.210.2; Sat, 6 Dec 2014 03:33:12 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Sat, 6 Dec 2014 03:33:11 -0500 From: Andrew Allen To: cowwoc , "rtcweb@ietf.org" Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEJCKEBti1FXXNkmH1ALOez9gJ5yBvm8AgAA6CwCAACgmAP//s+MwgACDqgD//+T5cA== Date: Sat, 6 Dec 2014 08:33:11 +0000 Message-ID: References: <54820E74.90201@mozilla.com> <548260D2.2020703@nostrum.com> <54828F6C.90401@bbs.darktech.org> In-Reply-To: <54828F6C.90401@bbs.darktech.org> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/n8K2L3TVPkI_DhwXYChHWeMR_kY Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 08:33:21 -0000 aHR0cDovL3d3dy5uZXRtYXJrZXRzaGFyZS5jb20vYnJvd3Nlci1tYXJrZXQtc2hhcmUuYXNweD9x cHJpZD0wJnFwY3VzdG9tZD0wDQoNCmh0dHA6Ly93d3cubmV0bWFya2V0c2hhcmUuY29tL2Jyb3dz ZXItbWFya2V0LXNoYXJlLmFzcHg/cXByaWQ9MCZxcGN1c3RvbWQ9MQ0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIGNvd3dvYw0KU2VudDogU2F0dXJkYXksIERlY2VtYmVyIDA2LCAy MDE0IDEyOjA5IEFNDQpUbzogcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0g Y29uZmlybWluZyBzZW5zZSBvZiB0aGUgcm9vbTogbXRpIGNvZGVjDQoNCkFuZHJldywNCg0KSSBk b24ndCBrbm93IHdoZXJlIHlvdSdyZSBnZXR0aW5nIHlvdXIgbnVtYmVycyBmcm9tLCBidXQgYWNj b3JkaW5nIHRvIGh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvVXNhZ2Vfc2hhcmVfb2Zfd2Vi X2Jyb3dzZXJzI1N1bW1hcnlfdGFibGUNCkNocm9tZSwgRmlyZWZveCBhbmQgT3BlcmEgbWFrZSB1 cCB0aGUgbWFqb3JpdHkgbWFya2V0LXNoYXJlIG9uIHRoZSBkZXNrdG9wIGFuZCBtb2JpbGUuDQoN Ck1vc3Qgc291cmNlcyBzZWVtIHRvIGFncmVlIHRoYXQgSUUgaXMgb24gdGhlIGRlY2xpbmUsIHdo aWxlIFNhZmFyaSBpcyBpbmNyZWFzaW5nIHNsb3dseS4NCg0KR2lsaQ0KDQpPbiAwNS8xMi8yMDE0 IDk6MjMgUE0sIEFuZHJldyBBbGxlbiB3cm90ZToNCj4gQWRhbSwNCj4NCj4gSG93ZXZlciBpZiB5 b3UgbG9vayBhdCBpdCBhbm90aGVyIHdheToNCj4NCj4gQSBtYWpvcml0eSBvZiB0aGUgbWFya2V0 IHNoYXJlIG9mIHRoZSBkZXNrdG9wIGJyb3dzZXIgbWFya2V0IChNaWNyb3NvZnQgYW5kIEFwcGxl KSBhcmUgYWdhaW5zdCB0aGlzIGFuZCBhIHNpZ25pZmljYW50IHNoYXJlIG9mIHRoZSBtb2JpbGUg YnJvd3NlciBtYXJrZXQgKEFwcGxlLCBNaWNyb3NvZnQgYW5kIEJsYWNrQmVycnkpIGFyZSBhZ2Fp bnN0IHRoaXMuDQo+DQo+IFRoYXQgZG9lc27igJl0IHNlZW0gdG8gbWUgYXMgbWFqb3IgcHJvZ3Jl c3MgdG93YXJkcyBjb25zZW5zdXMgYnkgdGhlIHBlb3BsZSB3aG8gYXJlIHN1cHBvc2VkIHRvIGFj dHVhbGx5IGNvbXBseSB3aXRoIHRoZSB0d28gTVRJIGRlY2lzaW9uIGluIG9yZGVyIHRvIGVuc3Vy ZSBpbnRlcm9wZXJhYmlsaXR5LiBBdCBsZWFzdCBub3QgaW4gdGhlIHJlYWwgd29ybGQgb2Ygc2hp cHBpbmcgcHJvZHVjdCB3aGVyZSBpdCByZWFsbHkgbWF0dGVycy4NCj4NCj4gQW5kcmV3DQo+DQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dl Yi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWRhbSBSb2FjaA0KPiBTZW50OiBGcmlk YXksIERlY2VtYmVyIDA1LCAyMDE0IDg6NTAgUE0NCj4gVG86IERhdmlkIFNpbmdlcjsgSmVhbi1N YXJjIFZhbGluDQo+IENjOiBydGN3ZWJAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtydGN3ZWJd IGNvbmZpcm1pbmcgc2Vuc2Ugb2YgdGhlIHJvb206IG10aSBjb2RlYw0KPg0KPiBPbiAxMi81LzE0 IDE1OjI2LCBEYXZpZCBTaW5nZXIgd3JvdGU6DQo+Pj4gT24gRGVjIDUsIDIwMTQsIGF0IDExOjU4 ICwgSmVhbi1NYXJjIFZhbGluIDxqbXZhbGluQG1vemlsbGEuY29tPiB3cm90ZToNCj4+PiAzKSBU aGlzIGlzIHRoZSBvbmx5IHByb3Bvc2FsIHRoYXQgZ2V0cyBzdXBwb3J0IGZyb20gYm90aCBjYW1w cw0KPj4gaWYgeW91IGNvdWxkIHNwZWFrIG9ubHkgZm9yIHlvdXJzZWxmLCBhbmQgbm90IG90aGVy cywgdGhhdCBtaWdodCBiZSBiZXR0ZXIuICBZb3XigJlyZSBjbGFpbWluZyBzdXBwb3J0IGJ5IG90 aGVyIHBlb3BsZSBoZXJlLg0KPj4NCj4gSWYgSSByZWFkIEplYW4tTWFyYydzIHN0YXRlbWVudCBj b3JyZWN0bHksIGl0J3Mgbm90IHNwZWFraW5nIG9uIGJlaGFsZiBvZiBvdGhlciBwZW9wbGU7IGl0 J3MgdXNpbmcgd2hhdCB0aGV5IGhhdmUgYWxyZWFkeSBzYWlkLCBvbiB0aGUgcmVjb3JkIFsxXSwg YXMgYSB2YWxpZCBwYXJ0IG9mIGhpcyByYXRpb25hbGUuDQo+DQo+IEknZCBsaWtlIHRvIHJlaW5m b3JjZSB0aGlzIHNlbnRpbWVudC4gSSBzdXBwb3J0IHRoaXMgcHJvcG9zYWwgbm90IGJlY2F1c2Ug SSB0aGluayBpdCBpcyB0aGUgYmVzdCBzb2x1dGlvbiwgYnV0IGJlY2F1c2UgaXQgaXMgdGhlIGZp cnN0IE1USSB2aWRlbyBjb2RlYyBwcm9wb3NhbCB0aGF0IHRoZSBhY3R1YWwgaW1wbGVtZW50b3Jz IGluIHRoaXMgdGVjaG5vbG9neSBzcGFjZSBoYXZlIGV2ZW4gcmVtb3RlbHkgYWdyZWVkIG9uIHNp bmNlIHRoZSBkaXNjdXNzaW9uIGJlZ2FuLiBJIHN1cHBvcnQgdGhpcyBwcm9wb3NhbCBwcmltYXJp bHkgYmVjYXVzZSBpdCBpcyB0aGUgb25seSBzb2x1dGlvbiB3ZSBoYXZlIHlldCBzZWVuIHRoYXQg aGFzIGEgY3JlZGlibGUgY2hhbmNlIG9mIHN1Y2NlZWRpbmcuDQo+DQo+IFRoYXQncyBhIHBvd2Vy ZnVsIHJlYXNvbiAtLSBhdCBsZWFzdCwgZm9yIHRob3NlIHBlb3BsZSBpbnZlc3RlZCBpbiB0aGlz IHRlY2hub2xvZ3kgLS0gYnV0IGl0IG5lY2Vzc2FyaWx5IGludm9sdmVzIHBvaW50aW5nIHRvIHRo ZSBwb3NpdGlvbnMgb2Ygb3RoZXJzLiBUaGlzIGlzIG5vdCB0aGUgc2FtZSBhcyBtYWtpbmcgc3Rh dGVtZW50cyBvbiB0aGVpciBiZWhhbGYsIGFzIHlvdSBjbGFpbTsgaXQgaXMgbWVyZWx5IGFja25v d2xlZGdpbmcgdGhhdCB0aGV5J3ZlIGFscmVhZHkgbWFkZSBzdWNoIHN0YXRlbWVudHMuDQo+DQo+ IC9hDQo+DQo+DQo+IF9fX18NCj4gWzFdIEknbSBub3QgZ29pbmcgdGhyb3VnaCB0aGUgZWZmb3J0 IG9mIGdhdGhlcmluZyBjaXRhdGlvbnMgaGVyZSwgYXMgSSB3b3VsZCBleHBlY3QgdGhhdCB5b3Us IGFuZCBhbGwgb3RoZXIgaW52b2x2ZWQgcGFydGljaXBhbnRzLCBhcmUgc3VmZmljaWVudGx5IGZh bWlsaWFyIHdpdGggdGhlIG9uZ29pbmcgY29udmVyc2F0aW9uIHRvIG1ha2UgZG9pbmcgc28gdW5u ZWNlc3NhcnkuIElmIHlvdSdkIGxpa2UgdG8gbWFrZSB0aGUgY2xhaW0gc3VjaCBwb3NpdGlvbnMg aGF2ZSAqbm90KiBiZWVuIGFzc2VydGVkIGJ5IHRoZSBwYXJ0aWVzIGluIHF1ZXN0aW9uLCBJJ2xs IGhhcHBpbHkgcG9pbnQgeW91IHRvIGEgdHJvdmUgb2YgcmVsZXZhbnQgZW1haWxzLCBtZWV0aW5n IG1pbnV0ZXMsIHNsaWRlIGRlY2tzLCBhbmQgYXVkaW8gcmVjb3JkaW5ncy4NCj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcnRjd2ViIG1haWxp bmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGN3ZWINCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxp c3QNCnJ0Y3dlYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWINCg== From nobody Sat Dec 6 01:17:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4A11A88EF for ; Sat, 6 Dec 2014 01:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDdTd_l-F5Vb for ; Sat, 6 Dec 2014 01:17:03 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACA141A1A25 for ; Sat, 6 Dec 2014 01:17:02 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so793188wiv.2 for ; Sat, 06 Dec 2014 01:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=t+tStrjzzIj6V7gKNCodridmmjbrsad5MFD7F8jpu0g=; b=wHOK02YEq5OHaRzzBUnwD2AF71VrHmvohKITKOzR1w+FDdxMrKm2zc7Q+WwkkM40gA h5gQvU3w7FzOLwgVBhs2/wgTsbj3Q1SwdZb9W76x2EDmMGH28PVFkIORbjiDitUreTV5 L26wQ5g68XBeWbx5v1Ytuynr3IA/8yxQ0r//Tfml+Q/wuUNdBrLWHUptolCPstmgG+jC Y+8XNXu6h7wnRdzeXQF09uPdbHTXXy5wOKHlyz60BxBKeN1voLFRU30saokosD5ogStX YZ5ZK2BTD5bXxL0uZ4QCKjMbTU2Lt5nH26TxwZSD1YxG8F/LiY1yPOeGA3Cbew8yIsVs Xd4A== X-Received: by 10.181.13.7 with SMTP id eu7mr10437772wid.72.1417857421505; Sat, 06 Dec 2014 01:17:01 -0800 (PST) Received: from ?IPv6:2001:4dd0:ff00:9ac0:4957:db8e:8567:cda4? ([2001:4dd0:ff00:9ac0:4957:db8e:8567:cda4]) by mx.google.com with ESMTPSA id j9sm15939953wjb.38.2014.12.06.01.17.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Dec 2014 01:17:00 -0800 (PST) Message-ID: <5482C98B.7090009@googlemail.com> Date: Sat, 06 Dec 2014 10:16:59 +0100 From: Maik Merten User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54820E74.90201@mozilla.com> In-Reply-To: <54820E74.90201@mozilla.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TGitHQHsHmskHNgnlJKksJHfN5k Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 09:17:04 -0000 Am 05.12.2014 um 20:58 schrieb Jean-Marc Valin: > Considering that: 1) We have committed to an MTI video codec 2) All > consensus calls on "VP8 only" and "H.264 only" have failed 3) This > is the only proposal that gets support from both camps I strongly > support this MTI proposal. +1 Maik From nobody Sat Dec 6 01:39:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963DE1A894A for ; Sat, 6 Dec 2014 01:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxuMBjex0bsP for ; Sat, 6 Dec 2014 01:39:17 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 85A2E1A88EF for ; Sat, 6 Dec 2014 01:39:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 49CF07C0B20 for ; Sat, 6 Dec 2014 10:39:15 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h06M6gGmee0n for ; Sat, 6 Dec 2014 10:39:14 +0100 (CET) Received: from [192.168.1.186] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id D3B5C7C0DDC for ; Sat, 6 Dec 2014 10:38:59 +0100 (CET) Message-ID: <5482CEB3.8030000@alvestrand.no> Date: Sat, 06 Dec 2014 10:38:59 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54820E74.90201@mozilla.com> <548260D2.2020703@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Kenxb4BhtfGTiM4tjlg5TUSK3go Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 09:39:20 -0000 On 12/06/2014 03:23 AM, Andrew Allen wrote: > Adam, > > However if you look at it another way: > > A majority of the market share of the desktop browser market (Microsoft= and Apple) are against this and a significant share of the mobile browse= r market (Apple, Microsoft and BlackBerry) are against this. Please .... if you bring market share into the discussion, tell us which numbers you are using. Clearly you are not using StatCounter: http://gs.statcounter.com/#desktop-browser-ww-monthly-200807-201411 http://gs.statcounter.com/#mobile_browser-ww-monthly-201311-201411 From nobody Sat Dec 6 01:46:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56221A8FD2 for ; Sat, 6 Dec 2014 01:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylzjEb20b1Mp for ; Sat, 6 Dec 2014 01:46:04 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12AD1A8ABB for ; Sat, 6 Dec 2014 01:46:04 -0800 (PST) Received: from panoramix.jmvalin.ca (unknown [107.16.188.53]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 1D5C9F25D4; Sat, 6 Dec 2014 01:46:04 -0800 (PST) Message-ID: <5482D05B.1050407@mozilla.com> Date: Sat, 06 Dec 2014 04:46:03 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Bernard Aboba , David Singer References: <54820E74.90201@mozilla.com> <548260D2.2020703@nostrum.com> <94C89195-99FC-4807-B00B-1A94701C8724@gmail.com> In-Reply-To: <94C89195-99FC-4807-B00B-1A94701C8724@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3xGG12vsbO0RL7I5SjD8NxdqMq0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 09:46:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/12/14 10:31 PM, Bernard Aboba wrote: > [BA] While this does appear to be a statement from an implementer > about support in their own product, it does not correctly > characterize the nature of the "consensus" as a whole. The > "consensus" here did not involve acceptance by RTCWEB implementers > of the necessity for them to support both H.264 and VP8. Had such > a proposal been made it most probably would have failed. Instead > the "consensus" call involved imposing an obligation on a subset > of implementers without their agreement. There is a term for > *that*, but it isn't "consensus" - the 13 colonies called it > "taxation without representation". OK, so it's browsers implementer that matter now? Let's see, the original position from Google and Mozilla -- who represent more than 50% of the market and (AFAIK) 100% of WebRTC browsers -- was originally "VP8 or die". Despite that, the "VP8 or die" option failed the consensus call (as did the "H.264 or die" option). Now, the same implementers are agreeing to make VP8 *and* H.264 MTI, while rallying some of the H.264 supporters (obviously not you) and you're still thinking it's a minority imposing its will on the majority of browser implementers? I'd like to understand what other outcome you're aiming for here: 1) Call for consensus on "H.264 or die" until enough people in the other camp get distracted; 2) No MTI, voice only ought to be good for everyone; or 3) Some other clever compromise we haven't yet heard of Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUgtBYAAoJEJ6/8sItn9q9CLQIAJPZ47KBo/1V3pY3KNWu3B4P OrevkGyXLkaXG9NhxRJ8TsTGP/KK7GMAVArQJW5oYhpvgZ8vmKXfLV8AwjP8THjG geXNbPpX7vW+FIKhzdtlIwG3teF44j9a9jMy4iLKBhV0N0msQUHnBw0aMtO2K7j3 /SFzeCVNRUYxmCa7GnHVztAXE9cOHfwjy4xEYNGcRn9Ds8GqJIJOCDSuuVqa/BJr 3pRdC4s1dsG8h9sxlwy17UDJHzjBHzwnxRLKbhSkLGw2aZJSMwdVMbKh967SQb8m PJpo71d6UWr2bpZqVRMb5JmHV+8zl8oRqBn0K0Hm8A70mrcvLksqeExoD8fFGSk= =u+CB -----END PGP SIGNATURE----- From nobody Sat Dec 6 05:06:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE02D1A9042 for ; Sat, 6 Dec 2014 05:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHdpd1uG2UkB for ; Sat, 6 Dec 2014 05:06:16 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 988151A9041 for ; Sat, 6 Dec 2014 05:06:16 -0800 (PST) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 06 Dec 2014 08:06:11 -0500 Received: from XCT116CNC.rim.net (10.65.161.216) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.210.2; Sat, 6 Dec 2014 08:06:11 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Sat, 6 Dec 2014 08:06:10 -0500 From: Andrew Allen To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEJCKEBti1FXXNkmH1ALOez9gJ5yBvm8AgAA6CwCAACgmAP//s+MwgADPGYD//+B8wA== Date: Sat, 6 Dec 2014 13:06:09 +0000 Message-ID: References: <54820E74.90201@mozilla.com> <548260D2.2020703@nostrum.com> <5482CEB3.8030000@alvestrand.no> In-Reply-To: <5482CEB3.8030000@alvestrand.no> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dHeuP4QSapF-3mzCq7UoZG2BgNE Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 13:06:19 -0000 Harald I already stated my source (which I picked at random based on a google sear= ch :) ) in a previous email and we could argue about the accuracy of the st= atistics on one site or another, the statistical trends, what snapshot wind= ow in time to take, how to measure it (based on website usage or number of = deployed units, etc).=20 But I think my point was clear. Several significant players in the browser = space that are supposed to implement the video MTI "compromise" are not in = support of this "compromise". Easy to get a hum to support both codecs from other people when they aren't= the ones that have to implement both codecs. Andrew -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestran= d Sent: Saturday, December 06, 2014 4:39 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec On 12/06/2014 03:23 AM, Andrew Allen wrote: > Adam, > > However if you look at it another way: > > A majority of the market share of the desktop browser market (Microsoft a= nd Apple) are against this and a significant share of the mobile browser ma= rket (Apple, Microsoft and BlackBerry) are against this. Please .... if you bring market share into the discussion, tell us which nu= mbers you are using. Clearly you are not using StatCounter: http://gs.statcounter.com/#desktop-browser-ww-monthly-200807-201411 http://gs.statcounter.com/#mobile_browser-ww-monthly-201311-201411 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sat Dec 6 06:00:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F561A9044 for ; Sat, 6 Dec 2014 06:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWznEIKu-ctW for ; Sat, 6 Dec 2014 06:00:51 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80541A9040 for ; Sat, 6 Dec 2014 06:00:51 -0800 (PST) Received: from [172.22.19.252] ([12.216.224.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB6E0d82029875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Dec 2014 08:00:42 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [12.216.224.110] claimed to be [172.22.19.252] References: <54820E74.90201@mozilla.com> <548260D2.2020703@nostrum.com> <5482CEB3.8030000@alvestrand.no> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B411) From: Adam Roach Date: Sat, 6 Dec 2014 06:00:34 -0800 To: Andrew Allen Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/47hDMSTGYtBnFi85U5ypZxUVhhU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 14:00:53 -0000 > On Dec 6, 2014, at 05:06, Andrew Allen wrote: >=20 > But I think my point was clear. Several significant players in the browser= space that are supposed to implement the video MTI... Well, there's "supposed to" and then there's "plan to." https://status.modern.ie/?term=3DWebRTC%20v1.0 /a= From nobody Sat Dec 6 09:02:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB51A1A89A1 for ; Sat, 6 Dec 2014 09:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i9MFgkULeDQ for ; Sat, 6 Dec 2014 09:02:28 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F13C1A0183 for ; Sat, 6 Dec 2014 09:02:27 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id hv19so2127603lab.14 for ; Sat, 06 Dec 2014 09:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=0XEwdZFFlg9K8q/uRng1ZUrZr9Xgey+mKR+uWAOpehY=; b=LfY2Wu3ZSUKjC+816okX6/Pi88pJ0u+kemxzravIJjxeRSeXaz2VNZ/mCSKMowBQ0m 1zTnlLif4b59vc/CPQBkwSV0w/T1waTYv7x9Twx+TkqiKbv4S+dzBwrK7ohyf5XE376P GSDASgY8biAhqznU85B/X2qu69ZHtl9wNZ34fztVw3Two7nRcyyaCPdQgMxvia9fagKb e8I8wTW5nI9qiGWMUOaSnA6Oni1PVoid8xS0SWhJRwabLbGaV2wvcqQXlHCD3MTlYNUi wSjBtL2RnQ7FF2XpHeQzhRUhA8pFw7RYWMNl6lW8ww21gZtZ4ie3JkNOVnoWgsOXygps eTtA== MIME-Version: 1.0 X-Received: by 10.112.132.2 with SMTP id oq2mr8324622lbb.11.1417885346436; Sat, 06 Dec 2014 09:02:26 -0800 (PST) Received: by 10.112.25.5 with HTTP; Sat, 6 Dec 2014 09:02:26 -0800 (PST) Received: by 10.112.25.5 with HTTP; Sat, 6 Dec 2014 09:02:26 -0800 (PST) In-Reply-To: <5481672E.4080305@alvestrand.no> References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> <5481672E.4080305@alvestrand.no> Date: Sat, 6 Dec 2014 19:02:26 +0200 Message-ID: From: Varun Singh To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=047d7b3a823a681c8a05098f282f Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7o8kRNN2WHv01K9d8NtNvawFjPk Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 17:02:31 -0000 --047d7b3a823a681c8a05098f282f Content-Type: text/plain; charset=UTF-8 A) Yes, I have read the draft and I support adopting it. Varun. On 5 Dec 2014 10:05, "Harald Alvestrand" wrote: > Just to get the ball rolling: > > A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG > document now. > > On 12/04/2014 08:29 PM, Cullen Jennings (fluffy) wrote: > >> Having reviewed the fine technical comments on this draft since we asked >> for comments, the chairs have noted that multiple people seem to have read >> the draft. Given this great news we are going make a call for adoption. >> >> If you have an opinion, please email the list by Dec 19 and let us know >> if you either: >> >> A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG >> document now >> >> B) no, not right now >> >> If we get consensus around A we will work with ADs on milestone. >> Otherwise we will encourage the authors to keep working on this draft and >> continue using this email list. We may adopt it later or include the text >> in other drafts. >> >> Thanks, >> The Chairs (Cullen, Sean, Ted) >> >> PS - if you want to send an email that says more than A or B, feel free >> to change the subject, start a new thread etc. >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 > --047d7b3a823a681c8a05098f282f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

A) Yes, I have read the draft and I support adopting it.

Varun.

On 5 Dec 2014 10:05, "Harald Alvestrand&quo= t; <harald@alvestrand.no>= wrote:
Just to get = the ball rolling:

A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG d= ocument now.

On 12/04/2014 08:29 PM, Cullen Jennings (fluffy) wrote:
Having reviewed the fine technical comments on this draft since we asked fo= r comments, the chairs have noted that multiple people seem to have read th= e draft. Given this great news we are going make a call for adoption.

If you have an opinion, please email the list by Dec 19 and let us know if = you either:

A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG d= ocument now

B) no, not right now

If we get consensus around A we will work with ADs on milestone. Otherwise = we will encourage the authors to keep working on this draft and continue us= ing this email list. We may adopt it later or include the text in other dra= fts.

Thanks,
The Chairs (Cullen, Sean, Ted)

PS - if you want to send an email that says more than A or B, feel free to = change the subject, start a new thread etc.








_______________________________________________
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
--047d7b3a823a681c8a05098f282f-- From nobody Sat Dec 6 13:30:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABD41A026A for ; Sat, 6 Dec 2014 13:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlbuwDvwf5MQ for ; Sat, 6 Dec 2014 13:30:06 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A171A0172 for ; Sat, 6 Dec 2014 13:30:06 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB6LU3aQ070190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Dec 2014 15:30:04 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <5483755A.4070806@nostrum.com> Date: Sat, 06 Dec 2014 15:30:02 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: David Singer References: <54820E74.90201@mozilla.com> <548260D2.2020703@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/T1BahfgFuuSAc-lmU_5D2YOeZLM Cc: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 06 Dec 2014 21:30:08 -0000 On 12/5/14 17:58, David Singer wrote: >> On Dec 5, 2014, at 17:50 , Adam Roach wrote: >> >> On 12/5/14 15:26, David Singer wrote: >>>> On Dec 5, 2014, at 11:58 , Jean-Marc Valin wrote: >>>> 3) This is the only proposal that gets support from both camps >>> if you could speak only for yourself, and not others, that might be better. You’re claiming support by other people here. >>> >> If I read Jean-Marc's statement correctly, it's not speaking on behalf of other people; it's using what they have already said, on the record [1], as a valid part of his rationale. >> >> I'd like to reinforce this sentiment. I support this proposal not because I think it is the best solution, but because it is the first MTI video codec proposal that the actual implementors in this technology space have even remotely agreed on since the discussion began. I support this proposal primarily because it is the only solution we have yet seen that has a credible chance of succeeding. > OK, we are potential implementor, and so are Blackberry, and we don’t agree. That's been taken into account. As Keith so helpfully pointed out, what was reached in the room was *rough* consensus, and you've made it abundantly clear that you're part of the rough. As *you* pointed out in the other active video-related thread, one generally "wouldn’t be here if [one] hadn’t chosen to implement," and it was sufficiently clear that people who "were here" in Hawaii thought that pursuing this plan was better than not. Lest you think I'm putting words in anyone's mouth when I say that, I cite the chairs' declaration on the topic rather than claiming my subjective evaluation of the room's sense (which would involve several more adjectives than my rather subdued statement here). Keep in mind that this is all being said in the context of making a point about why I support this course of action (because I think it has a good chance of success), so don't read more than that into it. > You seem to hypothesize two camps only and that this has support of both. I'm actually not claiming that it's as simple as two camps; however, I think it's pretty fair to say that the participants have historically held positions that could be broadly characterized as "pro-VP8" and "pro-H.264." My claim is that a non-trivial number of people who have historically supported one of those positions to the exclusion of the other have expressed a willingness to go along with this plan. > You are therefore trying to claim a state of consensus which does not exist. There was pushback both in the room and on the list. Rough consensus is not the lack of push-back. The IETF would specify approximately nothing if all decisions required unanimity. In terms of the rough accord I'm citing as part of my rationale, I'm far more inclined to consider the working group chairs' declaration about the sense of the room to be a valid indicator of the positions of interested parties than I would yours or even my own. /a From nobody Sat Dec 6 17:42:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88731A6F6D for ; Sat, 6 Dec 2014 17:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igsRjCiutn7M for ; Sat, 6 Dec 2014 17:41:57 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40CE1A6F62 for ; Sat, 6 Dec 2014 17:41:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417916517; x=2281830117; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WdHkHlVrs5EXSDFHrfbk6yNOxfEI4XU0nNjzB/tfgZo=; b=S1VhoNpRhYbVpnzw63f1UqSeqV5fvIv7Cuclmeei4TRZgaz7p5Q7RFtYl/tENgKv OAy7lyE0U/8LqoMc9hgRMpp68eN2n2VEoWhG0ULT1iQdAVWQVOAGU6oT7QXQhFT3 pE1wVIS2YZ6Rn+GDbEvCvQQfOjYjsl3GKZM3rXcD8Ue5a/eykGRYE0VEHDoapsBY wHBHmFWw0725cdnH0j3oYU9Rof+rEKKYR9UHxFP5moXZQIa5n+irPijz2Q/dZYhu Bo/tqC6E9hVGL1fMVyafKDm3fs3wVIOnnbsu1Wu86oL605CTYY4URRbekK6zBOb4 iXq0gnSKNCGeS8mPtOmlDw==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 9C.08.09658.560B3845; Sat, 6 Dec 2014 17:41:57 -0800 (PST) X-AuditID: 11973e16-f79aa6d0000025ba-50-5483b065163c Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 92.9E.05998.670B3845; Sat, 6 Dec 2014 17:42:14 -0800 (PST) Received: from [17.153.102.23] (unknown [17.153.102.23]) by cilantro.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG600AI7VDWV640@cilantro.apple.com> for rtcweb@ietf.org; Sat, 06 Dec 2014 17:41:57 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <5483755A.4070806@nostrum.com> Date: Sat, 06 Dec 2014 17:41:56 -0800 Content-transfer-encoding: quoted-printable Message-id: <68056FA8-8B28-41E5-815A-A1BAA048F190@apple.com> References: <54820E74.90201@mozilla.com> <548260D2.2020703@nostrum.com> <5483755A.4070806@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUi2FAYrpu6oTnE4Ow2EYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0bpjB1vBNLaKr7f8Ghh/sHQxcnBICJhI/Dnj08XICWSKSVy4 t56ti5GLQ0hgL6PEzsVr4WpOL1WDiE9kkvh6bwdU0WQmif/zHrOBFDELqEtMmZILMohXQE+i 6cljJpCwsICtxNbrQSBhNgFViQdzjjGC2JwC2hI3Zy4As1mA4q8mz2AGsZkFrCT+nn7CCGFr Szx5d4EVYqSNxLZFh1gg1v5jlDhw+i4bSEJEQFGi7fBNZogHZCX+XTzDDlIkIfCRVWL7myam CYzCsxDOm4XkvFlIdixgZF7FKJSbmJmjm5lnrpdYUJCTqpecn7uJERTA0+3EdjA+XGV1iFGA g1GJh7ejuClEiDWxrLgy9xCjNAeLkjhvsj1QSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+MG rUjzea7R//I4bTwnV81QTtsyUY2hQkgqyn9mn9rs8Nc/tm/fqGv73fMRu++GC8yMfI8+8IY4 vHbbHCH9dO7p1y+Mpl819zxz7uCnRI6s3QY9d4svry8wbGdLi4pbs+vw1V1ql67JeW6blyXT 9uNM4SGJgkvND5lCm4wmZ25y4zLv9H+71UGJpTgj0VCLuag4EQD/CqqrQQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUi2FAspFu2oTnE4PMiAYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0bpjB1vBNLaKr7f8Ghh/sHQxcnBICJhInF6q1sXICWSKSVy4 t56ti5GLQ0hgIpPE13s7oJzJTBL/5z1mA2lgFlCXmDIlF6SBV0BPounJYyaQsLCArcTW60Eg YTYBVYkHc44xgticAtoSN2cuALNZgOKvJs9gBrGZBawk/p5+wghha0s8eXeBFWKkjcS2RYdY INb+Y5Q4cPouG0hCREBRou3wTWaIQ2Ul/l08wz6BUWAWwkWzkFw0C8nYBYzMqxgFilJzEitN 9BILCnJS9ZLzczcxgkOuMHwH479lVocYBTgYlXh4O4ubQoRYE8uKK3MPMUpwMCuJ8K4Ubg4R 4k1JrKxKLcqPLyrNSS0+xCjNwaIkztv8rjFESCA9sSQ1OzW1ILUIJsvEwSnVwKh96a/p332z lvoYpq3LuSIVlqH8iquh46ZC47eYXvv2zvXBTy0d2Pg+fal7wcq5/MzE7f+3rPCxP6e5xjZr TVZTk2m2vvadT0LWjH6Tk5gZ/p7+HVJ1jDNuLv9T+6cfHk9S4jBObjm6cHNn58eFqZqKTYe/ MWwN4WS9eu1etVYn/7LX+2/uMlBiKc5INNRiLipOBACcYUcKNQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DlvapsQvHdhOp9r5rqrH0RY_ctA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 07 Dec 2014 01:41:59 -0000 Adam we are at cross purposes. I am complaining about a language usage. = When you say =E2=80=9Cboth camps support=E2=80=9D you imply (a) that = there are only two camps, and everyone is a member of one or other and = (b) that they have reached agreement =E2=80=94 and therefore we are = done. Perhaps you don=E2=80=99t mean it, but it=E2=80=99s a technique = some people use to try to give the appearance of an agreement, and given = the sensitive nature of the subject, I=E2=80=99d prefer you not do that. If you say =E2=80=9Cthere was support for the position from several = camps=E2=80=9D, or somesuch, that would be fine. That leaves room for = people to say that they dissent, that=E2=80=99s all. Got it? David Singer Manager, Software Standards, Apple Inc. From nobody Sat Dec 6 18:14:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCF31A6FE5 for ; Sat, 6 Dec 2014 18:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjFppFHVFDdk for ; Sat, 6 Dec 2014 18:14:51 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091421A6FE0 for ; Sat, 6 Dec 2014 18:14:51 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id rd18so2822941iec.22 for ; Sat, 06 Dec 2014 18:14:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=I8M5UUpQFnYNaLf+cA3bZQsK1ChdmQjxdux6TJMKD/o=; b=GIafZi/NAwT36OVPyxTPVXNOqIIAXa1X9EfCbG9lGvOo1/pp8wcuLBMfNxTb5tOdUh 7RoW+gkF1rvXTue8688IP9cXn0D3luFKwyBBS+fuEUj6I78nU8rmOwTOZOpQZhCJqa2W Qfw2d32R/lvcsECu+BMZ7rsFFNMVOFuQWBboMA591fOVh8aofFtcG1GtRcFYawRoOzHU IoQJn/lHQVfFZam0hjtT0cz33M+jfBVJNnjFPJxsMXoMBt+bCo/+kl4tPaSYbtaAqNTW J0pZk7PQMa2zMMLSe/wMFOdok4sFWa1zh6OnxVsVEUrThzkoKjCjWE/vNI/1x4wb31Z0 z+DA== X-Gm-Message-State: ALoCoQnxqNpm0gi/KRWUJddPJ4DnKY8fBgPuiTDAdEvACt1+spvTcePGrv1ugUH6AYPaSh06LLq/ X-Received: by 10.50.12.97 with SMTP id x1mr9157876igb.48.1417918490446; Sat, 06 Dec 2014 18:14:50 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id 73sm9169958ioz.30.2014.12.06.18.14.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Dec 2014 18:14:49 -0800 (PST) Message-ID: <5483B818.7050102@andyet.net> Date: Sat, 06 Dec 2014 19:14:48 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adam Roach , Ron , rtcweb@ietf.org References: <547511DB.5050100@nostrum.com> <547FC4FD.2050300@andyet.net> <20141204150041.GI10449@hex.shelbyville.oz> <54808198.7030207@andyet.net> <54808719.10402@nostrum.com> In-Reply-To: <54808719.10402@nostrum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8FTyncTlHEObnJr5gEtLY0ihyXM Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 07 Dec 2014 02:14:53 -0000 On 12/4/14, 9:08 AM, Adam Roach wrote: > On 12/4/14 07:45, Peter Saint-Andre - &yet wrote: >> On 12/4/14, 8:00 AM, Ron wrote: >>> >>> On Wed, Dec 03, 2014 at 07:20:45PM -0700, Peter Saint-Andre - &yet >>> wrote: >>>> >>>> IMHO we need to either pull out the future-oriented text entirely >>>> (which has >>>> its own problems) or significantly improve it. I would be happy to >>>> propose >>>> text for the latter. >>> >>> I'd definitely be interested in seeing proposals from you to improve >>> upon these things. It seemed premature to explore this until we had >>> some sense of whether this kind of compromise could fly at all, but >>> now that it seems it can, I think these are important details for us >>> to clarify as best we can. >> >> OK, I'll get to work. :-) > > Awesome, thanks. I've always found your prose to be clearer and easier > to read than mine anyway. :) > > When you draft your text, keep in mind that what we're trying to do is > capture the essence of the agreement that we've formed a critical mass > around. The less formal (i.e., not really document-ready) version of > this is: > >> "WebRTC devices MUST implement both VP8 and H.264. If compelling >> evidence arises that one of the codecs is available for use on a >> royalty-free basis, such as all IPR declarations known for the codec >> being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change >> this normative statement to indicate that only that codec is required. >> For absolute, crystal clarity, this provision is only applicable to >> WebRTC devices, and not to WebRTC User Agents." > > There's nuance to be added there, for sure, but I'd encourage you not to > color way outside those lines. Expanding scope to discuss issues such as > *other* circumstances that may cause revisiting the MTI, for example, > are far more likely to weaken consensus than they are to strengthen it. I see two kinds of triggers: 1. A trigger that is specific to the alternatives we have been presented so far. That is: only H.264 or VP8 (or both) can be MTI. If we learn that one of them can be used royalty-free, then that codec will be the only MTI codec. Questions: 1a. Does this trigger fire as soon as one codec is learned to be usable royalty-free? So this is a first-past-the-post contest? (Let's say codec "c1" is learned to be usable RF and the next week or month or quarter "c2" is learned to be usable RF. What happens?) 1b. Text along the lines of "the IETF will change this normative statement" does not make it clear how that will happen. Is there an automatic trigger (i.e., it's built into this document)? Or does the IETF need to do something (e.g., publish an RFC that obsoletes this one)? (There is some interaction between 1a and 1b. If some process is needed to declare "c1" the only MTI, then it's possible that we might learn that "c2" can also be used RF before the obsoleting RFC can be published.) 2. A trigger that is more general and future-proof. That is: someday (perhaps before too much longer on the standardization timescale) we will have other alternatives to consider: H.265, VP9, VP10, Daala, and who knows what. Another question: 2a. There is some interaction between 1b and 2. Let's say it takes us 10 years to learn that "c1" can be used RF. Hurray! But by that time, we might have "c3" and "c4" and "c5" to consider. Are we forbidden from considering anything but "c1" and "c2" at that time? I *think* that the trigger you're talking about is #1. Personally I am much more interested in #2 because I don't think we'll really settle this issue in the medium term or long term until we have the video equivalent of Opus. Because I think we're talking about different triggers for different purposes, my impression is that the text we have in mind would differ significantly (in particular, I feel no compulsion to "stay within the lines" because I think those lines are not useful, and indeed are positively harmful, in the long term). Peter -- Peter Saint-Andre CTO @ &yet https://andyet.com/ From nobody Sat Dec 6 19:17:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7461A802A for ; Sat, 6 Dec 2014 19:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNrufXg48RPJ for ; Sat, 6 Dec 2014 19:17:54 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA011A7D85 for ; Sat, 6 Dec 2014 19:17:53 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB73HpWF011320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Dec 2014 21:17:52 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <5483C6DE.80708@nostrum.com> Date: Sat, 06 Dec 2014 21:17:50 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: David Singer References: <54820E74.90201@mozilla.com> <548260D2.2020703@nostrum.com> <5483755A.4070806@nostrum.com> <68056FA8-8B28-41E5-815A-A1BAA048F190@apple.com> In-Reply-To: <68056FA8-8B28-41E5-815A-A1BAA048F190@apple.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_HO-QJ5-Lw83itt-Uvim3PzON0Q Cc: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 07 Dec 2014 03:17:55 -0000 On 12/6/14 19:41, David Singer wrote: > Adam > > we are at cross purposes. I am complaining about a language usage. When you say “both camps support†you imply (a) that there are only two camps, and everyone is a member of one or other and (b) that they have reached agreement — and therefore we are done. Perhaps you don’t mean it, but it’s a technique some people use to try to give the appearance of an agreement, and given the sensitive nature of the subject, I’d prefer you not do that. > > If you say “there was support for the position from several campsâ€, or somesuch, that would be fine. That leaves room for people to say that they dissent, that’s all. > > Got it? Is this the colloquial use of the word "you" to mean "one"? As in "when one says 'both camps support'"? Or are you making a claim that *I* used the phrase "both camps support" or something equivalent? I think if you go looking for something you could quote directly, anything that I've said on the topic is far more nuanced than that. But I suspect you already know that, since you oddly chose not to quote me at all: it's easier to apply a strawman logical fallacy to parody my position if you don't provide contrary evidence at the same time. /a From nobody Sat Dec 6 20:21:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E1E1A8547 for ; Sat, 6 Dec 2014 20:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thiOddEMNv75 for ; Sat, 6 Dec 2014 20:21:00 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC0F1A1BD2 for ; Sat, 6 Dec 2014 20:20:59 -0800 (PST) Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail07.adl2.internode.on.net with ESMTP; 07 Dec 2014 14:50:57 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 1B7B5FFE57; Sun, 7 Dec 2014 14:50:45 +1030 (CST) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VY13ha-c1Dih; Sun, 7 Dec 2014 14:50:41 +1030 (CST) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id AEABCFF906; Sun, 7 Dec 2014 14:50:41 +1030 (CST) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 9BF4680470; Sun, 7 Dec 2014 14:50:41 +1030 (ACDT) Date: Sun, 7 Dec 2014 14:50:41 +1030 From: Ron To: Peter Saint-Andre - &yet Message-ID: <20141207042041.GC19538@hex.shelbyville.oz> References: <547511DB.5050100@nostrum.com> <547FC4FD.2050300@andyet.net> <20141204150041.GI10449@hex.shelbyville.oz> <54808198.7030207@andyet.net> <54808719.10402@nostrum.com> <5483B818.7050102@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5483B818.7050102@andyet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ev6a0KC8WcOSttJOCuN1dOXyTM4 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 07 Dec 2014 04:21:04 -0000 On Sat, Dec 06, 2014 at 07:14:48PM -0700, Peter Saint-Andre - &yet wrote: > On 12/4/14, 9:08 AM, Adam Roach wrote: > >On 12/4/14 07:45, Peter Saint-Andre - &yet wrote: > >>On 12/4/14, 8:00 AM, Ron wrote: > >>> > >>>On Wed, Dec 03, 2014 at 07:20:45PM -0700, Peter Saint-Andre - &yet > >>>wrote: > >>>> > >>>>IMHO we need to either pull out the future-oriented text entirely > >>>>(which has > >>>>its own problems) or significantly improve it. I would be happy to > >>>>propose > >>>>text for the latter. > >>> > >>>I'd definitely be interested in seeing proposals from you to improve > >>>upon these things. It seemed premature to explore this until we had > >>>some sense of whether this kind of compromise could fly at all, but > >>>now that it seems it can, I think these are important details for us > >>>to clarify as best we can. > >> > >>OK, I'll get to work. :-) > > > >Awesome, thanks. I've always found your prose to be clearer and easier > >to read than mine anyway. :) > > > >When you draft your text, keep in mind that what we're trying to do is > >capture the essence of the agreement that we've formed a critical mass > >around. The less formal (i.e., not really document-ready) version of > >this is: > > > >>"WebRTC devices MUST implement both VP8 and H.264. If compelling > >>evidence arises that one of the codecs is available for use on a > >>royalty-free basis, such as all IPR declarations known for the codec > >>being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change > >>this normative statement to indicate that only that codec is required. > >>For absolute, crystal clarity, this provision is only applicable to > >>WebRTC devices, and not to WebRTC User Agents." > > > >There's nuance to be added there, for sure, but I'd encourage you not to > >color way outside those lines. Expanding scope to discuss issues such as > >*other* circumstances that may cause revisiting the MTI, for example, > >are far more likely to weaken consensus than they are to strengthen it. > > I see two kinds of triggers: > > 1. A trigger that is specific to the alternatives we have been presented so > far. That is: only H.264 or VP8 (or both) can be MTI. If we learn that one > of them can be used royalty-free, then that codec will be the only MTI > codec. > > Questions: > > 1a. Does this trigger fire as soon as one codec is learned to be usable > royalty-free? So this is a first-past-the-post contest? (Let's say codec > "c1" is learned to be usable RF and the next week or month or quarter "c2" > is learned to be usable RF. What happens?) This question was briefly picked at here: http://www.ietf.org/mail-archive/web/rtcweb/current/msg13506.html > 1b. Text along the lines of "the IETF will change this normative statement" > does not make it clear how that will happen. Is there an automatic trigger > (i.e., it's built into this document)? Or does the IETF need to do something > (e.g., publish an RFC that obsoletes this one)? > > (There is some interaction between 1a and 1b. If some process is needed to > declare "c1" the only MTI, then it's possible that we might learn that "c2" > can also be used RF before the obsoleting RFC can be published.) My impression was that this trigger is basically only relevant up until the point where we actually publish an RFC specifying MTI video. Since after that it's essentially set in stone unless or until we publish some superseding RFC. There were one or two voices pushing for whatever decision we make now to somehow irrevocably bind all future decisions, but personally I think that is pure nonsense, we couldn't do that even if we wanted to. Any future RFC can say anything it likes, whether made by this same group or any other. If the facts on the ground change after we've published, sufficiently for us to want to do something else, then I assume that something else will need to run the gauntlet of IETF consensus again the same way as any proposal normally would. If I'm wrong about any of that, I'm happy to rethink my assumptions, but that's the datum I've been surveying things from. > 2. A trigger that is more general and future-proof. That is: someday > (perhaps before too much longer on the standardization timescale) we will > have other alternatives to consider: H.265, VP9, VP10, Daala, and who knows > what. > > Another question: > > 2a. There is some interaction between 1b and 2. Let's say it takes us 10 > years to learn that "c1" can be used RF. Hurray! But by that time, we might > have "c3" and "c4" and "c5" to consider. Are we forbidden from considering > anything but "c1" and "c2" at that time? > > I *think* that the trigger you're talking about is #1. Personally I am much > more interested in #2 because I don't think we'll really settle this issue > in the medium term or long term until we have the video equivalent of Opus. I think this is where the hopes of most of the people who have been facepalming at the idea of H.264 even being considered here, except as some sort of sick in-joke, have moved to now. With this compromise essentially just being a way to avoid the work of this group collapsing completely before the IETF can do for video what it did for audio with Opus. What should happen with this standard once it does, is much less clear to me at this point in time. The obvious first step Ted reiterated again most recently here: http://www.ietf.org/mail-archive/web/rtcweb/current/msg13722.html "Note as well that I, personally, have never advocated for having a single codec available to an app or a browser; the methods for negotiating are a key part of this infrastructure, and they will be key to it moving forward as things progress. We worked toward a mandatory-to-implement to avoid interoperability failure." So things which support a new codec will be able to negotiate it as soon as it is available, as an essential part of this spec. Whether we'll want to revisit making one or more of them MTI, and/or dropping one or more of the existing MTI choices, seems like something we can't really answer yet. I do hope we'll have an IETF working group for video codec work soon, how long before it completes that work and publishes is an open question and how long after that happens before it reaches World Domination is another. Where RTCWEB will be at that time, I'm not sure anyone has a sufficiently powerful crystal ball to really say. (I mean, who would have guessed that after all these years people are still dorking about trying to *finish* HTML :) I completely agree that this is the really interesting question now, and it was one of the reasons some of us put forward the idea of having H.261 as the MTI (if you're going to be stuck with a legacy MTI forever it might as well be something lightweight) but that idea didn't really get to critical mass either. At this stage, I think we basically can only look at what options we have and what facts we know up until the point where the video MTI question goes to WGLC for publication of the RFC specifying it. What happens after that is basically a clean slate again. We can't be constrained "normatively" by any previous decision, and it would be stupid to want to be, since it's far more likely that things we don't expect will change what we have to work with than things which we do. (We might wake up tomorrow to find some company announcing that it has essential patents on H.264 that it is refusing to licence, which could change things we haven't specified actions for here too but that might still spur us to action anyway) All we can really do is work toward the world that we really want to have, and make future decisions based on how successful we were at that in the future. I don't think anything we are talking about here can or does rule out any of the interesting possibilities you're seeing for the 'trigger 2' case though. > Because I think we're talking about different triggers for different > purposes, my impression is that the text we have in mind would differ > significantly (in particular, I feel no compulsion to "stay within the > lines" because I think those lines are not useful, and indeed are positively > harmful, in the long term). Unless I'm still missing (or wrong about) something, the worst case I can see us painting ourselves into for the future is some people might need to support whatever lands as MTI in this first iteration for a bit longer than they otherwise would. That Cisco folk wanted to kill H.261 (which their devices already support) rather than make it MTI here, seems to confirm that whatever lines we draw here today, aren't really going to bind us forever. If something we pick today becomes more harmful than good in the future I don't think people are going to feel bound to keeping it. Video codecs are still far from being a Solved Problem, and I suspect "both camps" can probably agree with the above. If for no other reason than the people who preferred VP8 are going to see better RF alternative emerge, and the people who preferred H.264 are going to have the patents that they hold expire eventually. I don't mind if we explicitly say something to that effect, but it's not clear to me that we need to for it to actually be in effect anyway. Cheers, Ron From nobody Sun Dec 7 00:58:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B881A1ACC for ; Sun, 7 Dec 2014 00:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCZRl1fuafc7 for ; Sun, 7 Dec 2014 00:58:15 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 81F3E1A1ABE for ; Sun, 7 Dec 2014 00:58:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C06487C0958 for ; Sun, 7 Dec 2014 09:58:12 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_urKwVtbZ2g for ; Sun, 7 Dec 2014 09:58:11 +0100 (CET) Received: from [192.168.1.186] (unknown [188.113.88.47]) by mork.alvestrand.no (Postfix) with ESMTPSA id 75FE77C06BC for ; Sun, 7 Dec 2014 09:58:11 +0100 (CET) Message-ID: <548416A2.2010302@alvestrand.no> Date: Sun, 07 Dec 2014 09:58:10 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <547511DB.5050100@nostrum.com> <547FC4FD.2050300@andyet.net> <20141204150041.GI10449@hex.shelbyville.oz> <54808198.7030207@andyet.net> <54808719.10402@nostrum.com> <5483B818.7050102@andyet.net> In-Reply-To: <5483B818.7050102@andyet.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_7J0ZJMESfdE-nyrAFij8mKEYnk Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 07 Dec 2014 08:58:18 -0000 Personal opinions.... On 12/07/2014 03:14 AM, Peter Saint-Andre - &yet wrote: > On 12/4/14, 9:08 AM, Adam Roach wrote: >> On 12/4/14 07:45, Peter Saint-Andre - &yet wrote: >>> On 12/4/14, 8:00 AM, Ron wrote: >>>> >>>> On Wed, Dec 03, 2014 at 07:20:45PM -0700, Peter Saint-Andre - &yet >>>> wrote: >>>>> >>>>> IMHO we need to either pull out the future-oriented text entirely >>>>> (which has >>>>> its own problems) or significantly improve it. I would be happy to >>>>> propose >>>>> text for the latter. >>>> >>>> I'd definitely be interested in seeing proposals from you to improve= >>>> upon these things. It seemed premature to explore this until we had= >>>> some sense of whether this kind of compromise could fly at all, but >>>> now that it seems it can, I think these are important details for us= >>>> to clarify as best we can. >>> >>> OK, I'll get to work. :-) >> >> Awesome, thanks. I've always found your prose to be clearer and easier= >> to read than mine anyway. :) >> >> When you draft your text, keep in mind that what we're trying to do is= >> capture the essence of the agreement that we've formed a critical mass= >> around. The less formal (i.e., not really document-ready) version of >> this is: >> >>> "WebRTC devices MUST implement both VP8 and H.264. If compelling >>> evidence arises that one of the codecs is available for use on a >>> royalty-free basis, such as all IPR declarations known for the codec >>> being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change >>> this normative statement to indicate that only that codec is required= =2E >>> For absolute, crystal clarity, this provision is only applicable to >>> WebRTC devices, and not to WebRTC User Agents." >> >> There's nuance to be added there, for sure, but I'd encourage you not = to >> color way outside those lines. Expanding scope to discuss issues such = as >> *other* circumstances that may cause revisiting the MTI, for example, >> are far more likely to weaken consensus than they are to strengthen it= =2E > > I see two kinds of triggers: > > 1. A trigger that is specific to the alternatives we have been > presented so far. That is: only H.264 or VP8 (or both) can be MTI. If > we learn that one of them can be used royalty-free, then that codec > will be the only MTI codec. > > Questions: > > 1a. Does this trigger fire as soon as one codec is learned to be > usable royalty-free? So this is a first-past-the-post contest? (Let's > say codec "c1" is learned to be usable RF and the next week or month > or quarter "c2" is learned to be usable RF. What happens?) I think it was Adam who said "that's a problem I'd love to have"....... > > 1b. Text along the lines of "the IETF will change this normative > statement" does not make it clear how that will happen. Is there an > automatic trigger (i.e., it's built into this document)? Or does the > IETF need to do something (e.g., publish an RFC that obsoletes this one= )? When drafting this statement, it became abundantly clear that we couldn't make a mechanistic trigger. Some human would have to decide that the trigger conditions had been achieved. So the IETF needs to do something - at minimum, a declaration by somebody that the trigger conditions were achieved. Publishing a new RFC obsoleting -video- would also be appropriate. > > (There is some interaction between 1a and 1b. If some process is > needed to declare "c1" the only MTI, then it's possible that we might > learn that "c2" can also be used RF before the obsoleting RFC can be > published.) > > 2. A trigger that is more general and future-proof. That is: someday > (perhaps before too much longer on the standardization timescale) we > will have other alternatives to consider: H.265, VP9, VP10, Daala, and > who knows what. > > Another question: > > 2a. There is some interaction between 1b and 2. Let's say it takes us > 10 years to learn that "c1" can be used RF. Hurray! But by that time, > we might have "c3" and "c4" and "c5" to consider. Are we forbidden > from considering anything but "c1" and "c2" at that time? There are two variants of "consider c3 and c4 and c5": One is adding c3/4/5 to the MTI set; the other one is removing c1/2 from the MTI set and putting c3/4/5 into the MTI set instead. The tendency for new codecs is that they are more complex than the old ones. So the savings (in code lines or square millimeters of silicon) of removing a codec from the MTI set is perhaps not so great. My personal opinion is that removing things from the MTI set only makes sense if it makes an IPR difference. > > I *think* that the trigger you're talking about is #1. Personally I am > much more interested in #2 because I don't think we'll really settle > this issue in the medium term or long term until we have the video > equivalent of Opus. > > Because I think we're talking about different triggers for different > purposes, my impression is that the text we have in mind would differ > significantly (in particular, I feel no compulsion to "stay within the > lines" because I think those lines are not useful, and indeed are > positively harmful, in the long term). > > Peter > --=20 Surveillance is pervasive. Go Dark. From nobody Sun Dec 7 01:09:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC151A1B6D for ; Sun, 7 Dec 2014 01:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihPV41tsKiR2 for ; Sun, 7 Dec 2014 01:09:07 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1DA1A1ACC for ; Sun, 7 Dec 2014 01:09:07 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 2A95132E554; Sun, 7 Dec 2014 18:08:22 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 39cc_35ac_779a8722_e018_418f_b04d_3b5482f0acce; Sun, 07 Dec 2014 18:08:21 +0900 Received: from [133.2.249.139] (unknown [133.2.249.139]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 446B6BF511; Sun, 7 Dec 2014 18:08:21 +0900 (JST) Message-ID: <54841903.2050208@it.aoyama.ac.jp> Date: Sun, 07 Dec 2014 18:08:19 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , Adam Roach , Ron , rtcweb@ietf.org References: <547511DB.5050100@nostrum.com> <547FC4FD.2050300@andyet.net> <20141204150041.GI10449@hex.shelbyville.oz> <54808198.7030207@andyet.net> <54808719.10402@nostrum.com> <5483B818.7050102@andyet.net> In-Reply-To: <5483B818.7050102@andyet.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sDYzuWvjle7gyIQBGDvRZ1MgDNc Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 07 Dec 2014 09:09:09 -0000 Hello Peter, I agree with Ron and Harald that the details are difficult if not impossible to nail down. I see this as a broad statement of intent, with two purposes: 1) encourage better license conditions from those who have the power to make that happen, and 2) let the world know most of us (maybe even everybody?) would prefer to have only one MTI codec, RF and otherwise unencumbered of course. The rest can only be decided in the future, not now. Regards, Martin. On 2014/12/07 11:14, Peter Saint-Andre - &yet wrote: > On 12/4/14, 9:08 AM, Adam Roach wrote: >> On 12/4/14 07:45, Peter Saint-Andre - &yet wrote: >>> On 12/4/14, 8:00 AM, Ron wrote: >>>> >>>> On Wed, Dec 03, 2014 at 07:20:45PM -0700, Peter Saint-Andre - &yet >>>> wrote: >>>>> >>>>> IMHO we need to either pull out the future-oriented text entirely >>>>> (which has >>>>> its own problems) or significantly improve it. I would be happy to >>>>> propose >>>>> text for the latter. >>>> >>>> I'd definitely be interested in seeing proposals from you to improve >>>> upon these things. It seemed premature to explore this until we had >>>> some sense of whether this kind of compromise could fly at all, but >>>> now that it seems it can, I think these are important details for us >>>> to clarify as best we can. >>> >>> OK, I'll get to work. :-) >> >> Awesome, thanks. I've always found your prose to be clearer and easier >> to read than mine anyway. :) >> >> When you draft your text, keep in mind that what we're trying to do is >> capture the essence of the agreement that we've formed a critical mass >> around. The less formal (i.e., not really document-ready) version of >> this is: >> >>> "WebRTC devices MUST implement both VP8 and H.264. If compelling >>> evidence arises that one of the codecs is available for use on a >>> royalty-free basis, such as all IPR declarations known for the codec >>> being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change >>> this normative statement to indicate that only that codec is required. >>> For absolute, crystal clarity, this provision is only applicable to >>> WebRTC devices, and not to WebRTC User Agents." >> >> There's nuance to be added there, for sure, but I'd encourage you not to >> color way outside those lines. Expanding scope to discuss issues such as >> *other* circumstances that may cause revisiting the MTI, for example, >> are far more likely to weaken consensus than they are to strengthen it. > > I see two kinds of triggers: > > 1. A trigger that is specific to the alternatives we have been presented > so far. That is: only H.264 or VP8 (or both) can be MTI. If we learn > that one of them can be used royalty-free, then that codec will be the > only MTI codec. > > Questions: > > 1a. Does this trigger fire as soon as one codec is learned to be usable > royalty-free? So this is a first-past-the-post contest? (Let's say codec > "c1" is learned to be usable RF and the next week or month or quarter > "c2" is learned to be usable RF. What happens?) > > 1b. Text along the lines of "the IETF will change this normative > statement" does not make it clear how that will happen. Is there an > automatic trigger (i.e., it's built into this document)? Or does the > IETF need to do something (e.g., publish an RFC that obsoletes this one)? > > (There is some interaction between 1a and 1b. If some process is needed > to declare "c1" the only MTI, then it's possible that we might learn > that "c2" can also be used RF before the obsoleting RFC can be published.) > > 2. A trigger that is more general and future-proof. That is: someday > (perhaps before too much longer on the standardization timescale) we > will have other alternatives to consider: H.265, VP9, VP10, Daala, and > who knows what. > > Another question: > > 2a. There is some interaction between 1b and 2. Let's say it takes us 10 > years to learn that "c1" can be used RF. Hurray! But by that time, we > might have "c3" and "c4" and "c5" to consider. Are we forbidden from > considering anything but "c1" and "c2" at that time? > > I *think* that the trigger you're talking about is #1. Personally I am > much more interested in #2 because I don't think we'll really settle > this issue in the medium term or long term until we have the video > equivalent of Opus. > > Because I think we're talking about different triggers for different > purposes, my impression is that the text we have in mind would differ > significantly (in particular, I feel no compulsion to "stay within the > lines" because I think those lines are not useful, and indeed are > positively harmful, in the long term). > > Peter > From nobody Sun Dec 7 08:28:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DDB1A1A23 for ; Sun, 7 Dec 2014 08:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sc6S5MwXpwy3 for ; Sun, 7 Dec 2014 08:28:48 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830D41A1A11 for ; Sun, 7 Dec 2014 08:28:48 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so2732473wid.17 for ; Sun, 07 Dec 2014 08:28:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9Q2XxtRZrfq+g0CdBHgCrEpezz6o0aBlp/5rAW+ZlTc=; b=TJqEch9gHHpMrj4VX458LYSL9X02f9wV08yKUDYIXMQqnPnGCGLBd1bOfL8wgboIgZ HrfLvrD7jdmuYw1iEr6RZ2wDG7GLMl44HbZXUEU5p+W9KqNwhb6sdtiWAE/uvXNsncQI 5HxaQj0kaufnwR/Us7EjvmYtb6NW6LXHFkMWwmhzewUo8DLOHmoBOSXSVoIkwFMvcHFA +LPA9qp67D338pdeJ1rWP8mhniS7/IFOV9eGmOEO/bMaG1nHsP0O9Bgy8gORv2/FNCUC RFmcs+K/vefX+b40EkZEsE6CvgUzC4gnx1K+PGORCxnkkBrwOZ2FFzJrvnJRZbfzb+wX 6ExQ== X-Gm-Message-State: ALoCoQl2T+N/X8GaO/jaLxWAEvmB2BgQ7EHLpPpotbGnAt6+5BZglE3ayUw7bMntxgfuVYZRP0Mp X-Received: by 10.180.8.202 with SMTP id t10mr18478738wia.15.1417969727187; Sun, 07 Dec 2014 08:28:47 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com. [209.85.212.172]) by mx.google.com with ESMTPSA id d2sm53147190wjs.32.2014.12.07.08.28.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Dec 2014 08:28:45 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so2742493wiv.11 for ; Sun, 07 Dec 2014 08:28:45 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.110.161 with SMTP id ib1mr40799041wjb.78.1417969725693; Sun, 07 Dec 2014 08:28:45 -0800 (PST) Received: by 10.216.70.16 with HTTP; Sun, 7 Dec 2014 08:28:45 -0800 (PST) In-Reply-To: <20141206054017.5955730.89689.3585@blackberry.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F60A8.3080302@alvestrand.no> <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com> <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net> <547FA924.3000504@mozilla.com> <92D0D52F3A63344CA478CF12DB0648AADF35455C@XMB111CNC.rim.net> <548052E7.1050007@alvestrand.no> <92D0D52F3A63344CA478CF12DB0648AADF359C76@XMB111CNC.rim.net> <548203E2.90602@nostrum.com> <20141206054017.5955730.89689.3585@blackberry.com> Date: Sun, 7 Dec 2014 11:28:45 -0500 Message-ID: From: Roman Shpount To: Andrew Allen Content-Type: multipart/alternative; boundary=089e0102fc52cd63e40509a2cd7f Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RiOBwe4f8-08cNJH68C6X2gpUDs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 07 Dec 2014 16:28:50 -0000 --089e0102fc52cd63e40509a2cd7f Content-Type: text/plain; charset=UTF-8 On Sat, Dec 6, 2014 at 12:40 AM, Andrew Allen wrote: > > As Harald already admitted this entire debate has been about companies > business interests and not technical merits. There is ABSOLUTELY NO > TECHNICAL REASON to have 2 MTI video codecs. This has been company business > interest from the start. > This is disingenuous at the very least: There is a great technical reason to have 2 or more MTI video codecs -- interoperability. If it weren't for the IPR related issues, I would still vote for VP8 and H.264 as MTI, since these are the two wide spread codecs that enable video calls of acceptable quality. _____________ Roman Shpount --089e0102fc52cd63e40509a2cd7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Dec 6, 2014 at 12:40 AM, Andrew Allen <aallen@blackberry.com&g= t; wrote:

As Harald already admitted this entire debate has been about companies busi= ness interests and not technical merits. There is ABSOLUTELY NO TECHNICAL R= EASON to have 2 MTI video codecs. This has been company business interest f= rom the start.
=C2=A0
This is = disingenuous at the very least: There is a great technical reason to have 2= or more MTI video codecs -- interoperability.=C2=A0 If it weren't for = the IPR related issues, I would still vote for VP8 and H.264 as MTI, since = these are the two wide spread codecs that enable video calls of acceptable = quality.
_____________
Roman Sh= pount
=C2=A0
--089e0102fc52cd63e40509a2cd7f-- From nobody Sun Dec 7 08:40:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAAA1A1A2F for ; Sun, 7 Dec 2014 08:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUZUddHyQ3Qr for ; Sun, 7 Dec 2014 08:40:43 -0800 (PST) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112B81A1A23 for ; Sun, 7 Dec 2014 08:40:43 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id k14so4461677wgh.23 for ; Sun, 07 Dec 2014 08:40:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=rER+bMeGVeoMz61Tk0u+e+o24bsPzkY9IheOcYxsX9A=; b=ZqsQrvAQqTaKp3PNyLgwr08gVO6lEIEfVP7JqvvMBSIsJ4T8GEbFdAphRrO1a4nrLA K/RtaS00PRulJdk8VOAj2sMKtFzjXDmvitcZjqcSz+HLsaOkq6TtOmmLXdLv7SLGTPUk LRnoCYXzs7Ipc90RVH6h1D+ugeQwiiX4tCqcICSycd7/LwD4PJ8/h36pRnzqSonngfqx euMOTuDjyCtfiBWR54w8v/zNYf63Qb/1GCjHCrhndSaIpDn9F/eo3xquEFNN0rnx3mcX UfVl4e8E+g20FrLXZ8qqfbAu7C3aNL6qgSLnbLaGuwaFl/ypRwvfXHShWXfSj+tFpB/6 qiTA== X-Gm-Message-State: ALoCoQkXBL9GFvq7nDl8zGYmWbXYnf7wV9pd5gK8huDknqX5fnUTsOHHWGz27sENwMM36zeKWq6u X-Received: by 10.194.174.3 with SMTP id bo3mr35293894wjc.98.1417970441909; Sun, 07 Dec 2014 08:40:41 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com. [74.125.82.42]) by mx.google.com with ESMTPSA id gi5sm53182001wjd.26.2014.12.07.08.40.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Dec 2014 08:40:40 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id z12so4537571wgg.15 for ; Sun, 07 Dec 2014 08:40:40 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.76.7 with SMTP id g7mr18705139wiw.38.1417970440520; Sun, 07 Dec 2014 08:40:40 -0800 (PST) Received: by 10.216.70.16 with HTTP; Sun, 7 Dec 2014 08:40:40 -0800 (PST) In-Reply-To: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F60A8.3080302@alvestrand.no> <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com> <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net> <547FA924.3000504@mozilla.com> <92D0D52F3A63344CA478CF12DB0648AADF35455C@XMB111CNC.rim.net> <548052E7.1050007@alvestrand.no> <92D0D52F3A63344CA478CF12DB0648AADF359C76@XMB111CNC.rim.net> <548203E2.90602@nostrum.com> <20141206054017.5955730.89689.3585@blackberry.com> Date: Sun, 7 Dec 2014 11:40:40 -0500 Message-ID: From: Roman Shpount To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=f46d043893c768c8600509a2f8b8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/c9TkioT3GzqFV_EpTgOtBq2H_EI Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 07 Dec 2014 16:40:45 -0000 --f46d043893c768c8600509a2f8b8 Content-Type: text/plain; charset=UTF-8 There were a lot of arguments here about the Nokia IPR declaration regarding VP8. IANAL, but typically there is a very simple way to determine the validity of the IPR claim. It comes down to one simple question -- Have the party claiming IPR violation filed the law suite? If not, their claims most likely do not justify the court filing fees in their own eyes. Mozilla and Google have been shipping browsers with VP8 codec support for several years already and Nokia did not do a single thing to stop this. If Nokia is serious about their IPR claims, they should take the alleged violators to court. At least this way there is going to be a definitive decision regarding the validity of these claims. _____________ Roman Shpount --f46d043893c768c8600509a2f8b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There were a lot of arguments here about the Nokia IPR dec= laration regarding VP8. IANAL, but typically there is a very simple way to = determine the validity of the IPR claim. It comes down to one simple questi= on -- Have the party claiming IPR violation filed the law suite? If not, th= eir claims most likely do not justify the court filing fees in their own ey= es. Mozilla and Google have been shipping browsers with VP8 codec support f= or several years already and Nokia did not do a single thing to stop this. = If Nokia is serious about their IPR claims, they should take the alleged vi= olators to court. At least this way there is going to be a definitive decis= ion regarding the validity of these claims.
<= br clear=3D"all">
_____________
Roman= Shpount

--f46d043893c768c8600509a2f8b8-- From nobody Sun Dec 7 09:07:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B631A8792 for ; Sun, 7 Dec 2014 09:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuTGoGHgeZTt for ; Sun, 7 Dec 2014 09:07:44 -0800 (PST) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791411A877B for ; Sun, 7 Dec 2014 09:07:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417972064; x=2281885664; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wd4+A8Om4WJqAxqM+DeL1mmZPVwwA9RJwLbFQOR3Xa4=; b=PV0I8hgT4Xk6idkSrF8jMF4zC5rB/K9mTRE9wgPBoaJV8r7TOuMQhOEjCtS47q6Y 0CWg50Sw3pU2v7/AuD615ur1iHjGnaaLhCygxLkDAAWNUayL78SeYg6sw+hmNpVk zakCJ3t1D+MRuRJgWkRm5YJZvTb83jgrMY3T0dmpHzGLT2HpxU6AXwbLzIWmN/k0 N579VAegb5YoGMrIJ16lrlotZs9122BbrV3RlE3eZKnx2/G2nmRjoQ/iq0uCgdlZ orrYeVO/hdtFLsr8z3m8GPcZ4mz/6bsc1jKa1DcZVU+QlEyN7sjCP/P38qYiybit jXTeWCEf/i2hUWa0V3LqDQ==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id A0.4B.09658.06984845; Sun, 7 Dec 2014 09:07:44 -0800 (PST) X-AuditID: 11973e16-f79aa6d0000025ba-b8-548489605ca8 Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 74.EB.06123.16984845; Sun, 7 Dec 2014 09:07:45 -0800 (PST) Received: from [17.153.102.23] (unknown [17.153.102.23]) by cilantro.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG8004NU28VZ700@cilantro.apple.com> for rtcweb@ietf.org; Sun, 07 Dec 2014 09:07:43 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <5483C6DE.80708@nostrum.com> Date: Sun, 07 Dec 2014 09:07:42 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <54820E74.90201@mozilla.com> <548260D2.2020703@nostrum.com> <5483755A.4070806@nostrum.com> <68056FA8-8B28-41E5-815A-A1BAA048F190@apple.com> <5483C6DE.80708@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUi2FAYoZvQ2RJiMPsKk8Xaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKWHzdoOASZ8Wxw6YNjHfYuxg5OSQETCR+HlrCDGGLSVy4t56t i5GLQ0hgL6PExYZLbDBFy7d1sUAkJjJJdC35zQThTGaSmPlgO2MXIwcHs4C6xJQpuSANvAJ6 Ek1PHjOBhIUFbCW2Xg8CCbMJqEo8mHOMEcTmFNCUmN/yB+wIFqD4tUP3WEBsZgErib+nnzBC 2NoST95dYIUYaSMx5cgzqOMuMElM6j0BViQioCjRdvgm1AeyEv8unmEHKZIQeMkqMePeHcYJ jMKzEM6bheS8WUh2LGBkXsUolJuYmaObmWeul1hQkJOql5yfu4kRFMLT7cR2MD5cZXWIUYCD UYmHN4K7JUSINbGsuDL3EKM0B4uSOG+yfVOIkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbq jWUV/i+vKTpvUr2q9YPF796649sur+3f7nx+wcbDqkx/q9zjnOIaP1vmSjIpPdJ1e3hSJ+P3 5lXr2k+HNBXzWsxfeF99WtnbHA3G2swFoR87M9J5pKa8O8HpbGB9c/KbppUlLV5Kk41N+Cdw 7xXQZfi30dOn+N9d/QOrrDzVO3zU5yia9SqxFGckGmoxFxUnAgBOSRU2QgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUi2FAspJvY2RJisHKFucXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKWHzdoOASZ8Wxw6YNjHfYuxg5OSQETCSWb+tigbDFJC7cW8/W xcjFISQwkUmia8lvJghnMpPEzAfbGbsYOTiYBdQlpkzJBWngFdCTaHrymAkkLCxgK7H1ehBI mE1AVeLBnGOMIDangKbE/JY/YLtYgOLXDt0D28UsYCXx9/QTRghbW+LJuwusECNtJKYceQZ1 wwUmiUm9J8CKRAQUJdoO32SGOFRW4t/FM+wTGAVmIVw0C8lFs5CMXcDIvIpRoCg1J7HSVC+x oCAnVS85P3cTIzjkCiN2MP5fZnWIUYCDUYmHN4K7JUSINbGsuDL3EKMEB7OSCG9PGlCINyWx siq1KD++qDQntfgQozQHi5I4b8m7xhAhgfTEktTs1NSC1CKYLBMHp1QD45JHdgm7POfPfCT+ 9syV+Ca3DYfqPqcxemlJqyuf3XTpZszi5padh3Y8VuM+MK19pd9aCcW6xH1r7OLUtlhtdVOx 076/tVuB999drqs7Pv7a/lmE8d0hm6BKZZ/XQRuOa219zn8mV1tKuozR1qIzeeUrDh6XG7ob GJsmzql+tl5Iy+3NjiwOBSWW4oxEQy3mouJEALKew1U1AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1KIPZJG9LW5Rp4vVk2tg7Y1y1_g Cc: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 07 Dec 2014 17:07:46 -0000 > On Dec 6, 2014, at 19:17 , Adam Roach wrote: >=20 > On 12/6/14 19:41, David Singer wrote: >> Adam >>=20 >> we are at cross purposes. I am complaining about a language usage. = When you say =E2=80=9Cboth camps support=E2=80=9D you imply (a) that = there are only two camps, and everyone is a member of one or other and = (b) that they have reached agreement =E2=80=94 and therefore we are = done. Perhaps you don=E2=80=99t mean it, but it=E2=80=99s a technique = some people use to try to give the appearance of an agreement, and given = the sensitive nature of the subject, I=E2=80=99d prefer you not do that. >>=20 >> If you say =E2=80=9Cthere was support for the position from several = camps=E2=80=9D, or somesuch, that would be fine. That leaves room for = people to say that they dissent, that=E2=80=99s all. >>=20 >> Got it? >=20 > Is this the colloquial use of the word "you" to mean "one"? As in = "when one says 'both camps support=E2=80=99"? Yes, =E2=80=9Cyou=E2=80=9D as in the sense of =E2=80=9Cone=E2=80=9D. = Correct, Jean-Marc used the phrase first; but you responded to my = message about its use, not him. David Singer Manager, Software Standards, Apple Inc. From nobody Sun Dec 7 21:15:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DB21A6EE0 for ; Sun, 7 Dec 2014 21:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYZFMQZY2RMq for ; Sun, 7 Dec 2014 21:15:51 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 901081A6EDE for ; Sun, 7 Dec 2014 21:15:51 -0800 (PST) Received: from xct107cnc.rim.net ([10.65.161.207]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 08 Dec 2014 00:15:46 -0500 Received: from XCT104CNC.rim.net (10.65.161.204) by XCT107CNC.rim.net (10.65.161.207) with Microsoft SMTP Server (TLS) id 14.3.210.2; Mon, 8 Dec 2014 00:15:45 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Mon, 8 Dec 2014 00:15:45 -0500 From: Andrew Allen To: Roman Shpount Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) Thread-Index: AQHQDyew2za5sQikUES+QP80tOoCX5x+j7gAgAAgMwCAAChyAIAADcQAgAAeaYCAAKv2gIAB/3mAgAAErgCAAFtGa4ACm1OA///lNVA= Date: Mon, 8 Dec 2014 05:15:44 +0000 Message-ID: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F60A8.3080302@alvestrand.no> <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com> <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net> <547FA924.3000504@mozilla.com> <92D0D52F3A63344CA478CF12DB0648AADF35455C@XMB111CNC.rim.net> <548052E7.1050007@alvestrand.no> <92D0D52F3A63344CA478CF12DB0648AADF359C76@XMB111CNC.rim.net> <548203E2.90602@nostrum.com> <20141206054017.5955730.89689.3585@blackberry.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD233998956EXMB122CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PTB-jiL3ffSpvtxRcNj43A3mms4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 05:15:54 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD233998956EXMB122CNCrimnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9tYW4NCg0KV2Ugb25seSBuZWVkIHRvIGFncmVlIG9uIGEgc2luZ2xlIHZpZGVvIE1USSB0byBl bnN1cmUgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIFJUQ3dlYiBjb21wbGlhbnQgZW50aXRpZXMu IEguMjY0IGFsc28gZ2l2ZXMgeW91IGludGVyb3BlcmFiaWxpdHkgd2l0aCBtdWNoIG9mIHRoZSBh bHJlYWR5IGVzdGFibGlzaGVkIGxlZ2FjeSB2aWRlbyBpbmZyYXN0cnVjdHVyZSBiYXNlIG91dCB0 aGVyZSAoVmlkZW8gb3ZlciBMVEUsIHZpZGVvIGNvbmZlcmVuY2luZywgZXRjKSBhcyB3ZWxsLg0K DQpIYXZpbmcgdHdvIE1USXMgc2ltcGx5IGluY3JlYXNlcyB0aGUgY29tcGxleGl0eSwgY29zdCBh bmQgdGhlIGxpdGlnYXRpb24gcmlzayBmb3IgZXZlcnlvbmUgdGhhdCBhY3R1YWxseSBoYXMgdG8g aW1wbGVtZW50IGJvdGggTVRJcyB3aXRoIGxpdHRsZSBpZiBhbnkgYWRkaXRpb25hbCBiZW5lZml0 Lg0KDQpBbmRyZXcNCg0KRnJvbTogUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXgu Y29tXQ0KU2VudDogU3VuZGF5LCBEZWNlbWJlciAwNywgMjAxNCAxMToyOSBBTQ0KVG86IEFuZHJl dyBBbGxlbg0KQ2M6IEFkYW0gUm9hY2g7IEdhZWxsZSBNYXJ0aW4tQ29jaGVyOyBIYXJhbGQgQWx2 ZXN0cmFuZDsgcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gRmluaXNoaW5n IHVwIHRoZSBWaWRlbyBDb2RlYyBkb2N1bWVudCwgTVRJIChhZ2Fpbiwgc3RpbGwsIHNvcnJ5KQ0K DQpPbiBTYXQsIERlYyA2LCAyMDE0IGF0IDEyOjQwIEFNLCBBbmRyZXcgQWxsZW4gPGFhbGxlbkBi bGFja2JlcnJ5LmNvbTxtYWlsdG86YWFsbGVuQGJsYWNrYmVycnkuY29tPj4gd3JvdGU6DQoNCkFz IEhhcmFsZCBhbHJlYWR5IGFkbWl0dGVkIHRoaXMgZW50aXJlIGRlYmF0ZSBoYXMgYmVlbiBhYm91 dCBjb21wYW5pZXMgYnVzaW5lc3MgaW50ZXJlc3RzIGFuZCBub3QgdGVjaG5pY2FsIG1lcml0cy4g VGhlcmUgaXMgQUJTT0xVVEVMWSBOTyBURUNITklDQUwgUkVBU09OIHRvIGhhdmUgMiBNVEkgdmlk ZW8gY29kZWNzLiBUaGlzIGhhcyBiZWVuIGNvbXBhbnkgYnVzaW5lc3MgaW50ZXJlc3QgZnJvbSB0 aGUgc3RhcnQuDQoNClRoaXMgaXMgZGlzaW5nZW51b3VzIGF0IHRoZSB2ZXJ5IGxlYXN0OiBUaGVy ZSBpcyBhIGdyZWF0IHRlY2huaWNhbCByZWFzb24gdG8gaGF2ZSAyIG9yIG1vcmUgTVRJIHZpZGVv IGNvZGVjcyAtLSBpbnRlcm9wZXJhYmlsaXR5LiAgSWYgaXQgd2VyZW4ndCBmb3IgdGhlIElQUiBy ZWxhdGVkIGlzc3VlcywgSSB3b3VsZCBzdGlsbCB2b3RlIGZvciBWUDggYW5kIEguMjY0IGFzIE1U SSwgc2luY2UgdGhlc2UgYXJlIHRoZSB0d28gd2lkZSBzcHJlYWQgY29kZWNzIHRoYXQgZW5hYmxl IHZpZGVvIGNhbGxzIG9mIGFjY2VwdGFibGUgcXVhbGl0eS4NCl9fX19fX19fX19fX18NClJvbWFu IFNocG91bnQNCg0K --_000_BBF5DDFE515C3946BC18D733B20DAD233998956EXMB122CNCrimnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Um9tYW48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PldlIG9ubHkgbmVlZCB0byBhZ3JlZSBvbiBhIHNpbmdsZSB2aWRlbyBNVEkgdG8gZW5zdXJlIGlu dGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBSVEN3ZWIgY29tcGxpYW50IGVudGl0aWVzLiBILjI2NCBh bHNvIGdpdmVzIHlvdSBpbnRlcm9wZXJhYmlsaXR5IHdpdGggbXVjaCBvZg0KIHRoZSBhbHJlYWR5 IGVzdGFibGlzaGVkIGxlZ2FjeSB2aWRlbyBpbmZyYXN0cnVjdHVyZSBiYXNlIG91dCB0aGVyZSAo VmlkZW8gb3ZlciBMVEUsIHZpZGVvIGNvbmZlcmVuY2luZywgZXRjKSBhcyB3ZWxsLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SGF2aW5nIHR3byBNVElzIHNpbXBseSBpbmNyZWFzZXMgdGhlIGNvbXBsZXhpdHksIGNvc3Qg YW5kIHRoZSBsaXRpZ2F0aW9uIHJpc2sgZm9yIGV2ZXJ5b25lIHRoYXQgYWN0dWFsbHkgaGFzIHRv IGltcGxlbWVudCBib3RoIE1USXMgd2l0aCBsaXR0bGUgaWYgYW55IGFkZGl0aW9uYWwNCiBiZW5l Zml0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+QW5kcmV3PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gU3VuZGF5LCBEZWNlbWJlciAwNywgMjAxNCAxMToyOSBBTTxicj4NCjxiPlRv OjwvYj4gQW5kcmV3IEFsbGVuPGJyPg0KPGI+Q2M6PC9iPiBBZGFtIFJvYWNoOyBHYWVsbGUgTWFy dGluLUNvY2hlcjsgSGFyYWxkIEFsdmVzdHJhbmQ7IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gRmluaXNoaW5nIHVwIHRoZSBWaWRlbyBDb2RlYyBkb2N1 bWVudCwgTVRJIChhZ2Fpbiwgc3RpbGwsIHNvcnJ5KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCBEZWMgNiwgMjAxNCBhdCAxMjo0MCBB TSwgQW5kcmV3IEFsbGVuICZsdDs8YSBocmVmPSJtYWlsdG86YWFsbGVuQGJsYWNrYmVycnkuY29t IiB0YXJnZXQ9Il9ibGFuayI+YWFsbGVuQGJsYWNrYmVycnkuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBI YXJhbGQgYWxyZWFkeSBhZG1pdHRlZCB0aGlzIGVudGlyZSBkZWJhdGUgaGFzIGJlZW4gYWJvdXQg Y29tcGFuaWVzIGJ1c2luZXNzIGludGVyZXN0cyBhbmQgbm90IHRlY2huaWNhbCBtZXJpdHMuIFRo ZXJlIGlzIEFCU09MVVRFTFkgTk8gVEVDSE5JQ0FMDQogUkVBU09OIHRvIGhhdmUgMiBNVEkgdmlk ZW8gY29kZWNzLiBUaGlzIGhhcyBiZWVuIGNvbXBhbnkgYnVzaW5lc3MgaW50ZXJlc3QgZnJvbSB0 aGUgc3RhcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBkaXNpbmdlbnVvdXMgYXQgdGhl IHZlcnkgbGVhc3Q6IFRoZXJlIGlzIGEgZ3JlYXQgdGVjaG5pY2FsIHJlYXNvbiB0byBoYXZlIDIg b3IgbW9yZSBNVEkgdmlkZW8gY29kZWNzIC0tIGludGVyb3BlcmFiaWxpdHkuJm5ic3A7IElmIGl0 IHdlcmVuJ3QgZm9yIHRoZSBJUFIgcmVsYXRlZCBpc3N1ZXMsIEkgd291bGQgc3RpbGwgdm90ZSBm b3IgVlA4IGFuZCBILjI2NCBhcyBNVEksIHNpbmNlIHRoZXNlIGFyZSB0aGUNCiB0d28gd2lkZSBz cHJlYWQgY29kZWNzIHRoYXQgZW5hYmxlIHZpZGVvIGNhbGxzIG9mIGFjY2VwdGFibGUgcXVhbGl0 eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_BBF5DDFE515C3946BC18D733B20DAD233998956EXMB122CNCrimnet_-- From nobody Sun Dec 7 21:16:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317561A6EDE for ; Sun, 7 Dec 2014 21:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bU68QKttDBG8 for ; Sun, 7 Dec 2014 21:16:19 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 418BF1A6EF0 for ; Sun, 7 Dec 2014 21:16:19 -0800 (PST) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 08 Dec 2014 00:16:10 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT105CNC.rim.net ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.03.0210.002; Mon, 8 Dec 2014 00:16:08 -0500 From: Andrew Allen To: Roman Shpount , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) Thread-Index: AQHQDyew2za5sQikUES+QP80tOoCX5x+j7gAgAAgMwCAAChyAIAADcQAgAAeaYCAAKv2gIAB/3mAgAAErgCAAFtGa4ACm1OAgAADVACAAAuIYA== Date: Mon, 8 Dec 2014 05:16:08 +0000 Message-ID: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <547F60A8.3080302@alvestrand.no> <27F838F1-326D-48BD-B553-6FE993E5C34F@apple.com> <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net> <547FA924.3000504@mozilla.com> <92D0D52F3A63344CA478CF12DB0648AADF35455C@XMB111CNC.rim.net> <548052E7.1050007@alvestrand.no> <92D0D52F3A63344CA478CF12DB0648AADF359C76@XMB111CNC.rim.net> <548203E2.90602@nostrum.com> <20141206054017.5955730.89689.3585@blackberry.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD23399895AFXMB122CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ukKGr2ClJ-A0AdlqXjnYJEY-dmU Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 05:16:24 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD23399895AFXMB122CNCrimnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9tYW4NCg0KSSBkb27igJl0IHRoaW5rIHRoYXQgcHJvdmVzIGFueXRoaW5nLg0KDQpBbnkgYmFz aWMgbWlsaXRhcnkgZG9jdHJpbmUgb24gdGhlIHRhY3RpY3Mgb2YgYW1idXNoIGlzIGdvaW5nIHRv IHN0YXRlIHRoYXQgeW91IGRvbuKAmXQgZ28gYWZ0ZXIgdGhlIGxlYWQgZWxlbWVudHMgZXNwZWNp YWxseSBpZiB0aGV5IGFyZSB0aGUgc3Ryb25nZXIgYXJtb3JlZCBlbGVtZW50cyB0aGF0IGFyZSBt b3N0IGNhcGFibGUgb2YgYmVhdGluZyBiYWNrIHRoZSBhdHRhY2sg4oCTIG5vIHlvdSBiaWRlIHlv dXIgdGltZSBhbmQgd2FpdCB1bnRpbCB0aGUgZm9sbG93IG9uIHRyb29wcyB0aGF0IGFyZSBmYXIg bGVzcyBhYmxlIHRvIHdpdGhzdGFuZCB0aGUgYXR0YWNrIGNvbWUgYWxvbmcgYW5kIHRoZW4gbW91 bnQgeW91ciBhc3NhdWx0IOKAkyByaXBwaW5nIHRoZW0gdG8gc2hyZWFkcyBhbmQgdGh1cyBsZWF2 aW5nIHRob3NlIG1vcmUgcG93ZXJmdWwgbGVhZCBlbGVtZW50cyBjdXQgb2ZmIGFuZCBzdXJyb3Vu ZGVkIHdpdGggbm8gcGF0aCB0byByZXRyZWF0IQ0KDQpBbmRyZXcNCg0KRnJvbTogcnRjd2ViIFtt YWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb21hbiBTaHBvdW50 DQpTZW50OiBTdW5kYXksIERlY2VtYmVyIDA3LCAyMDE0IDExOjQxIEFNDQpUbzogcnRjd2ViQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gRmluaXNoaW5nIHVwIHRoZSBWaWRlbyBDb2Rl YyBkb2N1bWVudCwgTVRJIChhZ2Fpbiwgc3RpbGwsIHNvcnJ5KQ0KDQpUaGVyZSB3ZXJlIGEgbG90 IG9mIGFyZ3VtZW50cyBoZXJlIGFib3V0IHRoZSBOb2tpYSBJUFIgZGVjbGFyYXRpb24gcmVnYXJk aW5nIFZQOC4gSUFOQUwsIGJ1dCB0eXBpY2FsbHkgdGhlcmUgaXMgYSB2ZXJ5IHNpbXBsZSB3YXkg dG8gZGV0ZXJtaW5lIHRoZSB2YWxpZGl0eSBvZiB0aGUgSVBSIGNsYWltLiBJdCBjb21lcyBkb3du IHRvIG9uZSBzaW1wbGUgcXVlc3Rpb24gLS0gSGF2ZSB0aGUgcGFydHkgY2xhaW1pbmcgSVBSIHZp b2xhdGlvbiBmaWxlZCB0aGUgbGF3IHN1aXRlPyBJZiBub3QsIHRoZWlyIGNsYWltcyBtb3N0IGxp a2VseSBkbyBub3QganVzdGlmeSB0aGUgY291cnQgZmlsaW5nIGZlZXMgaW4gdGhlaXIgb3duIGV5 ZXMuIE1vemlsbGEgYW5kIEdvb2dsZSBoYXZlIGJlZW4gc2hpcHBpbmcgYnJvd3NlcnMgd2l0aCBW UDggY29kZWMgc3VwcG9ydCBmb3Igc2V2ZXJhbCB5ZWFycyBhbHJlYWR5IGFuZCBOb2tpYSBkaWQg bm90IGRvIGEgc2luZ2xlIHRoaW5nIHRvIHN0b3AgdGhpcy4gSWYgTm9raWEgaXMgc2VyaW91cyBh Ym91dCB0aGVpciBJUFIgY2xhaW1zLCB0aGV5IHNob3VsZCB0YWtlIHRoZSBhbGxlZ2VkIHZpb2xh dG9ycyB0byBjb3VydC4gQXQgbGVhc3QgdGhpcyB3YXkgdGhlcmUgaXMgZ29pbmcgdG8gYmUgYSBk ZWZpbml0aXZlIGRlY2lzaW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb2YgdGhlc2UgY2xhaW1z Lg0KDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCg== --_000_BBF5DDFE515C3946BC18D733B20DAD23399895AFXMB122CNCrimnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlJvbWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQgdGhpbmsgdGhhdCBwcm92 ZXMgYW55dGhpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbnkgYmFzaWMgbWlsaXRhcnkgZG9jdHJpbmUgb24gdGhl IHRhY3RpY3Mgb2YgYW1idXNoIGlzIGdvaW5nIHRvIHN0YXRlIHRoYXQgeW91IGRvbuKAmXQgZ28g YWZ0ZXIgdGhlIGxlYWQgZWxlbWVudHMgZXNwZWNpYWxseSBpZiB0aGV5IGFyZSB0aGUgc3Ryb25n ZXIgYXJtb3JlZA0KIGVsZW1lbnRzIHRoYXQgYXJlIG1vc3QgY2FwYWJsZSBvZiBiZWF0aW5nIGJh Y2sgdGhlIGF0dGFjayDigJMgbm8geW91IGJpZGUgeW91ciB0aW1lIGFuZCB3YWl0IHVudGlsIHRo ZSBmb2xsb3cgb24gdHJvb3BzIHRoYXQgYXJlIGZhciBsZXNzIGFibGUgdG8gd2l0aHN0YW5kIHRo ZSBhdHRhY2sgY29tZSBhbG9uZyBhbmQgdGhlbiBtb3VudCB5b3VyIGFzc2F1bHQg4oCTIHJpcHBp bmcgdGhlbSB0byBzaHJlYWRzIGFuZCB0aHVzIGxlYXZpbmcgdGhvc2UgbW9yZQ0KIHBvd2VyZnVs IGxlYWQgZWxlbWVudHMgY3V0IG9mZiBhbmQgc3Vycm91bmRlZCB3aXRoIG5vIHBhdGggdG8gcmV0 cmVhdCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkFuZHJldzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPlJvbWFuIFNocG91bnQ8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBEZWNl bWJlciAwNywgMjAxNCAxMTo0MSBBTTxicj4NCjxiPlRvOjwvYj4gcnRjd2ViQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBGaW5pc2hpbmcgdXAgdGhlIFZpZGVvIENv ZGVjIGRvY3VtZW50LCBNVEkgKGFnYWluLCBzdGlsbCwgc29ycnkpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgd2VyZSBhIGxvdCBvZiBhcmd1bWVudHMgaGVyZSBh Ym91dCB0aGUgTm9raWEgSVBSIGRlY2xhcmF0aW9uIHJlZ2FyZGluZyBWUDguIElBTkFMLCBidXQg dHlwaWNhbGx5IHRoZXJlIGlzIGEgdmVyeSBzaW1wbGUgd2F5IHRvIGRldGVybWluZSB0aGUgdmFs aWRpdHkgb2YgdGhlIElQUiBjbGFpbS4gSXQgY29tZXMgZG93biB0byBvbmUgc2ltcGxlIHF1ZXN0 aW9uIC0tIEhhdmUgdGhlIHBhcnR5IGNsYWltaW5nDQogSVBSIHZpb2xhdGlvbiBmaWxlZCB0aGUg bGF3IHN1aXRlPyBJZiBub3QsIHRoZWlyIGNsYWltcyBtb3N0IGxpa2VseSBkbyBub3QganVzdGlm eSB0aGUgY291cnQgZmlsaW5nIGZlZXMgaW4gdGhlaXIgb3duIGV5ZXMuIE1vemlsbGEgYW5kIEdv b2dsZSBoYXZlIGJlZW4gc2hpcHBpbmcgYnJvd3NlcnMgd2l0aCBWUDggY29kZWMgc3VwcG9ydCBm b3Igc2V2ZXJhbCB5ZWFycyBhbHJlYWR5IGFuZCBOb2tpYSBkaWQgbm90IGRvIGEgc2luZ2xlIHRo aW5nDQogdG8gc3RvcCB0aGlzLiBJZiBOb2tpYSBpcyBzZXJpb3VzIGFib3V0IHRoZWlyIElQUiBj bGFpbXMsIHRoZXkgc2hvdWxkIHRha2UgdGhlIGFsbGVnZWQgdmlvbGF0b3JzIHRvIGNvdXJ0LiBB dCBsZWFzdCB0aGlzIHdheSB0aGVyZSBpcyBnb2luZyB0byBiZSBhIGRlZmluaXRpdmUgZGVjaXNp b24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvZiB0aGVzZSBjbGFpbXMuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188 YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BBF5DDFE515C3946BC18D733B20DAD23399895AFXMB122CNCrimnet_-- From nobody Mon Dec 8 01:05:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E504B1A8032 for ; Mon, 8 Dec 2014 01:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7bm4_Su9ucm for ; Mon, 8 Dec 2014 01:05:24 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by ietfa.amsl.com (Postfix) with ESMTP id 158441A8731 for ; Mon, 8 Dec 2014 01:05:23 -0800 (PST) Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail06.adl2.internode.on.net with ESMTP; 08 Dec 2014 19:35:05 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id BD0C7FFC64 for ; Mon, 8 Dec 2014 19:35:04 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QCk5gUW9wlYV for ; Mon, 8 Dec 2014 19:35:00 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 0FDA8FF904 for ; Mon, 8 Dec 2014 19:35:00 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id EC52380470; Mon, 8 Dec 2014 19:34:59 +1030 (ACDT) Date: Mon, 8 Dec 2014 19:34:59 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141208090459.GD19538@hex.shelbyville.oz> References: <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net> <547FA924.3000504@mozilla.com> <92D0D52F3A63344CA478CF12DB0648AADF35455C@XMB111CNC.rim.net> <548052E7.1050007@alvestrand.no> <92D0D52F3A63344CA478CF12DB0648AADF359C76@XMB111CNC.rim.net> <548203E2.90602@nostrum.com> <20141206054017.5955730.89689.3585@blackberry.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1vXkGzWh3hvRdIGqOIQwUvO9vSE Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 09:05:28 -0000 On Mon, Dec 08, 2014 at 05:16:08AM +0000, Andrew Allen wrote: > > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount > > Sent: Sunday, December 07, 2014 11:41 AM > > To: rtcweb@ietf.org > > Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) > > > > There were a lot of arguments here about the Nokia IPR declaration > > regarding VP8. IANAL, but typically there is a very simple way to > > determine the validity of the IPR claim. It comes down to one simple > > question -- Have the party claiming IPR violation filed the law suite? > > If not, their claims most likely do not justify the court filing fees > > in their own eyes. Mozilla and Google have been shipping browsers with > > VP8 codec support for several years already and Nokia did not do a > > single thing to stop this. If Nokia is serious about their IPR claims, > > they should take the alleged violators to court. At least this way > > there is going to be a definitive decision regarding the validity of > > these claims. > > I don’t think that proves anything. > > Any basic military doctrine on the tactics of ambush is going to state > that you don’t go after the lead elements especially if they are the > stronger armored elements that are most capable of beating back the > attack – no you bide your time and wait until the follow on troops > that are far less able to withstand the attack come along and then > mount your assault – ripping them to shreads and thus leaving those > more powerful lead elements cut off and surrounded with no path to > retreat! While that's a very interesting analysis of the kind of panicked thought processes going on among the rearguard participants from blackberry, it's not clear to me exactly what relevance you think it has here. Are you saying that Nokia is not only bad at business, bad at keeping their talented staff, and bad at community relations - but that they also suck at military strategy too? Because they launched their attack, and got laughed out of court ... http://blog.webmproject.org/2013/08/good-news-from-germany.html Maybe you are suggesting that was just a clever ruse, and rather than using their actually valid patent, they wasted all that money on lawyers to simply feint with the weakest one they could find? In which case I hope for their sake that they've kept their good lawyers in reserve for when their shareholders come wanting to rip them to shreds! If ignorant both of your enemy and yourself, you are certain to be in peril. -- Sun Tzu From nobody Mon Dec 8 08:00:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88201A876B for ; Mon, 8 Dec 2014 08:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4Ka55HT5BLb for ; Mon, 8 Dec 2014 08:00:34 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1441A90E9 for ; Mon, 8 Dec 2014 08:00:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 7BC887C3659; Mon, 8 Dec 2014 17:00:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtKhvUPftW_k; Mon, 8 Dec 2014 17:00:30 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:603b:7836:2531:29df] (unknown [IPv6:2001:470:de0a:27:603b:7836:2531:29df]) by mork.alvestrand.no (Postfix) with ESMTPSA id F0F2A7C3658; Mon, 8 Dec 2014 17:00:29 +0100 (CET) Message-ID: <5485CB1D.5040305@alvestrand.no> Date: Mon, 08 Dec 2014 17:00:29 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Gaelle Martin-Cocher , "rtcweb@ietf.org" References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <20141204014218.5955730.38619.3157@blackberry.com> <1F326DF9-79C2-4562-853B-240D934EA235@apple.com> <949EF20990823C4C85C18D59AA11AD8B28CDFF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <5480CEF2.4020204@mozilla.com> <949EF20990823C4C85C18D59AA11AD8B28CF6B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54816F91.9010108@alvestrand.no> <92D0D52F3A63344CA478CF12DB0648AADF359DEB@XMB111CNC.rim.net> In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF359DEB@XMB111CNC.rim.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/j-GS7Ow-S66NKCRPeYbVOGc1ZNc Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 16:00:36 -0000 Den 05. des. 2014 21:37, skrev Gaelle Martin-Cocher: > Harald, > > Would you mind clarifying if that VP8 WebM CCL agreement is up to date (copyright is 2010-2013) I believe it is. > and if it covers all the declarations that are listed in https://tools.ietf.org/html/draft-benham-rtcweb-vp8litigation ? > To the limits of my understanding: It covers the IPR covered by Google's declarations listed in section 2.1 and 2.2 of that draft. It also covers the IPR described by the declarations covered by Note 1 of section 2.2 of that draft. But there are more declarations listed in those sections. So the answer to your question, read literally, is "no". From nobody Mon Dec 8 08:02:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AC01A90C8 for ; Mon, 8 Dec 2014 08:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTk0tGEb12Ti for ; Mon, 8 Dec 2014 08:02:27 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id AD5B91A8768 for ; Mon, 8 Dec 2014 08:02:26 -0800 (PST) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 08 Dec 2014 11:02:11 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0210.002; Mon, 8 Dec 2014 11:02:08 -0500 From: Gaelle Martin-Cocher To: Ron , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) Thread-Index: AQHQDyewEeqVo81nB0ShjNtLfXarlJx+j7gAgAAgMwD//7RIMIAAge4A///FiXCAAQTWgIABqNgwgABbTwCAAK8XAIACR4KAgAADVACAANMTAIAAP/GAgAAOc4A= Date: Mon, 8 Dec 2014 16:02:08 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF35B057@XMB111CNC.rim.net> References: <92D0D52F3A63344CA478CF12DB0648AADF354465@XMB111CNC.rim.net> <547FA924.3000504@mozilla.com> <92D0D52F3A63344CA478CF12DB0648AADF35455C@XMB111CNC.rim.net> <548052E7.1050007@alvestrand.no> <92D0D52F3A63344CA478CF12DB0648AADF359C76@XMB111CNC.rim.net> <548203E2.90602@nostrum.com> <20141206054017.5955730.89689.3585@blackberry.com> <20141208090459.GD19538@hex.shelbyville.oz> In-Reply-To: <20141208090459.GD19538@hex.shelbyville.oz> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KyB_F5CbMRSnKx-FmPbtjIRJFLM Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 16:02:29 -0000 Um9uLCANCg0KSSBkb24ndCB0aGluayBCbGFja0JlcnJ5IG5vciBCbGFja0JlcnJ5IGVtcGxveWVl cyB3aWxsIGV2ZXIgbWFrZSB0aGUgc3RhdGVtZW50cyB5b3UgaW1wbGllZC4NCk91ciBib3R0b20g bGluZSBpbiB0aGlzIGRpc2N1c3Npb24gaXMgYSBiYWxhbmNlIGJldHdlZW4gdGVjaG5pY2FsIHNl bnNlLCBRb1MsIGludGVyb3BlcmFiaWxpdHkgYW5kIGNvc3QgY29udHJvbC4NCkhlbmNlIHdlIGhh dmUgc3RhdGVkIHRoYXQgd2UgYXJlIE9LIHdpdGggY29kZWNzIHRoYXQgYXJlIGFscmVhZHkgc3Vw cG9ydGVkIGFjcm9zcyB2YXJpb3VzIHBsYXRmb3JtcyAoZS5nLiBILjI2MywgSC4yNjQpLiBUaGF0 IHNvbHZlcyBib3RoIGNvc3RzIGFuZCBpbnRlcm9wZXJhYmlsaXR5IGNvbmNlcm5zLg0KSXQgdGFr ZXMgZmFyIHRvbyBsb25nIHRvIHJlbW92ZSBhIGNvZGVjIGZyb20gYSBwbGF0Zm9ybSB3aGVuIGl0 IGlzIG9uY2UgaW5zdGFsbGVkLiAoZS5nLiBIMjYxKQ0KVGhlcmUgaXMgbGl0dGxlIHJlYXNvbnMg dG8gY3JlYXRlIGxlZ2FjeSBzZXJ2aWNlcyB3aXRoIFZQOCBhcyBpdCBpcyBnb2luZyB0byBiZSBz b29uIG9ic29sZXRlZCBieSBWUDkuIFRoZXJlIGlzIGV2ZW4gbGVzcyByZWFzb25zIHRvIG1hbmRh dGUgVlA4IGNvZGVjIGFjcm9zcyBwbGF0Zm9ybXMgKHNvb24gb2Jzb2xldGUsIHRvbyBsb25nIHRv IHJlbW92ZSBmcm9tIGEgcGxhdGZvcm0sIGRvZXMgbm90IGhhdmUgbXVjaCB0ZWNobmljYWwgdmFs dWVzIG92ZXIgSC4yNjQpLg0KDQpJIHNoYXJlIHRoZSBjb25jZXJucyBmcm9tIG1hbnkgaW4gdGhp cyBsaXN0LCB0aGF0IHdlIG1heSBkZXBlbmQgb24gYnJvd3NlciB2ZW5kb3JzIGltcGxlbWVudGF0 aW9ucyBvZiBILjI2NCBhbmQgVlA4IGFuZCB0aGF0IHdlIGFyZSBub3QgYWNoaWV2aW5nIGNvbnNl bnN1cyBvbiB0aGlzIG1vc3QgY3JpdGljYWwgY2F0ZWdvcnkuDQoNCkkgYW0gbm90IGFnYWluc3Qg YWRkaW5nIGNvZGVjcyB0byBwbGF0Zm9ybXMvc2VydmljZXMvYXBwcyBub3IgdG8gc3BlY2lmaWNh dGlvbnMuIA0KSXQgbWFrZXMgc2Vuc2Ugd2hlbiBpdCBpbXByb3ZlcyB0aGUgcXVhbGl0eSBvZiBz ZXJ2aWNlIChlLmcuIHNjYWxhYmxlLCBTRUkgZXRjKSAvY29tcHJlc3Npb24gcmF0aW8gKGUuZy4g SC4yNjUsIFZQOSkgb3Igd2hlbiBpdCBhZGRyZXNzZWQgYSB3aWRlciBlY29zeXN0ZW0gdGhhdCBp cyBjdXJyZW50bHkgbm90IGFkZHJlc3NlZC4gKGUuZy4gb3B1cykuDQoNCkluIHRoZSBjdXJyZW50 IHNpdHVhdGlvbiwgSSBkb24ndCBzZWUgVlA4IGFzIGFuIGFuc3dlciB0byBhbnkgb2YgdGhlIGFi b3ZlIGNvbnNpZGVyYXRpb25zLg0KDQpEZXNwaXRlIHRoYXQsIEkgaGF2ZSBwcm9wb3NlZCBhbiBh bHRlcm5hdGl2ZSBzb2x1dGlvbiB0aGF0IGNvbWJpbmVkIEFQSSBhdmFpbGFiaWxpdHkgYW5kIFdl YlJUQyBjYXRlZ29yaWVzLiAobm8gdGhhdCB3YXMgbm90IGRpc2N1c3NlZCBpbiB0aGlzIGZvcm0g YmVmb3JlKSBJIGJlbGlldmUgdGhhdCBwcm9wb3NhbCB3YXMvaXMgdGhlIGJlc3Qgd2F5IHRvIGlu dHJvZHVjZSBuZXcgY29kZWNzIChWUDgvSDI2NCBub3c7IGUuZy4gRGFsYWEgVlA5IGFuZCBIMjY1 IGxhdGVyKWluIGEgcmVhc29uYWJsZSBtYW5uZXIgYW5kIHdvdWxkIGhhdmUgYXZvaWRlZCB1cGZy b250ICJubywgd2UgY2FuJ3QgZG8gdGhpcyIuDQoNCkkgaG9wZSB0aGlzIGNsYXJpZmllcyB0aGF0 IHRoZSBUeXBlMyBkZWNsYXJhdGlvbiBmcm9tIE5va2lhIGlzIGZhciB0byBiZSB0aGUgb25seSBj b25jZXJuLg0KRmluYWxseSwgaWYgVlA4IGlzIHJlcXVpcmVkLCB3b3VsZCBSRiBoZWxwPw0KWWVz LCBhcyBpdCB3b3VsZCByZWR1Y2UgY29zdCBhbmQgYXMgaXQgaXMgdGhlIG1haW4gY2xhaW0gdGhh dCBwcm9wb25lbnQocykgaW50ZW5kKHMpIHRvIGRlbGl2ZXIgb24uIEkgc2VlIHRoYXQgYXMgYSBw b3NzaWJsZSBhZHZhbnRhZ2Ugb2YgVlA4IG92ZXIgSC4yNjQgd2hpY2gsIGluIG15IG9waW5pb24s IG9mZmVycyBtb3JlIGZsZXhpYmlsaXRpZXMgKHByb2ZpbGVzLCBmdW5jdGlvbnMgZXRjKS4gDQoN Cg0KR2HDq2xsZQ0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcnRj d2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb24NClNl bnQ6IE1vbmRheSwgRGVjZW1iZXIgMDgsIDIwMTQgNDowNSBBTQ0KVG86IHJ0Y3dlYkBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIEZpbmlzaGluZyB1cCB0aGUgVmlkZW8gQ29kZWMgZG9j dW1lbnQsIE1USSAoYWdhaW4sIHN0aWxsLCBzb3JyeSkNCg0KT24gTW9uLCBEZWMgMDgsIDIwMTQg YXQgMDU6MTY6MDhBTSArMDAwMCwgQW5kcmV3IEFsbGVuIHdyb3RlOg0KPiANCj4gPiBGcm9tOiBy dGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbWFu IA0KPiA+IFNocG91bnQNCj4gPiBTZW50OiBTdW5kYXksIERlY2VtYmVyIDA3LCAyMDE0IDExOjQx IEFNDQo+ID4gVG86IHJ0Y3dlYkBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBG aW5pc2hpbmcgdXAgdGhlIFZpZGVvIENvZGVjIGRvY3VtZW50LCBNVEkgDQo+ID4gKGFnYWluLCBz dGlsbCwgc29ycnkpDQo+ID4gDQo+ID4gVGhlcmUgd2VyZSBhIGxvdCBvZiBhcmd1bWVudHMgaGVy ZSBhYm91dCB0aGUgTm9raWEgSVBSIGRlY2xhcmF0aW9uIA0KPiA+IHJlZ2FyZGluZyBWUDguIElB TkFMLCBidXQgdHlwaWNhbGx5IHRoZXJlIGlzIGEgdmVyeSBzaW1wbGUgd2F5IHRvIA0KPiA+IGRl dGVybWluZSB0aGUgdmFsaWRpdHkgb2YgdGhlIElQUiBjbGFpbS4gSXQgY29tZXMgZG93biB0byBv bmUgc2ltcGxlIA0KPiA+IHF1ZXN0aW9uIC0tIEhhdmUgdGhlIHBhcnR5IGNsYWltaW5nIElQUiB2 aW9sYXRpb24gZmlsZWQgdGhlIGxhdyBzdWl0ZT8NCj4gPiBJZiBub3QsIHRoZWlyIGNsYWltcyBt b3N0IGxpa2VseSBkbyBub3QganVzdGlmeSB0aGUgY291cnQgZmlsaW5nIA0KPiA+IGZlZXMgaW4g dGhlaXIgb3duIGV5ZXMuIE1vemlsbGEgYW5kIEdvb2dsZSBoYXZlIGJlZW4gc2hpcHBpbmcgDQo+ ID4gYnJvd3NlcnMgd2l0aA0KPiA+IFZQOCBjb2RlYyBzdXBwb3J0IGZvciBzZXZlcmFsIHllYXJz IGFscmVhZHkgYW5kIE5va2lhIGRpZCBub3QgZG8gYSANCj4gPiBzaW5nbGUgdGhpbmcgdG8gc3Rv cCB0aGlzLiBJZiBOb2tpYSBpcyBzZXJpb3VzIGFib3V0IHRoZWlyIElQUiANCj4gPiBjbGFpbXMs IHRoZXkgc2hvdWxkIHRha2UgdGhlIGFsbGVnZWQgdmlvbGF0b3JzIHRvIGNvdXJ0LiBBdCBsZWFz dCANCj4gPiB0aGlzIHdheSB0aGVyZSBpcyBnb2luZyB0byBiZSBhIGRlZmluaXRpdmUgZGVjaXNp b24gcmVnYXJkaW5nIHRoZSANCj4gPiB2YWxpZGl0eSBvZiB0aGVzZSBjbGFpbXMuDQo+IA0KPiBJ IGRvbuKAmXQgdGhpbmsgdGhhdCBwcm92ZXMgYW55dGhpbmcuDQo+IA0KPiBBbnkgYmFzaWMgbWls aXRhcnkgZG9jdHJpbmUgb24gdGhlIHRhY3RpY3Mgb2YgYW1idXNoIGlzIGdvaW5nIHRvIHN0YXRl IA0KPiB0aGF0IHlvdSBkb27igJl0IGdvIGFmdGVyIHRoZSBsZWFkIGVsZW1lbnRzIGVzcGVjaWFs bHkgaWYgdGhleSBhcmUgdGhlIA0KPiBzdHJvbmdlciBhcm1vcmVkIGVsZW1lbnRzIHRoYXQgYXJl IG1vc3QgY2FwYWJsZSBvZiBiZWF0aW5nIGJhY2sgdGhlIA0KPiBhdHRhY2sg4oCTIG5vIHlvdSBi aWRlIHlvdXIgdGltZSBhbmQgd2FpdCB1bnRpbCB0aGUgZm9sbG93IG9uIHRyb29wcyANCj4gdGhh dCBhcmUgZmFyIGxlc3MgYWJsZSB0byB3aXRoc3RhbmQgdGhlIGF0dGFjayBjb21lIGFsb25nIGFu ZCB0aGVuIA0KPiBtb3VudCB5b3VyIGFzc2F1bHQg4oCTIHJpcHBpbmcgdGhlbSB0byBzaHJlYWRz IGFuZCB0aHVzIGxlYXZpbmcgdGhvc2UgDQo+IG1vcmUgcG93ZXJmdWwgbGVhZCBlbGVtZW50cyBj dXQgb2ZmIGFuZCBzdXJyb3VuZGVkIHdpdGggbm8gcGF0aCB0byANCj4gcmV0cmVhdCENCg0KV2hp bGUgdGhhdCdzIGEgdmVyeSBpbnRlcmVzdGluZyBhbmFseXNpcyBvZiB0aGUga2luZCBvZiBwYW5p Y2tlZCB0aG91Z2h0IHByb2Nlc3NlcyBnb2luZyBvbiBhbW9uZyB0aGUgcmVhcmd1YXJkIHBhcnRp Y2lwYW50cyBmcm9tIGJsYWNrYmVycnksIGl0J3Mgbm90IGNsZWFyIHRvIG1lIGV4YWN0bHkgd2hh dCByZWxldmFuY2UgeW91IHRoaW5rIGl0IGhhcyBoZXJlLg0KDQpBcmUgeW91IHNheWluZyB0aGF0 IE5va2lhIGlzIG5vdCBvbmx5IGJhZCBhdCBidXNpbmVzcywgYmFkIGF0IGtlZXBpbmcgdGhlaXIg dGFsZW50ZWQgc3RhZmYsIGFuZCBiYWQgYXQgY29tbXVuaXR5IHJlbGF0aW9ucyAtIGJ1dCB0aGF0 IHRoZXkgYWxzbyBzdWNrIGF0IG1pbGl0YXJ5IHN0cmF0ZWd5IHRvbz8NCg0KQmVjYXVzZSB0aGV5 IGxhdW5jaGVkIHRoZWlyIGF0dGFjaywgYW5kIGdvdCBsYXVnaGVkIG91dCBvZiBjb3VydCAuLi4N Cg0KaHR0cDovL2Jsb2cud2VibXByb2plY3Qub3JnLzIwMTMvMDgvZ29vZC1uZXdzLWZyb20tZ2Vy bWFueS5odG1sDQoNCg0KTWF5YmUgeW91IGFyZSBzdWdnZXN0aW5nIHRoYXQgd2FzIGp1c3QgYSBj bGV2ZXIgcnVzZSwgYW5kIHJhdGhlciB0aGFuIHVzaW5nIHRoZWlyIGFjdHVhbGx5IHZhbGlkIHBh dGVudCwgdGhleSB3YXN0ZWQgYWxsIHRoYXQgbW9uZXkgb24gbGF3eWVycyB0byBzaW1wbHkgZmVp bnQgd2l0aCB0aGUgd2Vha2VzdCBvbmUgdGhleSBjb3VsZCBmaW5kPw0KDQpJbiB3aGljaCBjYXNl IEkgaG9wZSBmb3IgdGhlaXIgc2FrZSB0aGF0IHRoZXkndmUga2VwdCB0aGVpciBnb29kIGxhd3ll cnMgaW4gcmVzZXJ2ZSBmb3Igd2hlbiB0aGVpciBzaGFyZWhvbGRlcnMgY29tZSB3YW50aW5nIHRv IHJpcCB0aGVtIHRvIHNocmVkcyENCg0KDQogIElmIGlnbm9yYW50IGJvdGggb2YgeW91ciBlbmVt eSBhbmQgeW91cnNlbGYsDQogIHlvdSBhcmUgY2VydGFpbiB0byBiZSBpbiBwZXJpbC4NCiAgICAt LSBTdW4gVHp1DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo= From nobody Mon Dec 8 08:03:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C3C1A8A43 for ; Mon, 8 Dec 2014 08:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grSUPQTKe6X7 for ; Mon, 8 Dec 2014 08:03:35 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id A63021A8768 for ; Mon, 8 Dec 2014 08:03:34 -0800 (PST) Received: from smtp-pop.rim.net (HELO XCT103CNC.rim.net) ([10.65.161.203]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 08 Dec 2014 11:03:33 -0500 Received: from XCT115CNC.rim.net (10.65.161.215) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.3.210.2; Mon, 8 Dec 2014 11:03:33 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT115CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Mon, 8 Dec 2014 11:03:32 -0500 From: Gaelle Martin-Cocher To: "rtcweb@ietf.org" Thread-Topic: WebRTC endpoint non-browser Thread-Index: AdATAH/MQNoxP+EfTdyeB/hihFTHUw== Date: Mon, 8 Dec 2014 16:03:32 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF35B076@XMB111CNC.rim.net> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/alternative; boundary="_000_92D0D52F3A63344CA478CF12DB0648AADF35B076XMB111CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9XOEbtPyVsUqfruaGtzcXC4egcs Subject: [rtcweb] WebRTC endpoint non-browser X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 16:03:41 -0000 --_000_92D0D52F3A63344CA478CF12DB0648AADF35B076XMB111CNCrimnet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, Is it possible to know who is going to develop services that belongs to the= WebRTC endpoint non-browser category? I think it would really help if we can identify that. Thanks, Ga=EBlle --_000_92D0D52F3A63344CA478CF12DB0648AADF35B076XMB111CNCrimnet_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

All,

 

Is it possible to know who is going to develop servi= ces that belongs to the WebRTC  endpoint non-browser category?

I think it would really help if we can identify that= .

Thanks,

 

Ga=EBlle





 

--_000_92D0D52F3A63344CA478CF12DB0648AADF35B076XMB111CNCrimnet_-- From nobody Mon Dec 8 08:08:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC271A9143 for ; Mon, 8 Dec 2014 08:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-6AHYYv3ZjC for ; Mon, 8 Dec 2014 08:08:06 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id C1C221A923D for ; Mon, 8 Dec 2014 08:05:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 142937C365B for ; Mon, 8 Dec 2014 17:05:50 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KC-Bg5D5JfNn for ; Mon, 8 Dec 2014 17:05:48 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:603b:7836:2531:29df] (unknown [IPv6:2001:470:de0a:27:603b:7836:2531:29df]) by mork.alvestrand.no (Postfix) with ESMTPSA id DE4DB7C3658 for ; Mon, 8 Dec 2014 17:05:47 +0100 (CET) Message-ID: <5485CC5B.2030104@alvestrand.no> Date: Mon, 08 Dec 2014 17:05:47 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4_NtnOY2zXS7hp51kOmui_nM2lA Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 16:08:08 -0000 Since others who were present in the room are repeating their position on the list, I'll do so too. I support the rough consensus as presented by the chair. Den 05. des. 2014 14:36, skrev Sean Turner: > All, > > At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about codecs, which I dubbed "the great codec compromise." The compromise text that was discussed appears in slides 12-14 at [4] (which is a slight editorial variation of the text proposed at [2]). > > This message serves to confirm the sense of the room. > > In the room, I heard the following objections and responses (and I’m paraphrasing here), which I’ll take the liberty of categorizing as IPR, Time, and Trigger: > > 1) IPR: > > Objections: There are still IPR concerns which may restrict what a particular organization feels comfortable with including in their browser implementations. > > Response: IPR concerns on this topic are well known. There is even a draft summarizing the current IPR status for VP8: draft-benham-rtcweb-vp8litigation. The sense of the room was still that adopting the compromise text was appropriate. > > 2) Time: > > 2.1) Time to consider decision: > > Objection: The decision to consider the compromise proposal at this meeting was provided on short notice and did not provide some the opportunity to attend in person. > > Response: Six months ago the chairs made it clear discussion would be revisited @ IETF 91 [0]. The first agenda proposal for the WG included this topic [1], and the topic was never removed by the chairs. More importantly, all decisions are confirmed on list; in person attendance is not required to be part of the process. > > 2.2) Time to consider text: > > Objection: The proposed text [2] is too new to be considered. > > Response: The requirement for browsers to support both VP8 and H.264 was among the options in the straw poll conducted more than six months ago. All decisions are confirmed on list so there will be ample time to discuss the proposal. > > 3) Trigger: > > Objection: The “trigger” sentence [3] is all kinds of wrong because it’s promising that the future IETF will update this specification. > > Response: Like any IETF proposal, an RFC that documents the current proposal can be changed through the consensus process at any other time. > > > After the discussion, some clarifying questions about the hums, and typing the hum questions on the screen, there was rough consensus in the room to add (aka “shove”) the proposed text into draft-ietf-rtcweb-video. In keeping with IETF process, I am confirming this consensus call on the list. > > If anyone has any other issues that they would like to raise please do by December 19th. > > Cheers, > spt (as chair) > > [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html > [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html > [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html > [3] The one that begins with "If compelling evidence ..." > [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Mon Dec 8 08:11:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3656D1A90D4 for ; Mon, 8 Dec 2014 08:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfS9VMCGQ50G for ; Mon, 8 Dec 2014 08:11:36 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876361A9122 for ; Mon, 8 Dec 2014 08:10:19 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y19so6591116wgg.0 for ; Mon, 08 Dec 2014 08:10:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=aQwBVX8eeAdCpMbeu3SgcgzjoX+Qdd9GmiM4PD92rT8=; b=eNgwJHOU9CbH4aenMZ0mlvaBR1uTn/apLzulNoWR10HO6OHFgaGOoeRPqZ+OONq/SX ozIqJqfjccShWVuaKbNq1vkkwXzOi08m9XczNk0jbAubQxhz+8tQvowGOlIgZ514ypQA pdbY2sbxTqB1v1K0nduYZy/2x7hE3I5gmvSTtXqLgP3q8hXnALcP62lxon+Zaq629sxu XCSpXsEu26WEmx4o+dyP+DJh4EsXeD3w41UvVmOm8dQK9T356A2/A2a1aoEWQdeaS+VE M33xCBqlwiXPlPEoxjRlLCW9HNNtQQl2yvMmtVH50d/gUvau2Z+TWHXLLr20eII/MqDH lI8g== X-Received: by 10.194.71.45 with SMTP id r13mr45045672wju.128.1418055018313; Mon, 08 Dec 2014 08:10:18 -0800 (PST) Received: from [192.168.0.194] ([95.61.111.78]) by mx.google.com with ESMTPSA id gy8sm10296996wib.23.2014.12.08.08.10.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Dec 2014 08:10:17 -0800 (PST) Message-ID: <5485CD70.4010605@gmail.com> Date: Mon, 08 Dec 2014 17:10:24 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <92D0D52F3A63344CA478CF12DB0648AADF35B076@XMB111CNC.rim.net> In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF35B076@XMB111CNC.rim.net> Content-Type: multipart/alternative; boundary="------------060703010309030806050004" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Ww_SAFbYTkXn5c7yXrNApsa5doo Subject: Re: [rtcweb] WebRTC endpoint non-browser X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 16:11:38 -0000 This is a multi-part message in MIME format. --------------060703010309030806050004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Native or custom applications, audio gateways, mcus, transcoders, SBCs... Best regards Sergio On 08/12/2014 17:03, Gaelle Martin-Cocher wrote: > > All, > > Is it possible to know who is going to develop services that belongs > to the WebRTC endpoint non-browser category? > > I think it would really help if we can identify that. > > Thanks, > > Gaëlle > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------060703010309030806050004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Native or custom applications, audio gateways, mcus, transcoders, SBCs...

Best regards
Sergio


On 08/12/2014 17:03, Gaelle Martin-Cocher wrote:

All,

 

Is it possible to know who is going to develop services that belongs to the WebRTC  endpoint non-browser category?

I think it would really help if we can identify that.

Thanks,

 

Gaëlle





 



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------060703010309030806050004-- From nobody Mon Dec 8 08:24:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461E11A9162 for ; Mon, 8 Dec 2014 08:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWgrx4IlKp30 for ; Mon, 8 Dec 2014 08:24:10 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 2363D1A9144 for ; Mon, 8 Dec 2014 08:24:10 -0800 (PST) Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 08 Dec 2014 11:24:09 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT108CNC.rim.net ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.03.0210.002; Mon, 8 Dec 2014 11:24:08 -0500 From: Gaelle Martin-Cocher To: Sergio Garcia Murillo , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WebRTC endpoint non-browser Thread-Index: AQHQEwGptNu+m+SBGkWau1ADvjUR4ZyF3/cw Date: Mon, 8 Dec 2014 16:24:08 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF35B132@XMB111CNC.rim.net> References: <92D0D52F3A63344CA478CF12DB0648AADF35B076@XMB111CNC.rim.net> <5485CD70.4010605@gmail.com> In-Reply-To: <5485CD70.4010605@gmail.com> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/alternative; boundary="_000_92D0D52F3A63344CA478CF12DB0648AADF35B132XMB111CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Vp9hyBKDOsyMe9ja7Qxke2oF4HA Subject: Re: [rtcweb] WebRTC endpoint non-browser X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 16:24:16 -0000 --_000_92D0D52F3A63344CA478CF12DB0648AADF35B132XMB111CNCrimnet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You are listing webrtc-compatible endpoints, not webrtc "non browser" endpo= ints. I am not asking of generic types of services but who actually belong to the= non browser endpoint category. Thanks Ga=EBlle From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio Garcia Mu= rillo Sent: Monday, December 08, 2014 11:10 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC endpoint non-browser Native or custom applications, audio gateways, mcus, transcoders, SBCs... Best regards Sergio On 08/12/2014 17:03, Gaelle Martin-Cocher wrote: All, Is it possible to know who is going to develop services that belongs to the= WebRTC endpoint non-browser category? I think it would really help if we can identify that. Thanks, Ga=EBlle _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_92D0D52F3A63344CA478CF12DB0648AADF35B132XMB111CNCrimnet_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

You are listing webrtc= -compatible endpoints, not webrtc “non browser” endpoints.=

I am not asking of gen= eric types of services but who actually belong to the non browser endpoint = category.

 

Thanks

Ga=EBlle

 

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio Garcia Murillo
Sent: Monday, December 08, 2014 11:10 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] WebRTC endpoint non-browser<= /p>

 

Native or custom applications, audio gateways, mcus,= transcoders, SBCs...

Best regards
Sergio


On 08/12/2014 17:03, Gaelle Martin-Cocher wrote:

All,

 

Is it possible to know who is going to develop servi= ces that belongs to the WebRTC  endpoint non-browser category?

I think it would really help if we can identify that= .

Thanks,

 

Ga=EBlle








 




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org

https://www.i=
etf.org/mailman/listinfo/rtcweb

 

--_000_92D0D52F3A63344CA478CF12DB0648AADF35B132XMB111CNCrimnet_-- From nobody Mon Dec 8 09:12:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA6D1AC3F2 for ; Mon, 8 Dec 2014 09:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9iObfMyrEs4 for ; Mon, 8 Dec 2014 09:12:13 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286771AC3E7 for ; Mon, 8 Dec 2014 09:12:13 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bs8so5323426wib.16 for ; Mon, 08 Dec 2014 09:12:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ckLMRPFym1s2N2APcpqGgng0MvgXzCn2Sf1Dmavypmg=; b=WLrqHBmPTmUb48rPHezHrMW1pFQeYHf7SLFFySlYjjnLEsjkBIh33Na9noMcCYsEYF t29V6ABti60UFxnR6eZusJinTUtQDRATtdXqyiANyyqrY4TseVMdhyO9+PXPs137pAkP dGUiiYR6w9YcsnwfPVrSK5FEn9afjf8FDFwid6vK8rXTRX6UcnmlMhAdtnnvOCwj1/j3 gJFPn7q5+qH3i3hHD6DW8/Rk3/6NnHh1onul/i4u58T2Ay84vpxwceudVxnFT9yOS8r1 TfwvimzgMgysv2SGtIIP85QS3PEDh3QPTKQh/pdv9GNt2eHwMpCFCHpgeZ99rBAshOxo 2e0w== X-Gm-Message-State: ALoCoQmHWRKyP+waOP0PjBlR0QGZtff3O6RloHJYicfpL8As45evpyxhbrj/j2CXdVVGcyo83cC5 MIME-Version: 1.0 X-Received: by 10.194.119.193 with SMTP id kw1mr47009956wjb.37.1418058731846; Mon, 08 Dec 2014 09:12:11 -0800 (PST) Received: by 10.194.6.39 with HTTP; Mon, 8 Dec 2014 09:12:11 -0800 (PST) In-Reply-To: <5485CC5B.2030104@alvestrand.no> References: <5485CC5B.2030104@alvestrand.no> Date: Mon, 8 Dec 2014 19:12:11 +0200 Message-ID: From: Mohammed Raad To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e01228626fb996c0509b786b6 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6UrgnGEF9sMJ5HxQVmSQMuLxc7A Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 17:12:16 -0000 --089e01228626fb996c0509b786b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I also support the rough consensus reached by those attending the meeting. Mohammed On Mon, Dec 8, 2014 at 6:05 PM, Harald Alvestrand wrote: > Since others who were present in the room are repeating their position > on the list, I'll do so too. > > I support the rough consensus as presented by the chair. > > > > Den 05. des. 2014 14:36, skrev Sean Turner: > > All, > > > > At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion abou= t > codecs, which I dubbed "the great codec compromise." The compromise text > that was discussed appears in slides 12-14 at [4] (which is a slight > editorial variation of the text proposed at [2]). > > > > This message serves to confirm the sense of the room. > > > > In the room, I heard the following objections and responses (and I=E2= =80=99m > paraphrasing here), which I=E2=80=99ll take the liberty of categorizing a= s IPR, > Time, and Trigger: > > > > 1) IPR: > > > > Objections: There are still IPR concerns which may restrict what a > particular organization feels comfortable with including in their browser > implementations. > > > > Response: IPR concerns on this topic are well known. There is even a > draft summarizing the current IPR status for VP8: > draft-benham-rtcweb-vp8litigation. The sense of the room was still that > adopting the compromise text was appropriate. > > > > 2) Time: > > > > 2.1) Time to consider decision: > > > > Objection: The decision to consider the compromise proposal at this > meeting was provided on short notice and did not provide some the > opportunity to attend in person. > > > > Response: Six months ago the chairs made it clear discussion would be > revisited @ IETF 91 [0]. The first agenda proposal for the WG included th= is > topic [1], and the topic was never removed by the chairs. More > importantly, all decisions are confirmed on list; in person attendance is > not required to be part of the process. > > > > 2.2) Time to consider text: > > > > Objection: The proposed text [2] is too new to be considered. > > > > Response: The requirement for browsers to support both VP8 and H.264 wa= s > among the options in the straw poll conducted more than six months ago. > All decisions are confirmed on list so there will be ample time to discus= s > the proposal. > > > > 3) Trigger: > > > > Objection: The =E2=80=9Ctrigger=E2=80=9D sentence [3] is all kinds of w= rong because it=E2=80=99s > promising that the future IETF will update this specification. > > > > Response: Like any IETF proposal, an RFC that documents the current > proposal can be changed through the consensus process at any other time. > > > > > > After the discussion, some clarifying questions about the hums, and > typing the hum questions on the screen, there was rough consensus in the > room to add (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draft-ie= tf-rtcweb-video. > In keeping with IETF process, I am confirming this consensus call on the > list. > > > > If anyone has any other issues that they would like to raise please do > by December 19th. > > > > Cheers, > > spt (as chair) > > > > [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html > > [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html > > [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html > > [3] The one that begins with "If compelling evidence ..." > > [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf > > _______________________________________________ > > 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 > --=20 Mohammed Raad, PhD. Partner RAADTECH CONSULTING P.O. Box 113 Warrawong NSW 2502 Australia Phone: +61 414451478 Email: mohammedsraad@raadtech.com --089e01228626fb996c0509b786b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also support the rough consensus reached by those attend= ing the meeting.

Mohammed

On Mon, Dec 8, 2014 at 6:05 PM, Hara= ld Alvestrand <harald@alvestrand.no> wrote:
Since others who were present in the room are repeatin= g their position
on the list, I'll do so too.

I support the rough consensus as presented by the chair.



Den 05. des. 2014 14:36, skrev Sean Turner:
> All,
>
> At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion abo= ut codecs, which I dubbed "the great codec compromise."=C2=A0 The= compromise text that was discussed appears in slides 12-14 at [4] (which i= s a slight editorial variation of the text proposed at [2]).
>
> This message serves to confirm the sense of the room.
>
> In the room, I heard the following objections and responses (and I=E2= =80=99m paraphrasing here), which I=E2=80=99ll take the liberty of categori= zing as IPR, Time, and Trigger:
>
> 1) IPR:
>
> Objections: There are still IPR concerns which may restrict what a par= ticular organization feels comfortable with including in their browser impl= ementations.
>
> Response:=C2=A0 IPR concerns on this topic are well known.=C2=A0 There= is even a draft summarizing the current IPR status for VP8: draft-benham-r= tcweb-vp8litigation.=C2=A0 The sense of the room was still that adopting th= e compromise text was appropriate.
>
> 2) Time:
>
> 2.1) Time to consider decision:
>
> Objection: The decision to consider the compromise proposal at this me= eting was provided on short notice and did not provide some the opportunity= to attend in person.
>
> Response:=C2=A0 Six months ago the chairs made it clear discussion wou= ld be revisited @ IETF 91 [0]. The first agenda proposal for the WG include= d this topic [1], and the topic was never removed by the chairs.=C2=A0 =C2= =A0 More importantly, all decisions are confirmed on list; in person attend= ance is not required to be part of the process.
>
> 2.2) Time to consider text:
>
> Objection: The proposed text [2] is too new to be considered.
>
> Response: The requirement for browsers to support both VP8 and H.264 w= as among the options in the straw poll conducted more than six months ago.= =C2=A0 All decisions are confirmed on list so there will be ample time to d= iscuss the proposal.
>
> 3) Trigger:
>
> Objection: The =E2=80=9Ctrigger=E2=80=9D sentence [3] is all kinds of = wrong because it=E2=80=99s promising that the future IETF will update this = specification.
>
> Response: Like any IETF proposal, an RFC that documents the current pr= oposal can be changed through the consensus process at any other time.
>
>
> After the discussion, some clarifying questions about the hums, and ty= ping the hum questions on the screen, there was rough consensus in the room= to add (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draft-ietf-rtc= web-video.=C2=A0 In keeping with IETF process, I am confirming this consens= us call on the list.
>
> If anyone has any other issues that they would like to raise please do= by December 19th.
>
> Cheers,
> spt (as chair)
>
> [0] http://www.ietf.org/mail-archive/web/rtcweb/c= urrent/msg11194.html
> [1] http://www.ietf.org/mail-archive/web/rtcweb/c= urrent/msg13150.html
> [2] http://www.ietf.org/mail-archive/web/rtcweb/c= urrent/msg13432.html
> [3] The one that begins with "If compelling evidence ..." > [4] http://www.ietf.org/proceedings/91/slides/slid= es-91-rtcweb-7.pdf
> _______________________________________________
> 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



--
=
Mohammed Raad, PhD.
Partner
RAADTECH C= ONSULTING
P.O. Box 113
Warrawong
NSW 2502 Australia
Phone: +61 = 414451478
Email: mohammedsraad@raadtech.com
--089e01228626fb996c0509b786b6-- From nobody Mon Dec 8 09:23:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65581AC42C for ; Mon, 8 Dec 2014 09:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4G9kgowEUhws for ; Mon, 8 Dec 2014 09:22:44 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4722C1AC430 for ; Mon, 8 Dec 2014 09:22:44 -0800 (PST) Received: from [10.252.28.147] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id E10FEF20F7 for ; Mon, 8 Dec 2014 09:22:43 -0800 (PST) Message-ID: <5485DE63.7060508@mozilla.com> Date: Mon, 08 Dec 2014 09:22:43 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5485CC5B.2030104@alvestrand.no> In-Reply-To: <5485CC5B.2030104@alvestrand.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AfdaXM95CXA-HZ3euslbLbvjlZs Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 17:22:48 -0000 Harald Alvestrand wrote: > Since others who were present in the room are repeating their position > on the list, I'll do so too. > > I support the rough consensus as presented by the chair. +1 I had hoped to spare people's inboxes, but for the convenience of the chairs, everything I said in still applies to this thread. From nobody Mon Dec 8 09:23:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8321AC44E for ; Mon, 8 Dec 2014 09:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwsbSf8NgXfp for ; Mon, 8 Dec 2014 09:23:45 -0800 (PST) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46FF1AC446 for ; Mon, 8 Dec 2014 09:23:36 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id x3so3764664qcv.22 for ; Mon, 08 Dec 2014 09:23:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=jPahk46RlK8IGBTBgQ4F3wj+PmkAlMOd7aBaqMkmH5U=; b=dedSmDjbMYkO8x12BkTivyHwJyTI0fI4aG4FsvkwY4sRNkz0iGg0PK9r0i0MPIR7F6 Qo+TsA7211oQLVGiGpdiqyWMNzAEC3QRp3Mwp2oJ+C4ultd+2F/1eN97u/M5qKIf2QFW zAxj50u6NfPZfZSfZXex0zXNAVsxbop+RfP7qRhALI7LyAH1lxtz8GH5gRPlVPqR5c+0 Hcra2ssFCl+wpI3//UgDIz+58VPsOhNR/A0KQtNlMCmerQqxKJojhH8E+mANyJt34QpY FOifGJNXhokB9dkKzpgnw7PmIApAlE2Yo5iC7nHQzNRbHTVZB5BuUVMYh9BLCbpOvmu+ XQAw== X-Gm-Message-State: ALoCoQnjkT25YUiRpC5e5c2aw5vrcL0/Rfdfkvsy7IDQuJW1/N5OOnpM4cPdpBv4P9s7G5iQ/c7I X-Received: by 10.140.36.168 with SMTP id p37mr52148700qgp.101.1418059416195; Mon, 08 Dec 2014 09:23:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Mon, 8 Dec 2014 09:23:15 -0800 (PST) In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF35B132@XMB111CNC.rim.net> References: <92D0D52F3A63344CA478CF12DB0648AADF35B076@XMB111CNC.rim.net> <5485CD70.4010605@gmail.com> <92D0D52F3A63344CA478CF12DB0648AADF35B132@XMB111CNC.rim.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 8 Dec 2014 18:23:15 +0100 Message-ID: To: Gaelle Martin-Cocher Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4-wf2EuDWcEL4WVjzvvCYT-6EaI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC endpoint non-browser X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 17:23:46 -0000 2014-12-08 17:24 GMT+01:00 Gaelle Martin-Cocher : > You are listing webrtc-compatible endpoints, not webrtc =E2=80=9Cnon brow= ser=E2=80=9D > endpoints. > > I am not asking of generic types of services but who actually belong to t= he > non browser endpoint category. If you build a mobile native app with WebRTC capabilities (using a WebRTC library or your own one) then that is a "non browser" WebRTC endpoint. --=20 I=C3=B1aki Baz Castillo From nobody Mon Dec 8 09:24:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B02F1AC42A for ; Mon, 8 Dec 2014 09:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 369GEdxGrO_R for ; Mon, 8 Dec 2014 09:24:13 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A8AC1AC442 for ; Mon, 8 Dec 2014 09:24:13 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id dc16so3589172qab.39 for ; Mon, 08 Dec 2014 09:24:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qOs/NZMj72xwracDELL6gmoShQxbnY+qAUao30GDZXc=; b=S6rH1NtSX674SjWQgetgwA9ev5gV9J5hd6v1u2nmC6jzZ0ZrnTBibHFzVQr5y2c5Fx R5Gz/dAFGpb6xxTmTi7cOblHD/egMXOlo1+xIW7v6oS7nW0q3IT4ffFZdIkFpAxxKGSE bZqCmQitVohIPyx/ALWXIowczDg1KlXCNOcRMg1I5NN4xz5b1UKMAHNo9S7PvirCJgSY dg2RsXJ2T25OsVEDB9nIHiZ21ewGMQ1+cEvL40JAqAsHqzuvB34hol9oV954g1v6S/Jv nUsAXV523QzTeQDxxNycpDcSD1PG1sza+O96XtLyyyeOOI7NXVj3S09T4i/pQ6eDbWIN TRVw== X-Gm-Message-State: ALoCoQmeBSjDT83E7QD2CXIGJ78AxS5sgjukPGJqx7dVyJ5K3qxDToFcc0zP0HQrMgorRHgvd8za X-Received: by 10.224.40.72 with SMTP id j8mr55375789qae.59.1418059452137; Mon, 08 Dec 2014 09:24:12 -0800 (PST) Received: from [10.0.0.38] (c-76-100-94-44.hsd1.md.comcast.net. [76.100.94.44]) by mx.google.com with ESMTPSA id d2sm38366234qab.24.2014.12.08.09.24.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Dec 2014 09:24:11 -0800 (PST) Message-ID: <5485DEBA.7050504@dgql.org> Date: Mon, 08 Dec 2014 12:24:10 -0500 From: Nathan Egge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121208 Thunderbird/10.0.10 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5485CC5B.2030104@alvestrand.no> In-Reply-To: <5485CC5B.2030104@alvestrand.no> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2dq761VOZgqygywcQe_YEqSswNA Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 17:24:15 -0000 +1 > Since others who were present in the room are repeating their position > on the list, I'll do so too. > > I support the rough consensus as presented by the chair. > From nobody Mon Dec 8 09:24:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9751ACC87 for ; Mon, 8 Dec 2014 09:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJJXG7UmUTmM for ; Mon, 8 Dec 2014 09:24:33 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 603151AC447 for ; Mon, 8 Dec 2014 09:24:33 -0800 (PST) Received: from xct103cnc.rim.net ([10.65.161.203]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 08 Dec 2014 12:24:27 -0500 Received: from XCT113CNC.rim.net (10.65.161.213) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.3.210.2; Mon, 8 Dec 2014 12:24:26 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT113CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Mon, 8 Dec 2014 12:24:26 -0500 From: Gaelle Martin-Cocher To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] WebRTC endpoint non-browser Thread-Index: AQHQEwGptNu+m+SBGkWau1ADvjUR4ZyF3/cwgABlJID//6x0EA== Date: Mon, 8 Dec 2014 17:24:25 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF35B343@XMB111CNC.rim.net> References: <92D0D52F3A63344CA478CF12DB0648AADF35B076@XMB111CNC.rim.net> <5485CD70.4010605@gmail.com> <92D0D52F3A63344CA478CF12DB0648AADF35B132@XMB111CNC.rim.net> In-Reply-To: Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cruNzRrTPBkQeP2RnnPZvIoxHxU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC endpoint non-browser X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 17:24:34 -0000 QXJlIHlvdSBidWlsZGluZyBzdWNoIGFwcD8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IEnDsWFraSBCYXogQ2FzdGlsbG8gW21haWx0bzppYmNAYWxpYXgubmV0XSANClNlbnQ6 IE1vbmRheSwgRGVjZW1iZXIgMDgsIDIwMTQgMTI6MjMgUE0NClRvOiBHYWVsbGUgTWFydGluLUNv Y2hlcg0KQ2M6IFNlcmdpbyBHYXJjaWEgTXVyaWxsbzsgcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3J0Y3dlYl0gV2ViUlRDIGVuZHBvaW50IG5vbi1icm93c2VyDQoNCjIwMTQtMTItMDgg MTc6MjQgR01UKzAxOjAwIEdhZWxsZSBNYXJ0aW4tQ29jaGVyIDxnbWFydGluY29jaGVyQGJsYWNr YmVycnkuY29tPjoNCj4gWW91IGFyZSBsaXN0aW5nIHdlYnJ0Yy1jb21wYXRpYmxlIGVuZHBvaW50 cywgbm90IHdlYnJ0YyDigJxub24gYnJvd3NlcuKAnQ0KPiBlbmRwb2ludHMuDQo+DQo+IEkgYW0g bm90IGFza2luZyBvZiBnZW5lcmljIHR5cGVzIG9mIHNlcnZpY2VzIGJ1dCB3aG8gYWN0dWFsbHkg YmVsb25nIA0KPiB0byB0aGUgbm9uIGJyb3dzZXIgZW5kcG9pbnQgY2F0ZWdvcnkuDQoNCklmIHlv dSBidWlsZCBhIG1vYmlsZSBuYXRpdmUgYXBwIHdpdGggV2ViUlRDIGNhcGFiaWxpdGllcyAodXNp bmcgYSBXZWJSVEMgbGlicmFyeSBvciB5b3VyIG93biBvbmUpIHRoZW4gdGhhdCBpcyBhICJub24g YnJvd3NlciIgV2ViUlRDIGVuZHBvaW50Lg0KDQoNCg0KLS0NCknDsWFraSBCYXogQ2FzdGlsbG8N CjxpYmNAYWxpYXgubmV0Pg0K From nobody Mon Dec 8 09:26:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC091ACC83 for ; Mon, 8 Dec 2014 09:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljFB5Cd65qHS for ; Mon, 8 Dec 2014 09:26:00 -0800 (PST) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C011B1AC42A for ; Mon, 8 Dec 2014 09:25:59 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id b13so4193178qcw.20 for ; Mon, 08 Dec 2014 09:25:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=OYIa7XmPBy6SPpKkC4SMjFcfacuITJH7dlbpPxmbiC8=; b=bOFSa8L6Hv9/TibY3cxqXq2yb1R+i0v9FzqfrM15nAsQNrRIktXCfCMzD9GRIzZeNJ H4yM85BoUyfhRr+4GfCeICJZ0HQVUHXEkAB75pNZM86+6pZVzFLem5vVrlkOIGNHvh/2 TxguIC9DUfpfjTnX2EC5dN85rZ9py9C6wY+pcyIdKuNcMOjyaXBwz0vTty9k9Ahv++B1 PSZVbJ5gGFR/DGOf5JuaqTV97jodboLAYR7J7gOqS7DQ8zpfnLrl/5DPjapEn54qwthi GsfK7lhYhkveFtj3uU/SLaJvRM3F9DJWxwLjUBghJonfuqG7bhMxKiz3j8VhC5wiO4nd NTmA== X-Gm-Message-State: ALoCoQnF1aSnMw/ATNu20+gUJ8GwsRLJchPRCyY8NXpUXLPQZQHBRZCPCCt/zyyhCaVYnT7Wxpzh X-Received: by 10.224.160.212 with SMTP id o20mr56679829qax.57.1418059559045; Mon, 08 Dec 2014 09:25:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Mon, 8 Dec 2014 09:25:38 -0800 (PST) In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF35B343@XMB111CNC.rim.net> References: <92D0D52F3A63344CA478CF12DB0648AADF35B076@XMB111CNC.rim.net> <5485CD70.4010605@gmail.com> <92D0D52F3A63344CA478CF12DB0648AADF35B132@XMB111CNC.rim.net> <92D0D52F3A63344CA478CF12DB0648AADF35B343@XMB111CNC.rim.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 8 Dec 2014 18:25:38 +0100 Message-ID: To: Gaelle Martin-Cocher Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HACQYDpiMMmri-2plbINl0pmR8g Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC endpoint non-browser X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 17:26:00 -0000 2014-12-08 18:24 GMT+01:00 Gaelle Martin-Cocher : > Are you building such app? Does it matter? --=20 I=C3=B1aki Baz Castillo From nobody Mon Dec 8 09:26:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484111AC3F2 for ; Mon, 8 Dec 2014 09:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.281 X-Spam-Level: X-Spam-Status: No, score=0.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXy1JQOlzeZZ for ; Mon, 8 Dec 2014 09:26:21 -0800 (PST) Received: from smtpcmd02102.aruba.it (smtpcmd02102.aruba.it [62.149.158.102]) by ietfa.amsl.com (Postfix) with ESMTP id CBF2D1ACCDA for ; Mon, 8 Dec 2014 09:26:20 -0800 (PST) Received: from android-8f633aaf6de55e4c ([79.9.157.122]) by smtpcmd02.ad.aruba.it with bizsmtp id R5Rt1p00B2ejfy7015S9fF; Mon, 08 Dec 2014 18:26:19 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF35B343@XMB111CNC.rim.net> References: <92D0D52F3A63344CA478CF12DB0648AADF35B076@XMB111CNC.rim.net> <5485CD70.4010605@gmail.com> <92D0D52F3A63344CA478CF12DB0648AADF35B132@XMB111CNC.rim.net> <92D0D52F3A63344CA478CF12DB0648AADF35B343@XMB111CNC.rim.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----F6B8J8IZ5K6SXQY4ZPFM999BYKXL1J" Content-Transfer-Encoding: 8bit From: Lorenzo Miniero Date: Mon, 08 Dec 2014 18:25:44 +0100 To: Gaelle Martin-Cocher , =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Message-ID: <9EE9BFFF-9C24-4FA2-96BB-41D5363F6006@meetecho.com> Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_TkXYvl_QCQ3IgjP17TV6Qtj65g Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC endpoint non-browser X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 17:26:23 -0000 ------F6B8J8IZ5K6SXQY4ZPFM999BYKXL1J Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Many of us are, L. Il 08 dicembre 2014 18:24:25 CET, Gaelle Martin-Cocher ha scritto: >Are you building such app? > >-----Original Message----- >From: Iñaki Baz Castillo [mailto:ibc@aliax.net] >Sent: Monday, December 08, 2014 12:23 PM >To: Gaelle Martin-Cocher >Cc: Sergio Garcia Murillo; rtcweb@ietf.org >Subject: Re: [rtcweb] WebRTC endpoint non-browser > >2014-12-08 17:24 GMT+01:00 Gaelle Martin-Cocher >: >> You are listing webrtc-compatible endpoints, not webrtc “non browser†>> endpoints. >> >> I am not asking of generic types of services but who actually belong >> to the non browser endpoint category. > >If you build a mobile native app with WebRTC capabilities (using a >WebRTC library or your own one) then that is a "non browser" WebRTC >endpoint. > > > >-- >Iñaki Baz Castillo > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb -- Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. ------F6B8J8IZ5K6SXQY4ZPFM999BYKXL1J Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Many of us are,

L.

Il 08 dicembre 2014 18:24:25 CET, Gaelle Martin-Cocher <gmartincocher@blackberry.com> ha scritto:
Are you building such app?

-----Original Message-----
From: Iñaki Baz Castillo [mailto:ibc@aliax.net] 
Sent: Monday, December 08, 2014 12:23 PM
To: Gaelle Martin-Cocher
Cc: Sergio Garcia Murillo; rtcweb@ietf.org
Subject: Re: [rtcweb] WebRTC endpoint non-browser

2014-12-08 17:24 GMT+01:00 Gaelle Martin-Cocher <gmartincocher@blackberry.com>:
 You are listing webrtc-compatible endpoints, not webrtc “non browserâ€
 endpoints.

 I am not asking of generic types of services but who actually belong 
 to the non browser endpoint category.

If you build a mobile native app with WebRTC capabilities (using a WebRTC library or your own one) then that is a "non browser" WebRTC endpoint.



--
Iñaki Baz Castillo
<ibc@aliax.net>

rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. ------F6B8J8IZ5K6SXQY4ZPFM999BYKXL1J-- From nobody Mon Dec 8 09:27:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6832C1AC418 for ; Mon, 8 Dec 2014 09:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id st_PsKDflWQP for ; Mon, 8 Dec 2014 09:27:05 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004B91AC3F2 for ; Mon, 8 Dec 2014 09:27:04 -0800 (PST) Received: by mail-oi0-f52.google.com with SMTP id h136so3674838oig.11 for ; Mon, 08 Dec 2014 09:27:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lrvOy2f3gEm7y16UBavheIm9yTAK/+Ghy8Ft1gAP0oE=; b=CYp7Tbd+3NkR/MJoLiXSHwYSo7KHcAEJUWYGrTAT+RLFj0oxaZ5SfJ1rXLMHCJYAvf 5Hue7HNt5RxKXOiS6dRGMS/NW6SPej/x28eeff7D7nSUByWxEUQcqDSVdBtLAkN7TEY1 oRtCYQ/gv5Aj3fXl4zBhyQJqdFBTdGHFF2V5h8F5JMIf2BWxbW8dafq5tp85cZUBkYDd kyrR1Qwq8Qs3KPdCgmhjmRRO1AepMH553hcuyVZL4L65TlEPcvtapqvZih5e9/JeI4Em mKKUpOXZ134UzdU2cuVdWt67a9KtN0/txYrVsIEM+LB/z0XGJ4SOYXWyCaHqqtnQbzFf KXHQ== MIME-Version: 1.0 X-Received: by 10.202.212.82 with SMTP id l79mr7628183oig.12.1418059624252; Mon, 08 Dec 2014 09:27:04 -0800 (PST) Received: by 10.202.115.4 with HTTP; Mon, 8 Dec 2014 09:27:04 -0800 (PST) In-Reply-To: <5485CC5B.2030104@alvestrand.no> References: <5485CC5B.2030104@alvestrand.no> Date: Mon, 8 Dec 2014 09:27:04 -0800 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YjTebijHNNjQ2T2M23zWhbTLM1Q Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 17:27:06 -0000 On 8 December 2014 at 08:05, Harald Alvestrand wrote: > Since others who were present in the room are repeating their position > on the list, I'll do so too. That's probably a good thing to do. An almost anonymous humming sound isn't a good basis for establishing a record. > I support the rough consensus as presented by the chair. +1 From nobody Mon Dec 8 09:40:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE301A875D for ; Mon, 8 Dec 2014 09:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZKwKMXf6kSC for ; Mon, 8 Dec 2014 09:40:17 -0800 (PST) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7711A1B76 for ; Mon, 8 Dec 2014 09:40:16 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id hy4so2386905vcb.2 for ; Mon, 08 Dec 2014 09:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aSrV+JR3Oi9zw/utAInGRr4YdOPfg6y611xR8OrKclU=; b=DgH0Uxavptp+X0TIhu8wm0pdzpf6ResSGSUcspqVwqf7NxcmxMPfKIPs7LvITLzrNP le6k+GEynIq97+RbiCgrpOdzRFskEzmaubCkZsJy5loXq3ehjUbFVus+8XR5XsmsEM10 TnJJbNunHLtUt9V1AL1m1v8CjnI79bClhFYFHIrtDkf6h2uj+zEpuskGcmN3EIdgBpVx ia6M5LrlPYTyqCIojHn1Kp4mqoQjYI7g3DlBB/0rrtMPtJuB9ZQRvUIx05Zv3JPG+QDx JLhi3JOTrnMiNhn38tLfTtNJV6bequi2Ad/6U7s1hSlJNUqWxLeVNvutYJ+IopzKRNHH qMFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aSrV+JR3Oi9zw/utAInGRr4YdOPfg6y611xR8OrKclU=; b=Mf7IvQku5QNJkXlAKtr8Tnj+EhwNAOHJ8IFn4vt69zeA9NT6FTkzb+QEK1ieTfgi0h urqLLHaMW51sxWbeAs9qKcaPBLOAo3+HxqWH3lIo5Bq9WP2JQd4lHrvSYaEHid08HzRz /sF3OCpjmqtoVe9yavTANHcOaG4tz2U8NLXPMmEq+xMrxfs9EyzyNLQcQR8fX8DXt25R t5U039f5W9GtUAoD4w2Gtfh7FMMlsdEOQEQVpOCApuAUfTRhBPt6J0AWB+2Ml4CFUgw8 FKD/d84yAW/0bSRc4lqqo2ntZHriELkY6ptr1CwQvSozkx2uCpCl16aA5Tt+O+CfJRvO 4sfA== X-Gm-Message-State: ALoCoQklTfRQB34VTjvT5bEnybFzvpLkE34g+Jy8/gwsnFV7T4cEVDSkpgr8Z1liqyFFHP437WR4 X-Received: by 10.52.10.198 with SMTP id k6mr22006003vdb.38.1418060416086; Mon, 08 Dec 2014 09:40:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Mon, 8 Dec 2014 09:39:55 -0800 (PST) In-Reply-To: References: <5485CC5B.2030104@alvestrand.no> From: Justin Uberti Date: Mon, 8 Dec 2014 09:39:55 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=20cf30334e255f194b0509b7ebf1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ezRd3eOf6bD6rpVoWoNHpjEFyvY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 17:40:18 -0000 --20cf30334e255f194b0509b7ebf1 Content-Type: text/plain; charset=UTF-8 I support the rough consensus as presented by the chair. As stated before - I think this plan represents a legitimate compromise in what had previously seemed like a stalemate. While not my ideal outcome, I think this is good for the WebRTC ecosystem - it ensures interoperability, and provides a reasonably clear path for reaching a completely RF solution. On Mon, Dec 8, 2014 at 9:27 AM, Martin Thomson wrote: > On 8 December 2014 at 08:05, Harald Alvestrand > wrote: > > Since others who were present in the room are repeating their position > > on the list, I'll do so too. > > That's probably a good thing to do. An almost anonymous humming sound > isn't a good basis for establishing a record. > > > I support the rough consensus as presented by the chair. > > +1 > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf30334e255f194b0509b7ebf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the= rough consensus as presented by the chair.=C2=A0

As stated before -=C2=A0I think this plan represents a legitimate compromis= e in what had previously seemed like a stalemate. While not my ideal outcom= e, I think this is good for the WebRTC ecosystem - it ensures interoperabil= ity, and provides a reasonably clear path for reaching a completely RF solu= tion.

On Mon, Dec 8, 2014 at 9:27 AM, Martin Thomson <= ;martin.thoms= on@gmail.com> wrote:
On 8 December 2014 at 08:05, Harald Alvestrand <harald@alvestrand.no> wrote:
> Since others who were present in the room are repeating their position=
> on the list, I'll do so too.

That's probably a good thing to do.=C2=A0 An almost anonymous hu= mming sound
isn't a good basis for establishing a record.

> I support the rough consensus as presented by the chair.

+1

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--20cf30334e255f194b0509b7ebf1-- From nobody Mon Dec 8 09:44:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640F11A1AAE for ; Mon, 8 Dec 2014 09:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6KRM-SqdGO5 for ; Mon, 8 Dec 2014 09:44:37 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFDE61A1BE6 for ; Mon, 8 Dec 2014 09:44:26 -0800 (PST) Received: by mail-oi0-f46.google.com with SMTP id h136so3677380oig.33 for ; Mon, 08 Dec 2014 09:44:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LzrkPsKAQ7Q8jgEvAjItl0K8llKkvHNajQXV4RhOEic=; b=ZiUsG9MJh67T7bSDnrZUjzCTKpA62WAiLREWDkKoQxfcAPN9M/VpbrDNw75Iy1qdrT td66Jt3eNyCxpDQz3fp+fvlQexXF3figIYue8BcRecJ8asJBmaqcOpajEWbW13KoK1OW XNqAqzciqQJX4tTVFpCOPlXNRqeabpPyP69nSI4UycQlJh429279Gu4KokR+aLBUJnWZ +s78yTCArEy2cObtsB/QA6OqAwztD/Z5WfR6CChyXVlA4ey3zkfpUV0Gu7X7zkrARIjz 4bWJWAakGat1QD1vl9BPQUbU4TNLfBQy0v6eQfn9rZ1cS+IafCo9i0J8h+NP+qf0QpS6 Qi1A== MIME-Version: 1.0 X-Received: by 10.182.104.40 with SMTP id gb8mr20631304obb.61.1418060666060; Mon, 08 Dec 2014 09:44:26 -0800 (PST) Received: by 10.202.115.4 with HTTP; Mon, 8 Dec 2014 09:44:25 -0800 (PST) In-Reply-To: References: <5485CC5B.2030104@alvestrand.no> Date: Mon, 8 Dec 2014 09:44:25 -0800 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ds3PoXwaWbE6ggHUnlpXpsWOw6k Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 17:44:48 -0000 On 8 December 2014 at 09:39, Justin Uberti wrote: > As stated before - I think this plan represents a legitimate compromise in > what had previously seemed like a stalemate. While not my ideal outcome, I > think this is good for the WebRTC ecosystem - it ensures interoperability, > and provides a reasonably clear path for reaching a completely RF solution. "It has been said that democracy is the worst form of government except all the others that have been tried." From nobody Mon Dec 8 09:45:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DBA1A1B76 for ; Mon, 8 Dec 2014 09:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TchFb4CgZhO for ; Mon, 8 Dec 2014 09:44:21 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2F61A1A23 for ; Mon, 8 Dec 2014 09:44:21 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id k15so3594901qaq.24 for ; Mon, 08 Dec 2014 09:44:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=/FCfss0I6Ulya7/wZR+MoUDrUdrN4DbA5EJtxX++VLE=; b=HG5JmNc5abpqUi2eDdWjKk/J7O2ymsX09kVo0r4AgqqEqKlVCMsfdr41pz9yAErdta /P59TswkK2GU3PfmvB2Ivpox+P2C4ZhGe8O1dKWINCf3ixHfbTHcEk8xn6a0R3rGC74L cLrxaozu3c842LBgFnZetM8Cx01TQmtYRr2/EOKdciYZyLss8iRW923Rnltp3jh1MD8X Pu2M4suvOSur8eM8uzp8kpi2vBh96JveykEPmyRh4an7/06hBz4SnWcSMU2eGWT/ZRJX x3m46Rs4fg7jaodsiIbuQEOUyksxM4YavBSjb9Z+LV64Bd3XDF1FWtzxZ9r1ISaJOc6U GlYQ== X-Gm-Message-State: ALoCoQnTkhsWuZn974Tx9XtKOFRlE0UXsBmkGhXWYuHCK9ROlQBzqs6tuVcrjk5tWaoriV1WVgz1 X-Received: by 10.140.81.6 with SMTP id e6mr53415569qgd.90.1418060660275; Mon, 08 Dec 2014 09:44:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Mon, 8 Dec 2014 09:43:59 -0800 (PST) In-Reply-To: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 8 Dec 2014 18:43:59 +0100 Message-ID: To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KXWjRDy8xtqRsoL3ywEwc3cjIpQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 17:45:02 -0000 2014-12-05 20:55 GMT+01:00 Ted Hardie : > This is fundamentally incorrect. The IETF writes voluntary standards. A > MUST in an IETF standard is not an instruction to a company; it is a > description of the expected behaviour of an interoperable implementation. > You are not required to implement the standard at all. At most, it is a > description of what someone who claimed compliance to the standard is > expected to have done. Let's imagine I want to build a new open-source browser from scratch in my spare time. Basically (if I was smart enough) I could conform with all the W3C specs... Really? can I safely include VP8 and H264 (existing libraries or my own implementation of both) into my open-source browser and publish the project and its source code? The "MUST implement VP8 and H264" is a break line in the W3C, meaning that from now on just big vendors (those who can deal with licensing stuff) can conform with the specifications. And that is no good at all. --=20 I=C3=B1aki Baz Castillo From nobody Mon Dec 8 09:49:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F068C1ACD32 for ; Mon, 8 Dec 2014 09:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgLLpsQ31PF2 for ; Mon, 8 Dec 2014 09:49:40 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C52C1A1AAE for ; Mon, 8 Dec 2014 09:49:40 -0800 (PST) Received: by mail-oi0-f47.google.com with SMTP id v63so3711665oia.6 for ; Mon, 08 Dec 2014 09:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SDqW5utsUQxSDI0fDwARc/TByr0BqA8qNZN3oDYZUH8=; b=t0COnYq4Wl3XXvWnBON/M78v/gEUCUJ0kxnGMz4rIN+WtDblSAMsCUPmOJGyJJnVNv FPROTmFEZoSbHdkGlcS02TlwfZ9pINe0Spyrwce2plHRtLFtZca1QWCGRTdPdkBkBHdR p61K0df+GeuuVVoLJkNtfig0O1Twr6oE1ZaBh6Q8z/1w+BWMNHJACLb0Aye7Fddu900U Gjk3bfuasATyhVrif5l5iVQxSVaUyoiw1tcvMtPW/Cf8R+8B97bUx7FYWtbMHWqJ+Wwi 21wejdr5ORm3YoBW4aXN+iBInbqwFTOYmHt3ROxOX3JnqyXJRZ+HCft5HY0qRRKJeqqu w2+w== MIME-Version: 1.0 X-Received: by 10.182.104.40 with SMTP id gb8mr20647546obb.61.1418060979796; Mon, 08 Dec 2014 09:49:39 -0800 (PST) Received: by 10.202.115.4 with HTTP; Mon, 8 Dec 2014 09:49:39 -0800 (PST) In-Reply-To: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> Date: Mon, 8 Dec 2014 09:49:39 -0800 Message-ID: From: Martin Thomson To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UIa_3Ymxq_hu3CsRhheH5tC1XDs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 17:49:42 -0000 On 8 December 2014 at 09:43, I=C3=B1aki Baz Castillo wrote: > The "MUST implement VP8 and H264" is a break line in the W3C, meaning > that from now on just big vendors (those who can deal with licensing > stuff) can conform with the specifications. And that is no good at > all. To the extent that this is true, it is true already. If you want to create a competitive browser, you need significant resources. At any one time, you need to have about this much work in flight, even once you reach parity: https://status.modern.ie/ However, calling out codecs as being special is ridiculous. Firefox manages, therefore this hypothetical new player could do the same thing. From nobody Mon Dec 8 09:55:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6BB1ACD51 for ; Mon, 8 Dec 2014 09:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkVrKa9FZG1U for ; Mon, 8 Dec 2014 09:55:42 -0800 (PST) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6461A879C for ; Mon, 8 Dec 2014 09:55:42 -0800 (PST) Received: by mail-qg0-f52.google.com with SMTP id a108so3892849qge.11 for ; Mon, 08 Dec 2014 09:55:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=/8W23gbrsj8JP4tgGp0y12mQxbHtkcPWzLjfMiFtamQ=; b=gKsDMZjAcqITcnAYcitYbF3a/f4eOTf/Ux6AvYTAwB+cXg6GuEBKR4u8ntnFcupfN1 rZ/vOojCb/uQ2fI+9RqkNNZyTJ0NXtBcBjxuyfQwKL4ACNoPgF415VUgHzWPuqP/IttF VZjaKxAGTk5gRKhCRiUR6D62DpsY/PCKb+cKUtVqS0E8/j5+nB8MGAxr4FVy5bjppVfJ ISYHcO7/ltqjjbiRN7m6y1YdX7K1tUEyXfret248M/nVrDfHH+D0rlEWMHRw+m1fbSpz 8l+YqeIV07Jjs6VVpe540NNqruNhamdoi32z5Bvi9o2GQLnPSuZxxx5EijtWb//0Iw1d YFVA== X-Gm-Message-State: ALoCoQm5Bwpc5h20VwFLOapLGmAQBjqtr2oiphvEOReLZCdY84NU0dd8VS+svj6kYTh/wtMTTKcG X-Received: by 10.224.54.203 with SMTP id r11mr55452239qag.62.1418061341046; Mon, 08 Dec 2014 09:55:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Mon, 8 Dec 2014 09:55:19 -0800 (PST) In-Reply-To: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 8 Dec 2014 18:55:19 +0100 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tdimhuuxVhNK16wbHMllc-4rboA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 17:55:43 -0000 2014-12-08 18:49 GMT+01:00 Martin Thomson : > However, calling out codecs as being special is ridiculous. Firefox > manages, therefore this hypothetical new player could do the same > thing. I don't think Firefox "manages" H264 at all. When a website runs Flash in my browser I don't say that "I manage Flash". --=20 I=C3=B1aki Baz Castillo From nobody Mon Dec 8 09:56:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7751A87A0 for ; Mon, 8 Dec 2014 09:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrMAMhKx1cRa for ; Mon, 8 Dec 2014 09:56:32 -0800 (PST) Received: from relay.mailchannels.net (ar-005-i178.relay.mailchannels.net [162.253.144.63]) by ietfa.amsl.com (Postfix) with ESMTP id 958541ACD58 for ; Mon, 8 Dec 2014 09:56:16 -0800 (PST) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-220-9-73.us-west-2.compute.internal [10.220.9.73]) by relay.mailchannels.net (Postfix) with ESMTPA id 63D9F1217C7 for ; Mon, 8 Dec 2014 17:56:06 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.216.27.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.2); Mon, 08 Dec 2014 17:56:12 GMT X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1418061368600:1644794636 X-MC-Ingress-Time: 1418061366807 Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:54537 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xy2XV-000BaH-1J for rtcweb@ietf.org; Mon, 08 Dec 2014 11:56:05 -0600 Message-ID: <5485E627.5050706@jesup.org> Date: Mon, 08 Dec 2014 12:55:51 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54820E74.90201@mozilla.com> In-Reply-To: <54820E74.90201@mozilla.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AuthUser: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RPPHZD7PaEmKBTmc1HGjgD3xcTM Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 17:56:34 -0000 On 12/5/2014 2:58 PM, Jean-Marc Valin wrote: > Considering that: > 1) We have committed to an MTI video codec > 2) All consensus calls on "VP8 only" and "H.264 only" have failed > 3) This is the only proposal that gets support from both camps > I strongly support this MTI proposal. > Please, let's close this debate once and for all. This compromise is > by no means great, but it's much better than anything else we're going > to get otherwise (i.e. more wasted time and still no MTI). +1 - it's by no means my preferred solution, but it's one I can live with, and better than the alternative of the status-quo - no MTI at all. If it wasn't for OpenH264, my answer would be different. I can't see adopting H.264 as sole MTI, and I can't see that we'd get consensus to adopt VP8 as sole MTI. That basically leaves stone knives and bear skins (aka H.261) just to claim we have MTI, nothing (wild west), or this. (Unless magically MPEG-LA changes their mind - in which case that might trigger the kickout here.) -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Mon Dec 8 10:01:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDC71ACD65 for ; Mon, 8 Dec 2014 10:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b--_8g2nDl0t for ; Mon, 8 Dec 2014 10:00:57 -0800 (PST) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2041A87A0 for ; Mon, 8 Dec 2014 10:00:57 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id x3so3787974qcv.8 for ; Mon, 08 Dec 2014 10:00:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=5gJ9cJFW3Ax7NPvIJA2aQALjvnPbsJOqn7fIEVgk9LM=; b=fAba3nlbCHc93vz8rMNVBi8j0ut2e+eT7A6PRxvPDyn5tBoEF5rGi/o3zl+RA7eVJf SL8VrdOQPMvDGB52kI1Zil402pwrMHU2NojnXVlYfgTzPxXwOm2jO2Np4CAU+jsATpck BKlEFMvdAIU2DLwVHqUnBS3Et1M4YIUa0sqNgjjeIdrZroEEF6OXOPyHYl2aqKWS6CJ0 36QhXAWr9LQ8ham4Jf4LeHyhb2AevokFVMzn9FQ+j6/O+PEPKlitWF0Bg2y1QaHm7UNq Kxb/KKnEuRO7BhWubv9pcSuTvYFB7/GyPBKDMmGqqs397sgYPXZBx7CRmmSZ/pxqO9Jv xBhA== X-Gm-Message-State: ALoCoQmVxAlW5Qetv+txDGP4fxTVMhGuIm9EihPuJ5LMzS8y8QMW3Ho2aGbQxY3/8l/0NNpEYOuO X-Received: by 10.229.44.7 with SMTP id y7mr55014330qce.26.1418061648339; Mon, 08 Dec 2014 10:00:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Mon, 8 Dec 2014 10:00:28 -0800 (PST) In-Reply-To: <5485E627.5050706@jesup.org> References: <54820E74.90201@mozilla.com> <5485E627.5050706@jesup.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 8 Dec 2014 19:00:28 +0100 Message-ID: To: Randell Jesup Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/U3AnIdlKs6Go0tLye_3a-vF7AmM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 18:00:58 -0000 2014-12-08 18:55 GMT+01:00 Randell Jesup : > +1 - it's by no means my preferred solution, but it's one I can live with= , > and better than the alternative of the status-quo - no MTI at all. If it > wasn't for OpenH264, my answer would be different. > > I can't see adopting H.264 as sole MTI, and I can't see that we'd get > consensus to adopt VP8 as sole MTI. There was a much better solution: - Don't make VP8 nor H264 MTI. - So for now no MTI video codec. - And a W3C compromise: First video codec 100% royalty free would become MTI in WebRTC. Things would be exactly as they are now, but at least we avoid a "MUST" that will be ignored by 50% of the market. --=20 I=C3=B1aki Baz Castillo From nobody Mon Dec 8 10:14:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0015E1ACD6B for ; Mon, 8 Dec 2014 10:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4XqzFiJig1Z for ; Mon, 8 Dec 2014 10:14:40 -0800 (PST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 7318B1A87B2 for ; Mon, 8 Dec 2014 10:14:40 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 08 Dec 2014 10:14:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,539,1413270000"; d="scan'208,217";a="644360134" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga002.fm.intel.com with ESMTP; 08 Dec 2014 10:14:39 -0800 Received: from fmsmsx102.amr.corp.intel.com (10.18.124.200) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 8 Dec 2014 10:14:38 -0800 Received: from fmsmsx118.amr.corp.intel.com ([169.254.1.40]) by FMSMSX102.amr.corp.intel.com ([169.254.10.94]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 10:14:39 -0800 From: "Cavigioli, Chris" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQExCSNiUFbQ5Va0mwaH6oHJ3FE5yF/qzQ Date: Mon, 8 Dec 2014 18:14:38 +0000 Message-ID: References: <54820E74.90201@mozilla.com> <5485E627.5050706@jesup.org> In-Reply-To: <5485E627.5050706@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.108] Content-Type: multipart/alternative; boundary="_000_E36D1A4AE0B6AA4091F1728D584A6AD24011A566fmsmsx118amrcor_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/frWrKzs9bYKX0V_bFWF96qmVcOE Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 18:14:43 -0000 --_000_E36D1A4AE0B6AA4091F1728D584A6AD24011A566fmsmsx118amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 ...fully support the consensus, even if rough and non-unanimous Chris Cavigioli Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile and = Communications Group (MCG) * This e-mail may contain confidential and privileged material for the sole u= se of the intended recipient(s). Any review or distribution by others is s= trictly prohibited. If you are not the intended recipient, please contact t= he sender and delete all copies. -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Randell Jesup Sent: Monday, December 08, 2014 9:56 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec On 12/5/2014 2:58 PM, Jean-Marc Valin wrote: > Considering that: > 1) We have committed to an MTI video codec > 2) All consensus calls on "VP8 only" and "H.264 only" have failed > 3) This is the only proposal that gets support from both camps I > strongly support this MTI proposal. > Please, let's close this debate once and for all. This compromise is > by no means great, but it's much better than anything else we're going > to get otherwise (i.e. more wasted time and still no MTI). +1 - it's by no means my preferred solution, but it's one I can live with, and better than the alternative of the status-quo - no MTI at all. I= f it wasn't for OpenH264, my answer would be different. I can't see adopting H.264 as sole MTI, and I can't see that we'd get conse= nsus to adopt VP8 as sole MTI. That basically leaves stone knives and bear= skins (aka H.261) just to claim we have MTI, nothing (wild west), or this.= (Unless magically MPEG-LA changes their mind - in which case that might t= rigger the kickout here.) -- Randell Jesup -- rjesup a t mozilla d o t com _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_E36D1A4AE0B6AA4091F1728D584A6AD24011A566fmsmsx118amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1      ...fully sup= port the consensus, even if rough and non-unanimous

 

Chris Cavigioli

Intel Corp, System Architecture and Planning, Video/Multimedia, Mobile and Commu= nications Group (MCG)

*

This e-ma= il may contain confidential and privileged material for the sole use of the= intended recipient(s).  Any review or distribution by others is stric= tly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

 

 

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Randell Jesup Sent: Monday, December 08, 2014 9:56 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] confirming sense of the room: mti codec

 

On 12/5/2014 2:58 PM, Jean-Marc Valin wrote:=

> Considering that:

> 1) We have committed to an MTI video codec

> 2) All consensus calls on "VP8 only&quo= t; and "H.264 only" have failed

> 3) This is the only proposal that gets suppo= rt from both camps I

> strongly support this MTI proposal.

> Please, let's close this debate once and for= all. This compromise is

> by no means great, but it's much better than= anything else we're going

> to get otherwise (i.e. more wasted time and = still no MTI).

 

+1 - it's by no means my preferred solution, = but it's one I can live

with, and better than the alternative of the stat= us-quo - no MTI at all.  If it wasn't for OpenH264, my answer would be= different.

 

I can't see adopting H.264 as sole MTI, and I can= 't see that we'd get consensus to adopt VP8 as sole MTI.  That basical= ly leaves stone knives and bear skins (aka H.261) just to claim we have MTI= , nothing (wild west), or this.  (Unless magically MPEG-LA changes their mind - in which case that might trigger th= e kickout here.)

 

--

Randell Jesup -- rjesup a t mozilla d o t com

 

_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.i= etf.org/mailman/listinfo/rtcweb

--_000_E36D1A4AE0B6AA4091F1728D584A6AD24011A566fmsmsx118amrcor_-- From nobody Mon Dec 8 10:18:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F7B1A87BC for ; Mon, 8 Dec 2014 10:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzLj9Vt06kxX for ; Mon, 8 Dec 2014 10:18:03 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C6C1AC3C4 for ; Mon, 8 Dec 2014 10:17:43 -0800 (PST) Received: by mail-oi0-f50.google.com with SMTP id a141so3756953oig.9 for ; Mon, 08 Dec 2014 10:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=B8q+kAV/HftwAYwHU0RBW+Z9u55TqsUS8zrcexmabps=; b=y5RDLTUWgu9EQS5m7j4U4EjBRTYcZ7FN5KlEMBwzte/bMYZYhThYFHIkzpffbf7Vvy LUVZlYgh/bJBkiekwr43t0i6JuMjoiESq/CLGfu9Syl0QRieDIs6+ZJwUX36aSsrkG8m 9qM18GLRGlFpYaMbPERkStbsr4nkE36rVr1GBw/8CNTMGSJxGYMDZZyNo4aL6zxvrqFH JTiVV4+wpIaDfKmsdDRGTlJASGiFio2OW5lwu8Iobimd1vbja89y6/eqqGz8658FZDLC YPWRUzCHoqNR6tZ8/qon5IQbRmXlBTvix0AUj49fiJyHfUXFDDHHOGiCLsO1z5eblWuE scYQ== MIME-Version: 1.0 X-Received: by 10.202.168.204 with SMTP id r195mr7890603oie.72.1418062663289; Mon, 08 Dec 2014 10:17:43 -0800 (PST) Received: by 10.202.115.4 with HTTP; Mon, 8 Dec 2014 10:17:43 -0800 (PST) In-Reply-To: References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> Date: Mon, 8 Dec 2014 10:17:43 -0800 Message-ID: From: Martin Thomson To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KgLFDpnfhkw6uTPyuUhRISHX8b8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 18:18:04 -0000 On 8 December 2014 at 09:55, I=C3=B1aki Baz Castillo wrote: > I don't think Firefox "manages" H264 at all. When a website runs Flash > in my browser I don't say that "I manage Flash". If that is your standard, I suggest that you might consider how anything "manages" to happen at all. From nobody Mon Dec 8 10:31:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0651A87BF for ; Mon, 8 Dec 2014 10:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySTzFBNTJwF4 for ; Mon, 8 Dec 2014 10:30:57 -0800 (PST) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7AAD1AC3D0 for ; Mon, 8 Dec 2014 10:30:54 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id r20so7930670wiv.0 for ; Mon, 08 Dec 2014 10:30:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nGqUf3Z/KndnFUOy8iLtPIFfkqTTLzInfovkGgFtcvM=; b=mkZ3nv/3HhuhggUmKfr5Z0ZrELxHbLzJX7juwJ1BKiUK5be4A08IWzy2MB1fW1/rLt 2LZNXlSkw1mAW0aEeKvS913eC7RZI1zbB/uZphPg3JpNToCKXQGR+hOJLoGlqWG7ki4E T0S8pKHyhPcB3jhodB9xeV8zp3DvDbOG6H20o7G3wCxFCTPY35y7RPdYduciblJwlMuL dcCxbMnnoI8dzfLXldBTXCVbmuXWzGpinAbMoCvQhtIza+3NStzQbK2KYsVty7BOh2Wc J98QZ5FIV32Hi/f4c6l+iJofbuamRgMOgA5dMdBFIEL4EpIB9ti/wBbCUTT1TPNhhumd z4CA== X-Gm-Message-State: ALoCoQk4/nXs9TMXjSm8yM1NogeUkRcx/QZACcgJQzJESvYJx0l4bV+kxo5wCiAa7zasdySq0BXT X-Received: by 10.194.108.98 with SMTP id hj2mr16310421wjb.102.1418063453678; Mon, 08 Dec 2014 10:30:53 -0800 (PST) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com. [209.85.212.170]) by mx.google.com with ESMTPSA id pf4sm57593063wjb.36.2014.12.08.10.30.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Dec 2014 10:30:52 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id bs8so7917921wib.5 for ; Mon, 08 Dec 2014 10:30:52 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.109.3 with SMTP id ho3mr26227122wib.39.1418063452221; Mon, 08 Dec 2014 10:30:52 -0800 (PST) Received: by 10.216.70.16 with HTTP; Mon, 8 Dec 2014 10:30:52 -0800 (PST) In-Reply-To: <5485CC5B.2030104@alvestrand.no> References: <5485CC5B.2030104@alvestrand.no> Date: Mon, 8 Dec 2014 13:30:52 -0500 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=e89a8f3b9daf56b80c0509b8a07e Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/60l8cbfVua2LqiS7qBSTz5FgZuY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 18:31:05 -0000 --e89a8f3b9daf56b80c0509b8a07e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support the rough consensus as presented by the chair. _____________ Roman Shpount On Mon, Dec 8, 2014 at 11:05 AM, Harald Alvestrand wrote: > Since others who were present in the room are repeating their position > on the list, I'll do so too. > > I support the rough consensus as presented by the chair. > > > > Den 05. des. 2014 14:36, skrev Sean Turner: > > All, > > > > At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion abou= t > codecs, which I dubbed "the great codec compromise." The compromise text > that was discussed appears in slides 12-14 at [4] (which is a slight > editorial variation of the text proposed at [2]). > > > > This message serves to confirm the sense of the room. > > > > In the room, I heard the following objections and responses (and I=E2= =80=99m > paraphrasing here), which I=E2=80=99ll take the liberty of categorizing a= s IPR, > Time, and Trigger: > > > > 1) IPR: > > > > Objections: There are still IPR concerns which may restrict what a > particular organization feels comfortable with including in their browser > implementations. > > > > Response: IPR concerns on this topic are well known. There is even a > draft summarizing the current IPR status for VP8: > draft-benham-rtcweb-vp8litigation. The sense of the room was still that > adopting the compromise text was appropriate. > > > > 2) Time: > > > > 2.1) Time to consider decision: > > > > Objection: The decision to consider the compromise proposal at this > meeting was provided on short notice and did not provide some the > opportunity to attend in person. > > > > Response: Six months ago the chairs made it clear discussion would be > revisited @ IETF 91 [0]. The first agenda proposal for the WG included th= is > topic [1], and the topic was never removed by the chairs. More > importantly, all decisions are confirmed on list; in person attendance is > not required to be part of the process. > > > > 2.2) Time to consider text: > > > > Objection: The proposed text [2] is too new to be considered. > > > > Response: The requirement for browsers to support both VP8 and H.264 wa= s > among the options in the straw poll conducted more than six months ago. > All decisions are confirmed on list so there will be ample time to discus= s > the proposal. > > > > 3) Trigger: > > > > Objection: The =E2=80=9Ctrigger=E2=80=9D sentence [3] is all kinds of w= rong because it=E2=80=99s > promising that the future IETF will update this specification. > > > > Response: Like any IETF proposal, an RFC that documents the current > proposal can be changed through the consensus process at any other time. > > > > > > After the discussion, some clarifying questions about the hums, and > typing the hum questions on the screen, there was rough consensus in the > room to add (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draft-ie= tf-rtcweb-video. > In keeping with IETF process, I am confirming this consensus call on the > list. > > > > If anyone has any other issues that they would like to raise please do > by December 19th. > > > > Cheers, > > spt (as chair) > > > > [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html > > [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html > > [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html > > [3] The one that begins with "If compelling evidence ..." > > [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf > > _______________________________________________ > > 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 > --e89a8f3b9daf56b80c0509b8a07e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the rough consensus as presented by the chair.

_____________
Roman Shpount

On Mon, Dec 8, 2014 at 11:05 AM, Harald Alve= strand <harald@alvestrand.no> wrote:
Since others who were present in the room are repeating their= position
on the list, I'll do so too.

I support the rough consensus as presented by the chair.



Den 05. des. 2014 14:36, skrev Sean Turner:
> All,
>
> At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion abo= ut codecs, which I dubbed "the great codec compromise."=C2=A0 The= compromise text that was discussed appears in slides 12-14 at [4] (which i= s a slight editorial variation of the text proposed at [2]).
>
> This message serves to confirm the sense of the room.
>
> In the room, I heard the following objections and responses (and I=E2= =80=99m paraphrasing here), which I=E2=80=99ll take the liberty of categori= zing as IPR, Time, and Trigger:
>
> 1) IPR:
>
> Objections: There are still IPR concerns which may restrict what a par= ticular organization feels comfortable with including in their browser impl= ementations.
>
> Response:=C2=A0 IPR concerns on this topic are well known.=C2=A0 There= is even a draft summarizing the current IPR status for VP8: draft-benham-r= tcweb-vp8litigation.=C2=A0 The sense of the room was still that adopting th= e compromise text was appropriate.
>
> 2) Time:
>
> 2.1) Time to consider decision:
>
> Objection: The decision to consider the compromise proposal at this me= eting was provided on short notice and did not provide some the opportunity= to attend in person.
>
> Response:=C2=A0 Six months ago the chairs made it clear discussion wou= ld be revisited @ IETF 91 [0]. The first agenda proposal for the WG include= d this topic [1], and the topic was never removed by the chairs.=C2=A0 =C2= =A0 More importantly, all decisions are confirmed on list; in person attend= ance is not required to be part of the process.
>
> 2.2) Time to consider text:
>
> Objection: The proposed text [2] is too new to be considered.
>
> Response: The requirement for browsers to support both VP8 and H.264 w= as among the options in the straw poll conducted more than six months ago.= =C2=A0 All decisions are confirmed on list so there will be ample time to d= iscuss the proposal.
>
> 3) Trigger:
>
> Objection: The =E2=80=9Ctrigger=E2=80=9D sentence [3] is all kinds of = wrong because it=E2=80=99s promising that the future IETF will update this = specification.
>
> Response: Like any IETF proposal, an RFC that documents the current pr= oposal can be changed through the consensus process at any other time.
>
>
> After the discussion, some clarifying questions about the hums, and ty= ping the hum questions on the screen, there was rough consensus in the room= to add (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draft-ietf-rtc= web-video.=C2=A0 In keeping with IETF process, I am confirming this consens= us call on the list.
>
> If anyone has any other issues that they would like to raise please do= by December 19th.
>
> Cheers,
> spt (as chair)
>
> [0] http://www.ietf.org/mail-archive/web/rtcweb/c= urrent/msg11194.html
> [1] http://www.ietf.org/mail-archive/web/rtcweb/c= urrent/msg13150.html
> [2] http://www.ietf.org/mail-archive/web/rtcweb/c= urrent/msg13432.html
> [3] The one that begins with "If compelling evidence ..." > [4] http://www.ietf.org/proceedings/91/slides/slid= es-91-rtcweb-7.pdf
> __________________= _____________________________
> 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

--e89a8f3b9daf56b80c0509b8a07e-- From nobody Mon Dec 8 10:35:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E561ACD76 for ; Mon, 8 Dec 2014 10:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCJi9jl95fgV for ; Mon, 8 Dec 2014 10:35:08 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2771ACD70 for ; Mon, 8 Dec 2014 10:35:06 -0800 (PST) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 08 Dec 2014 13:34:59 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0210.002; Mon, 8 Dec 2014 13:34:59 -0500 From: Andrew Allen To: Roman Shpount , Harald Alvestrand Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEJCKEBti1FXXNkmH1ALOez9gJ5yGNFiAgAAoiQD//6yQEA== Date: Mon, 8 Dec 2014 18:34:58 +0000 Message-ID: References: <5485CC5B.2030104@alvestrand.no> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD233998A6A5XMB122CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pmstU1L-zu5VvR8XwNJtLz-Lz4Q Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 18:35:10 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD233998A6A5XMB122CNCrimnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBpdOKAmXMgcHJldHR5IGNsZWFyIGZyb20gbXkgc3RhdGVtZW50cyBpbiB0aGUgSUVU RiBzZXNzaW9uIG9uIHRoaXMgdG9waWMgYW5kIG9uIHRoaXMgbGlzdCB0aGF0IEkgZG9u4oCZdCBz dXBwb3J0IGhhdmluZyB0d28gTVRJICB2aWRlbyBjb2RlY3MgZm9yIGFueSBXZWJSVEMgZW50aXR5 IGFuZCBJIGRvbuKAmXQgdGhpbmsgaXQgaXMgdGVjaG5pY2FsbHkganVzdGlmaWVkLiBCdXQgSSBz dGF0ZSB0aGlzIGhlcmUgZm9ybWFsbHkuDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9tYW4gU2hwb3VudA0KU2VudDogTW9uZGF5 LCBEZWNlbWJlciAwOCwgMjAxNCAxOjMxIFBNDQpUbzogSGFyYWxkIEFsdmVzdHJhbmQNCkNjOiBy dGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBjb25maXJtaW5nIHNlbnNlIG9m IHRoZSByb29tOiBtdGkgY29kZWMNCg0KSSBzdXBwb3J0IHRoZSByb3VnaCBjb25zZW5zdXMgYXMg cHJlc2VudGVkIGJ5IHRoZSBjaGFpci4NCg0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0K DQpPbiBNb24sIERlYyA4LCAyMDE0IGF0IDExOjA1IEFNLCBIYXJhbGQgQWx2ZXN0cmFuZCA8aGFy YWxkQGFsdmVzdHJhbmQubm88bWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vPj4gd3JvdGU6DQpT aW5jZSBvdGhlcnMgd2hvIHdlcmUgcHJlc2VudCBpbiB0aGUgcm9vbSBhcmUgcmVwZWF0aW5nIHRo ZWlyIHBvc2l0aW9uDQpvbiB0aGUgbGlzdCwgSSdsbCBkbyBzbyB0b28uDQoNCkkgc3VwcG9ydCB0 aGUgcm91Z2ggY29uc2Vuc3VzIGFzIHByZXNlbnRlZCBieSB0aGUgY2hhaXIuDQoNCg0KDQpEZW4g MDUuIGRlcy4gMjAxNCAxNDozNiwgc2tyZXYgU2VhbiBUdXJuZXI6DQo+IEFsbCwNCj4NCj4gQXQg dGhlIDJuZCBSVEN3ZWIgV0cgc2Vzc2lvbiBAIElFVEYgOTEsIHdlIGhhZCBhIGxpdmVseSBkaXNj dXNzaW9uIGFib3V0IGNvZGVjcywgd2hpY2ggSSBkdWJiZWQgInRoZSBncmVhdCBjb2RlYyBjb21w cm9taXNlLiIgIFRoZSBjb21wcm9taXNlIHRleHQgdGhhdCB3YXMgZGlzY3Vzc2VkIGFwcGVhcnMg aW4gc2xpZGVzIDEyLTE0IGF0IFs0XSAod2hpY2ggaXMgYSBzbGlnaHQgZWRpdG9yaWFsIHZhcmlh dGlvbiBvZiB0aGUgdGV4dCBwcm9wb3NlZCBhdCBbMl0pLg0KPg0KPiBUaGlzIG1lc3NhZ2Ugc2Vy dmVzIHRvIGNvbmZpcm0gdGhlIHNlbnNlIG9mIHRoZSByb29tLg0KPg0KPiBJbiB0aGUgcm9vbSwg SSBoZWFyZCB0aGUgZm9sbG93aW5nIG9iamVjdGlvbnMgYW5kIHJlc3BvbnNlcyAoYW5kIEnigJlt IHBhcmFwaHJhc2luZyBoZXJlKSwgd2hpY2ggSeKAmWxsIHRha2UgdGhlIGxpYmVydHkgb2YgY2F0 ZWdvcml6aW5nIGFzIElQUiwgVGltZSwgYW5kIFRyaWdnZXI6DQo+DQo+IDEpIElQUjoNCj4NCj4g T2JqZWN0aW9uczogVGhlcmUgYXJlIHN0aWxsIElQUiBjb25jZXJucyB3aGljaCBtYXkgcmVzdHJp Y3Qgd2hhdCBhIHBhcnRpY3VsYXIgb3JnYW5pemF0aW9uIGZlZWxzIGNvbWZvcnRhYmxlIHdpdGgg aW5jbHVkaW5nIGluIHRoZWlyIGJyb3dzZXIgaW1wbGVtZW50YXRpb25zLg0KPg0KPiBSZXNwb25z ZTogIElQUiBjb25jZXJucyBvbiB0aGlzIHRvcGljIGFyZSB3ZWxsIGtub3duLiAgVGhlcmUgaXMg ZXZlbiBhIGRyYWZ0IHN1bW1hcml6aW5nIHRoZSBjdXJyZW50IElQUiBzdGF0dXMgZm9yIFZQODog ZHJhZnQtYmVuaGFtLXJ0Y3dlYi12cDhsaXRpZ2F0aW9uLiAgVGhlIHNlbnNlIG9mIHRoZSByb29t IHdhcyBzdGlsbCB0aGF0IGFkb3B0aW5nIHRoZSBjb21wcm9taXNlIHRleHQgd2FzIGFwcHJvcHJp YXRlLg0KPg0KPiAyKSBUaW1lOg0KPg0KPiAyLjEpIFRpbWUgdG8gY29uc2lkZXIgZGVjaXNpb246 DQo+DQo+IE9iamVjdGlvbjogVGhlIGRlY2lzaW9uIHRvIGNvbnNpZGVyIHRoZSBjb21wcm9taXNl IHByb3Bvc2FsIGF0IHRoaXMgbWVldGluZyB3YXMgcHJvdmlkZWQgb24gc2hvcnQgbm90aWNlIGFu ZCBkaWQgbm90IHByb3ZpZGUgc29tZSB0aGUgb3Bwb3J0dW5pdHkgdG8gYXR0ZW5kIGluIHBlcnNv bi4NCj4NCj4gUmVzcG9uc2U6ICBTaXggbW9udGhzIGFnbyB0aGUgY2hhaXJzIG1hZGUgaXQgY2xl YXIgZGlzY3Vzc2lvbiB3b3VsZCBiZSByZXZpc2l0ZWQgQCBJRVRGIDkxIFswXS4gVGhlIGZpcnN0 IGFnZW5kYSBwcm9wb3NhbCBmb3IgdGhlIFdHIGluY2x1ZGVkIHRoaXMgdG9waWMgWzFdLCBhbmQg dGhlIHRvcGljIHdhcyBuZXZlciByZW1vdmVkIGJ5IHRoZSBjaGFpcnMuICAgIE1vcmUgaW1wb3J0 YW50bHksIGFsbCBkZWNpc2lvbnMgYXJlIGNvbmZpcm1lZCBvbiBsaXN0OyBpbiBwZXJzb24gYXR0 ZW5kYW5jZSBpcyBub3QgcmVxdWlyZWQgdG8gYmUgcGFydCBvZiB0aGUgcHJvY2Vzcy4NCj4NCj4g Mi4yKSBUaW1lIHRvIGNvbnNpZGVyIHRleHQ6DQo+DQo+IE9iamVjdGlvbjogVGhlIHByb3Bvc2Vk IHRleHQgWzJdIGlzIHRvbyBuZXcgdG8gYmUgY29uc2lkZXJlZC4NCj4NCj4gUmVzcG9uc2U6IFRo ZSByZXF1aXJlbWVudCBmb3IgYnJvd3NlcnMgdG8gc3VwcG9ydCBib3RoIFZQOCBhbmQgSC4yNjQg d2FzIGFtb25nIHRoZSBvcHRpb25zIGluIHRoZSBzdHJhdyBwb2xsIGNvbmR1Y3RlZCBtb3JlIHRo YW4gc2l4IG1vbnRocyBhZ28uICBBbGwgZGVjaXNpb25zIGFyZSBjb25maXJtZWQgb24gbGlzdCBz byB0aGVyZSB3aWxsIGJlIGFtcGxlIHRpbWUgdG8gZGlzY3VzcyB0aGUgcHJvcG9zYWwuDQo+DQo+ IDMpIFRyaWdnZXI6DQo+DQo+IE9iamVjdGlvbjogVGhlIOKAnHRyaWdnZXLigJ0gc2VudGVuY2Ug WzNdIGlzIGFsbCBraW5kcyBvZiB3cm9uZyBiZWNhdXNlIGl04oCZcyBwcm9taXNpbmcgdGhhdCB0 aGUgZnV0dXJlIElFVEYgd2lsbCB1cGRhdGUgdGhpcyBzcGVjaWZpY2F0aW9uLg0KPg0KPiBSZXNw b25zZTogTGlrZSBhbnkgSUVURiBwcm9wb3NhbCwgYW4gUkZDIHRoYXQgZG9jdW1lbnRzIHRoZSBj dXJyZW50IHByb3Bvc2FsIGNhbiBiZSBjaGFuZ2VkIHRocm91Z2ggdGhlIGNvbnNlbnN1cyBwcm9j ZXNzIGF0IGFueSBvdGhlciB0aW1lLg0KPg0KPg0KPiBBZnRlciB0aGUgZGlzY3Vzc2lvbiwgc29t ZSBjbGFyaWZ5aW5nIHF1ZXN0aW9ucyBhYm91dCB0aGUgaHVtcywgYW5kIHR5cGluZyB0aGUgaHVt IHF1ZXN0aW9ucyBvbiB0aGUgc2NyZWVuLCB0aGVyZSB3YXMgcm91Z2ggY29uc2Vuc3VzIGluIHRo ZSByb29tIHRvIGFkZCAoYWthIOKAnHNob3Zl4oCdKSB0aGUgcHJvcG9zZWQgdGV4dCBpbnRvIGRy YWZ0LWlldGYtcnRjd2ViLXZpZGVvLiAgSW4ga2VlcGluZyB3aXRoIElFVEYgcHJvY2VzcywgSSBh bSBjb25maXJtaW5nIHRoaXMgY29uc2Vuc3VzIGNhbGwgb24gdGhlIGxpc3QuDQo+DQo+IElmIGFu eW9uZSBoYXMgYW55IG90aGVyIGlzc3VlcyB0aGF0IHRoZXkgd291bGQgbGlrZSB0byByYWlzZSBw bGVhc2UgZG8gYnkgRGVjZW1iZXIgMTl0aC4NCj4NCj4gQ2hlZXJzLA0KPiBzcHQgKGFzIGNoYWly KQ0KPg0KPiBbMF0gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Y3dlYi9j dXJyZW50L21zZzExMTk0Lmh0bWwNCj4gWzFdIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9ydGN3ZWIvY3VycmVudC9tc2cxMzE1MC5odG1sDQo+IFsyXSBodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1cnJlbnQvbXNnMTM0MzIuaHRtbA0KPiBb M10gVGhlIG9uZSB0aGF0IGJlZ2lucyB3aXRoICJJZiBjb21wZWxsaW5nIGV2aWRlbmNlIC4uLiIN Cj4gWzRdIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTEvc2xpZGVzL3NsaWRlcy05 MS1ydGN3ZWItNy5wZGYNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWINCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2Vi QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIN Cg0K --_000_BBF5DDFE515C3946BC18D733B20DAD233998A6A5XMB122CNCrimnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgaXTigJlzIHByZXR0eSBj bGVhciBmcm9tIG15IHN0YXRlbWVudHMgaW4gdGhlIElFVEYgc2Vzc2lvbiBvbiB0aGlzIHRvcGlj IGFuZCBvbiB0aGlzIGxpc3QgdGhhdCBJIGRvbuKAmXQgc3VwcG9ydCBoYXZpbmcgdHdvIE1USSZu YnNwOyB2aWRlbyBjb2RlY3MgZm9yIGFueSBXZWJSVEMNCiBlbnRpdHkgYW5kIEkgZG9u4oCZdCB0 aGluayBpdCBpcyB0ZWNobmljYWxseSBqdXN0aWZpZWQuIEJ1dCBJIHN0YXRlIHRoaXMgaGVyZSBm b3JtYWxseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dl YiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5S b21hbiBTaHBvdW50PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRGVjZW1iZXIgMDgsIDIwMTQg MTozMSBQTTxicj4NCjxiPlRvOjwvYj4gSGFyYWxkIEFsdmVzdHJhbmQ8YnI+DQo8Yj5DYzo8L2I+ IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gY29uZmly bWluZyBzZW5zZSBvZiB0aGUgcm9vbTogbXRpIGNvZGVjPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBzdXBwb3J0IHRoZSByb3VnaCBjb25zZW5zdXMgYXMgcHJlc2VudGVk IGJ5IHRoZSBjaGFpci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgRGVj IDgsIDIwMTQgYXQgMTE6MDUgQU0sIEhhcmFsZCBBbHZlc3RyYW5kICZsdDs8YSBocmVmPSJtYWls dG86aGFyYWxkQGFsdmVzdHJhbmQubm8iIHRhcmdldD0iX2JsYW5rIj5oYXJhbGRAYWx2ZXN0cmFu ZC5ubzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ U2luY2Ugb3RoZXJzIHdobyB3ZXJlIHByZXNlbnQgaW4gdGhlIHJvb20gYXJlIHJlcGVhdGluZyB0 aGVpciBwb3NpdGlvbjxicj4NCm9uIHRoZSBsaXN0LCBJJ2xsIGRvIHNvIHRvby48YnI+DQo8YnI+ DQpJIHN1cHBvcnQgdGhlIHJvdWdoIGNvbnNlbnN1cyBhcyBwcmVzZW50ZWQgYnkgdGhlIGNoYWly Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCkRlbiAwNS4gZGVzLiAyMDE0IDE0OjM2LCBza3JldiBT ZWFuIFR1cm5lcjo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jmd0OyBBbGwsPGJyPg0KJmd0Ozxicj4NCiZndDsgQXQgdGhlIDJuZCBSVEN3ZWIgV0cg c2Vzc2lvbiBAIElFVEYgOTEsIHdlIGhhZCBhIGxpdmVseSBkaXNjdXNzaW9uIGFib3V0IGNvZGVj cywgd2hpY2ggSSBkdWJiZWQgJnF1b3Q7dGhlIGdyZWF0IGNvZGVjIGNvbXByb21pc2UuJnF1b3Q7 Jm5ic3A7IFRoZSBjb21wcm9taXNlIHRleHQgdGhhdCB3YXMgZGlzY3Vzc2VkIGFwcGVhcnMgaW4g c2xpZGVzIDEyLTE0IGF0IFs0XSAod2hpY2ggaXMgYSBzbGlnaHQgZWRpdG9yaWFsIHZhcmlhdGlv biBvZiB0aGUgdGV4dCBwcm9wb3NlZA0KIGF0IFsyXSkuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhp cyBtZXNzYWdlIHNlcnZlcyB0byBjb25maXJtIHRoZSBzZW5zZSBvZiB0aGUgcm9vbS48YnI+DQom Z3Q7PGJyPg0KJmd0OyBJbiB0aGUgcm9vbSwgSSBoZWFyZCB0aGUgZm9sbG93aW5nIG9iamVjdGlv bnMgYW5kIHJlc3BvbnNlcyAoYW5kIEnigJltIHBhcmFwaHJhc2luZyBoZXJlKSwgd2hpY2ggSeKA mWxsIHRha2UgdGhlIGxpYmVydHkgb2YgY2F0ZWdvcml6aW5nIGFzIElQUiwgVGltZSwgYW5kIFRy aWdnZXI6PGJyPg0KJmd0Ozxicj4NCiZndDsgMSkgSVBSOjxicj4NCiZndDs8YnI+DQomZ3Q7IE9i amVjdGlvbnM6IFRoZXJlIGFyZSBzdGlsbCBJUFIgY29uY2VybnMgd2hpY2ggbWF5IHJlc3RyaWN0 IHdoYXQgYSBwYXJ0aWN1bGFyIG9yZ2FuaXphdGlvbiBmZWVscyBjb21mb3J0YWJsZSB3aXRoIGlu Y2x1ZGluZyBpbiB0aGVpciBicm93c2VyIGltcGxlbWVudGF0aW9ucy48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBSZXNwb25zZTombmJzcDsgSVBSIGNvbmNlcm5zIG9uIHRoaXMgdG9waWMgYXJlIHdlbGwg a25vd24uJm5ic3A7IFRoZXJlIGlzIGV2ZW4gYSBkcmFmdCBzdW1tYXJpemluZyB0aGUgY3VycmVu dCBJUFIgc3RhdHVzIGZvciBWUDg6IGRyYWZ0LWJlbmhhbS1ydGN3ZWItdnA4bGl0aWdhdGlvbi4m bmJzcDsgVGhlIHNlbnNlIG9mIHRoZSByb29tIHdhcyBzdGlsbCB0aGF0IGFkb3B0aW5nIHRoZSBj b21wcm9taXNlIHRleHQgd2FzIGFwcHJvcHJpYXRlLjxicj4NCiZndDs8YnI+DQomZ3Q7IDIpIFRp bWU6PGJyPg0KJmd0Ozxicj4NCiZndDsgMi4xKSBUaW1lIHRvIGNvbnNpZGVyIGRlY2lzaW9uOjxi cj4NCiZndDs8YnI+DQomZ3Q7IE9iamVjdGlvbjogVGhlIGRlY2lzaW9uIHRvIGNvbnNpZGVyIHRo ZSBjb21wcm9taXNlIHByb3Bvc2FsIGF0IHRoaXMgbWVldGluZyB3YXMgcHJvdmlkZWQgb24gc2hv cnQgbm90aWNlIGFuZCBkaWQgbm90IHByb3ZpZGUgc29tZSB0aGUgb3Bwb3J0dW5pdHkgdG8gYXR0 ZW5kIGluIHBlcnNvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBSZXNwb25zZTombmJzcDsgU2l4IG1v bnRocyBhZ28gdGhlIGNoYWlycyBtYWRlIGl0IGNsZWFyIGRpc2N1c3Npb24gd291bGQgYmUgcmV2 aXNpdGVkIEAgSUVURiA5MSBbMF0uIFRoZSBmaXJzdCBhZ2VuZGEgcHJvcG9zYWwgZm9yIHRoZSBX RyBpbmNsdWRlZCB0aGlzIHRvcGljIFsxXSwgYW5kIHRoZSB0b3BpYyB3YXMgbmV2ZXIgcmVtb3Zl ZCBieSB0aGUgY2hhaXJzLiZuYnNwOyAmbmJzcDsgTW9yZSBpbXBvcnRhbnRseSwgYWxsIGRlY2lz aW9ucyBhcmUgY29uZmlybWVkIG9uDQogbGlzdDsgaW4gcGVyc29uIGF0dGVuZGFuY2UgaXMgbm90 IHJlcXVpcmVkIHRvIGJlIHBhcnQgb2YgdGhlIHByb2Nlc3MuPGJyPg0KJmd0Ozxicj4NCiZndDsg Mi4yKSBUaW1lIHRvIGNvbnNpZGVyIHRleHQ6PGJyPg0KJmd0Ozxicj4NCiZndDsgT2JqZWN0aW9u OiBUaGUgcHJvcG9zZWQgdGV4dCBbMl0gaXMgdG9vIG5ldyB0byBiZSBjb25zaWRlcmVkLjxicj4N CiZndDs8YnI+DQomZ3Q7IFJlc3BvbnNlOiBUaGUgcmVxdWlyZW1lbnQgZm9yIGJyb3dzZXJzIHRv IHN1cHBvcnQgYm90aCBWUDggYW5kIEguMjY0IHdhcyBhbW9uZyB0aGUgb3B0aW9ucyBpbiB0aGUg c3RyYXcgcG9sbCBjb25kdWN0ZWQgbW9yZSB0aGFuIHNpeCBtb250aHMgYWdvLiZuYnNwOyBBbGwg ZGVjaXNpb25zIGFyZSBjb25maXJtZWQgb24gbGlzdCBzbyB0aGVyZSB3aWxsIGJlIGFtcGxlIHRp bWUgdG8gZGlzY3VzcyB0aGUgcHJvcG9zYWwuPGJyPg0KJmd0Ozxicj4NCiZndDsgMykgVHJpZ2dl cjo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPYmplY3Rpb246IFRoZSDigJx0cmlnZ2Vy4oCdIHNlbnRl bmNlIFszXSBpcyBhbGwga2luZHMgb2Ygd3JvbmcgYmVjYXVzZSBpdOKAmXMgcHJvbWlzaW5nIHRo YXQgdGhlIGZ1dHVyZSBJRVRGIHdpbGwgdXBkYXRlIHRoaXMgc3BlY2lmaWNhdGlvbi48YnI+DQom Z3Q7PGJyPg0KJmd0OyBSZXNwb25zZTogTGlrZSBhbnkgSUVURiBwcm9wb3NhbCwgYW4gUkZDIHRo YXQgZG9jdW1lbnRzIHRoZSBjdXJyZW50IHByb3Bvc2FsIGNhbiBiZSBjaGFuZ2VkIHRocm91Z2gg dGhlIGNvbnNlbnN1cyBwcm9jZXNzIGF0IGFueSBvdGhlciB0aW1lLjxicj4NCiZndDs8YnI+DQom Z3Q7PGJyPg0KJmd0OyBBZnRlciB0aGUgZGlzY3Vzc2lvbiwgc29tZSBjbGFyaWZ5aW5nIHF1ZXN0 aW9ucyBhYm91dCB0aGUgaHVtcywgYW5kIHR5cGluZyB0aGUgaHVtIHF1ZXN0aW9ucyBvbiB0aGUg c2NyZWVuLCB0aGVyZSB3YXMgcm91Z2ggY29uc2Vuc3VzIGluIHRoZSByb29tIHRvIGFkZCAoYWth IOKAnHNob3Zl4oCdKSB0aGUgcHJvcG9zZWQgdGV4dCBpbnRvIGRyYWZ0LWlldGYtcnRjd2ViLXZp ZGVvLiZuYnNwOyBJbiBrZWVwaW5nIHdpdGggSUVURiBwcm9jZXNzLCBJIGFtIGNvbmZpcm1pbmcN CiB0aGlzIGNvbnNlbnN1cyBjYWxsIG9uIHRoZSBsaXN0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IElm IGFueW9uZSBoYXMgYW55IG90aGVyIGlzc3VlcyB0aGF0IHRoZXkgd291bGQgbGlrZSB0byByYWlz ZSBwbGVhc2UgZG8gYnkgRGVjZW1iZXIgMTl0aC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBDaGVlcnMs PGJyPg0KJmd0OyBzcHQgKGFzIGNoYWlyKTxicj4NCiZndDs8YnI+DQomZ3Q7IFswXSA8YSBocmVm PSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1cnJlbnQvbXNn MTExOTQuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50L21zZzExMTk0Lmh0bWw8L2E+PGJyPg0KJmd0OyBbMV0g PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Y3dlYi9jdXJy ZW50L21zZzEzMTUwLmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9ydGN3ZWIvY3VycmVudC9tc2cxMzE1MC5odG1sPC9hPjxicj4NCiZn dDsgWzJdIDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9ydGN3 ZWIvY3VycmVudC9tc2cxMzQzMi5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1cnJlbnQvbXNnMTM0MzIuaHRtbDwvYT48 YnI+DQomZ3Q7IFszXSBUaGUgb25lIHRoYXQgYmVnaW5zIHdpdGggJnF1b3Q7SWYgY29tcGVsbGlu ZyBldmlkZW5jZSAuLi4mcXVvdDs8YnI+DQomZ3Q7IFs0XSA8YSBocmVmPSJodHRwOi8vd3d3Lmll dGYub3JnL3Byb2NlZWRpbmdzLzkxL3NsaWRlcy9zbGlkZXMtOTEtcnRjd2ViLTcucGRmIiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkxL3NsaWRlcy9z bGlkZXMtOTEtcnRjd2ViLTcucGRmPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgcnRjd2ViIG1haWxpbmcg bGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGll dGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48YnI+DQomZ3Q7PGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BBF5DDFE515C3946BC18D733B20DAD233998A6A5XMB122CNCrimnet_-- From nobody Mon Dec 8 10:51:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E882E1ACDAF for ; Mon, 8 Dec 2014 10:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qm0KupLtgQUY for ; Mon, 8 Dec 2014 10:51:07 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875E01ACD9F for ; Mon, 8 Dec 2014 10:51:06 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id tp5so5088945ieb.9 for ; Mon, 08 Dec 2014 10:51:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZVk/Vwl+VMbTC1GQOPlKp4cjqcUpCMfJOaZtItknPEs=; b=QwcHhhdKjLYAga+IRUfiwHztWEzLP7usxqLbrlSH/T57nHy5Bd1zl59o58MN5rA9UT DEJ3egHj/Zc6JWXoAlGdMNj6KOV/sIhe7Rzur1kXjTQ5BsqHRc/mfKf2VWT0ziDgJ77O LYbQLUXQb9o/PGrSpeUDpuCDy1hVZDiH0bhEEuND0i6p0xtO1VaPeanGfBEhJ2mOWwp4 hg+7eq3jd8TkiCpzzIgSsZsRtoAJkxgBDIYTnhSJWa2+mdttq0wYIQ9FNt33tUm2e4ZM 9UBRa5CrE55/1R76zI7vZL34RkOp5f0tS5zwjMz9z/x6SdnEqk+CZTHwQlbLJ4+rbBK4 M9GQ== X-Gm-Message-State: ALoCoQkY7x1qwF2EGS1HGa0v2QS8m5s9GKl5jq1586pzrtDmnLfrZoPRhiKntJyv14PMR2XEcMuf X-Received: by 10.107.162.134 with SMTP id l128mr12388704ioe.65.1418064665912; Mon, 08 Dec 2014 10:51:05 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id c1sm4218774igo.17.2014.12.08.10.51.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Dec 2014 10:51:05 -0800 (PST) Message-ID: <5485F318.2090707@andyet.net> Date: Mon, 08 Dec 2014 11:51:04 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5485CC5B.2030104@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/R9I_bNS53Pn5bJ1DjniPjTwhkTA Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 18:51:09 -0000 On 12/8/14, 11:34 AM, Andrew Allen wrote: > I think it’s pretty clear from my statements in the IETF session on this > topic and on this list that I don’t support having two MTI video codecs > for any WebRTC entity and I don’t think it is technically justified. But > I state this here formally. To those (not just Andrew) who are opposed to two MTI video codecs: were you also opposed to two MTI audio codecs? I'm trying to understand the differences between audio and video here... Peter From nobody Mon Dec 8 11:06:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BBB1ACDAA for ; Mon, 8 Dec 2014 11:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1pCDImauDSb for ; Mon, 8 Dec 2014 11:06:14 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1457B1ACDAF for ; Mon, 8 Dec 2014 11:06:14 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so6969318wgg.7 for ; Mon, 08 Dec 2014 11:06:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hOpdbjQ2sSRuBB026jcXwLtB1FtCvTRD8z09jzI8WEQ=; b=GB/UiYxj5IEKtZ15IhRaXBF1Ww3pFiA4IFTRaltpFkT5bqEBG7b2AKKNhHEmB6C9IC hzsFSebjYqRE7EqSTW10pfK/yBcCndMdkaCL9iBBGdwstyjAAhrahFhPnjrSJsK5IW4N F7hxdNba2wdyDB+Z0BW8N+qnQh3GWMixbc4Kd/csCO8/wLM3jOnbP0R3iBKafLnQ6Lqt uk6e4alBpWyr4NjSgxwdu2PCYOr4rp7kPg6zVeNntAN7awPL3uwhq9AjaOnPMg5DzShx bmfXg9ZuEC0GRjqaY3zkpGugiTekB2g+oTYO+JNOP2oJpAFu6AaLa6ztP8How+3ZJBBP uQjw== X-Gm-Message-State: ALoCoQkcAneLrLuM8cu4dfIa4NDb0CE7/o9vj9t5QMp70A+XWw/ZRrRf6hWNAAErFPpows1Shx1N X-Received: by 10.180.107.136 with SMTP id hc8mr26552784wib.32.1418065572812; Mon, 08 Dec 2014 11:06:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Mon, 8 Dec 2014 11:05:32 -0800 (PST) In-Reply-To: References: <5485CC5B.2030104@alvestrand.no> From: Eric Rescorla Date: Mon, 8 Dec 2014 20:05:32 +0100 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=e89a8f3bad45bc6cf50509b91e7f Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/a8reTLQTa9yjvo2DYOU0i8-tbOU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 19:06:16 -0000 --e89a8f3bad45bc6cf50509b91e7f Content-Type: text/plain; charset=UTF-8 Just to reiterate what I said in the room, I agree with this. -Ekr On Mon, Dec 8, 2014 at 6:39 PM, Justin Uberti wrote: > I support the rough consensus as presented by the chair. > > As stated before - I think this plan represents a legitimate compromise > in what had previously seemed like a stalemate. While not my ideal outcome, > I think this is good for the WebRTC ecosystem - it ensures > interoperability, and provides a reasonably clear path for reaching a > completely RF solution. > > On Mon, Dec 8, 2014 at 9:27 AM, Martin Thomson > wrote: > >> On 8 December 2014 at 08:05, Harald Alvestrand >> wrote: >> > Since others who were present in the room are repeating their position >> > on the list, I'll do so too. >> >> That's probably a good thing to do. An almost anonymous humming sound >> isn't a good basis for establishing a record. >> >> > I support the rough consensus as presented by the chair. >> >> +1 >> >> _______________________________________________ >> 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 > > --e89a8f3bad45bc6cf50509b91e7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just to reiterate what I said in the room, I agree with th= is.

-Ekr


On Mon, Dec 8, 2014 at 6:39 PM, Justin= Uberti <juberti@google.com> wrote:
I support the rough consensus as presented by the chair.= =C2=A0

<= /div>
As stated bef= ore -=C2=A0I think this= plan represents a legitimate compromise in what had previously seemed like= a stalemate. While not my ideal outcome, I think this is good for the WebR= TC ecosystem - it ensures interoperability, and provides a reasonably clear= path for reaching a completely RF solution.

On Mon, Dec 8, 2014 at 9:27 AM, Martin Thomson <martin= .thomson@gmail.com> wrote:
= On 8 December 2014 at 08:05, Harald Alvestrand <harald@alvestrand.no> wrote:=
> Since others who were present in the room are repeating their position=
> on the list, I'll do so too.

That's probably a good thing to do.=C2=A0 An almost anonymous hu= mming sound
isn't a good basis for establishing a record.

> I support the rough consensus as presented by the chair.

+1

_______________________________________________
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


--e89a8f3bad45bc6cf50509b91e7f-- From nobody Mon Dec 8 11:18:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A961AC42A for ; Mon, 8 Dec 2014 09:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9R2TOLTTS4uH for ; Mon, 8 Dec 2014 09:21:07 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7CDB1AC426 for ; Mon, 8 Dec 2014 09:21:07 -0800 (PST) Received: from [10.0.0.38] (c-76-100-94-44.hsd1.md.comcast.net [76.100.94.44]) (Authenticated sender: negge@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 61928F2263 for ; Mon, 8 Dec 2014 09:21:07 -0800 (PST) Message-ID: <5485DE02.3090900@mozilla.com> Date: Mon, 08 Dec 2014 12:21:06 -0500 From: Nathan Egge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121208 Thunderbird/10.0.10 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5485CC5B.2030104@alvestrand.no> In-Reply-To: <5485CC5B.2030104@alvestrand.no> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/y2zVbP3qatismE18ObcQzHEaF7E X-Mailman-Approved-At: Mon, 08 Dec 2014 11:18:45 -0800 Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 17:21:11 -0000 +1 On 12/08/2014 11:05 AM, Harald Alvestrand wrote: > Since others who were present in the room are repeating their position > on the list, I'll do so too. > > I support the rough consensus as presented by the chair. > From nobody Mon Dec 8 11:33:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C881A007C for ; Mon, 8 Dec 2014 11:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjnJfXEsVz6T for ; Mon, 8 Dec 2014 11:33:46 -0800 (PST) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C021AC3D1 for ; Mon, 8 Dec 2014 11:33:20 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id id10so2482689vcb.19 for ; Mon, 08 Dec 2014 11:33:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yb11v3aD4z2gKzSB6h+QpRlTrZHCKWRFn9xIsKAtHls=; b=jFbPxeOG9Fi1yoFEUsMZjCJis5MaMP2+rubZsdZGbN7OIl8FDqaISSahDfnIiOYrff 3b5bUiPg149NavdHZG4FsT8VMvgklh5LpovuyVHuqon4Z8HtvCQon17FdxmbgUuNlfId Z8pFV1qIzhMSpwoKrDXjF4PVd2S+If/PwMrPyq9KEW1AgIzWSVOfeY6KUYeT0HRv0ml7 kkfgcuipXsAYq31pEwLaGOy6t49Nv9m2GOamJdRtLGGULPgglAgveKo16L4tO0wMQH36 F7cGfa4+HCh9eYMZ2QP9qCoSKFxQYZB8z+3n7INIP1Gi/KuFOXW6JeJde0K0k9eA6Xc/ JnAg== X-Gm-Message-State: ALoCoQkvVHB5Y8lNmtIR2r5pGQMY2+Ckz7w57MwuL89O3u4XQvv3QJAg4YXbTSSkvmOkyJmSawcj MIME-Version: 1.0 X-Received: by 10.52.37.72 with SMTP id w8mr22656622vdj.28.1418067199689; Mon, 08 Dec 2014 11:33:19 -0800 (PST) Received: by 10.52.75.66 with HTTP; Mon, 8 Dec 2014 11:33:19 -0800 (PST) In-Reply-To: <5485DE02.3090900@mozilla.com> References: <5485CC5B.2030104@alvestrand.no> <5485DE02.3090900@mozilla.com> Date: Mon, 8 Dec 2014 11:33:19 -0800 Message-ID: From: Gustavo Garcia To: Nathan Egge Content-Type: multipart/alternative; boundary=20cf307ac783b49a300509b97fc2 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fvVGOMkIpKlOIXWMULBKQOtur0I Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 19:33:49 -0000 --20cf307ac783b49a300509b97fc2 Content-Type: text/plain; charset=UTF-8 I support the rough consensus too (this is the least-worst option) On Mon, Dec 8, 2014 at 9:21 AM, Nathan Egge wrote: > +1 > > On 12/08/2014 11:05 AM, Harald Alvestrand wrote: > > Since others who were present in the room are repeating their position > > on the list, I'll do so too. > > > > I support the rough consensus as presented by the chair. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf307ac783b49a300509b97fc2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the rough consensus too (this is the least-worst= option)

On = Mon, Dec 8, 2014 at 9:21 AM, Nathan Egge <negge@mozilla.com>= wrote:
+1

On 12/08/2014 11:05 AM, Harald Alvestrand wrote:
> Since others who were present in the room are repeating their position=
> on the list, I'll do so too.
>
> I support the rough consensus as presented by the chair.
>

____________________________= ___________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--20cf307ac783b49a300509b97fc2-- From nobody Mon Dec 8 11:47:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF23A1A885D for ; Mon, 8 Dec 2014 11:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sncoNw9Pd7Mm for ; Mon, 8 Dec 2014 11:47:20 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D1DB1A00F1 for ; Mon, 8 Dec 2014 11:47:20 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so4571368wgg.33 for ; Mon, 08 Dec 2014 11:47:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=lP+GlYcHn+Z52muBDpu4c7F8RpXkserhb/p9IgOFGPE=; b=VUveUII+DLwL9moS4f8J91u+W63v/6pGR0Oq50VlI89TKkoqacZO4wEBYOe/vgfHG6 3bfd8gmt37Fvc5A28yelP5ajiADRAhJ26h17hIcPLkG66GI+gIrBS5Ahjq7RKQpaV8H2 XNe+GxvDi+iZMW9EHOTc2Kuz1zwajnqMDvyGJC18qf4pXKRPBIjTeOR+MJKDusol40pN iRmIf+5lTT7MuJ/1lL4TTXPnM7ISg6pDw3t/ZVPtBuSO21wQE+p1co0ZgGSY9jD7xOMZ m5UdE3F8qSPrPB2BJDOu93iwLSN0GcoCIltd5uA2+0+oFKmp/6VLVfyhLiiIWQFIZ5+o QtAw== X-Received: by 10.194.92.176 with SMTP id cn16mr47051695wjb.62.1418068038956; Mon, 08 Dec 2014 11:47:18 -0800 (PST) Received: from [192.168.0.194] ([95.61.111.78]) by mx.google.com with ESMTPSA id bs2sm40625120wjc.43.2014.12.08.11.47.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Dec 2014 11:47:18 -0800 (PST) Message-ID: <5486004C.3090007@gmail.com> Date: Mon, 08 Dec 2014 20:47:24 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Gaelle Martin-Cocher , "rtcweb@ietf.org" References: <92D0D52F3A63344CA478CF12DB0648AADF35B076@XMB111CNC.rim.net> <5485CD70.4010605@gmail.com> <92D0D52F3A63344CA478CF12DB0648AADF35B132@XMB111CNC.rim.net> In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF35B132@XMB111CNC.rim.net> Content-Type: multipart/alternative; boundary="------------000009060003050609030405" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RQF3PNOZQRrYADAWfR7sMAwGcl4 Subject: Re: [rtcweb] WebRTC endpoint non-browser X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 19:47:22 -0000 This is a multi-part message in MIME format. --------------000009060003050609030405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit They may be webrtc endpoints, or compatible-endpoints depending if they implement full webrtc-rtc stuff our just a minimum subset. Being specific, any mobile application not using a browser will be a webrtc endpoint. So I bet every single webrtc service will implement their own app, hence their own webrtc endpoint. Best regards Sergio On 08/12/2014 17:24, Gaelle Martin-Cocher wrote: > > You are listing webrtc-compatible endpoints, not webrtc "non browser" > endpoints. > > I am not asking of generic types of services but who actually belong > to the non browser endpoint category. > > Thanks > > Gaëlle > > *From:*rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Sergio > Garcia Murillo > *Sent:* Monday, December 08, 2014 11:10 AM > *To:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] WebRTC endpoint non-browser > > Native or custom applications, audio gateways, mcus, transcoders, SBCs... > > Best regards > Sergio > > > On 08/12/2014 17:03, Gaelle Martin-Cocher wrote: > > All, > > Is it possible to know who is going to develop services that > belongs to the WebRTC endpoint non-browser category? > > I think it would really help if we can identify that. > > Thanks, > > Gaëlle > > > > > > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > --------------000009060003050609030405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

They may be webrtc endpoints, or compatible-endpoints depending if they implement full webrtc-rtc stuff our just a minimum subset.

Being specific, any mobile application not using a browser will be a webrtc endpoint. So I bet every single webrtc service will implement their own app, hence their own webrtc endpoint.

Best regards
Sergio

On 08/12/2014 17:24, Gaelle Martin-Cocher wrote:

You are listing webrtc-compatible endpoints, not webrtc “non browser” endpoints.

I am not asking of generic types of services but who actually belong to the non browser endpoint category.

 

Thanks

Gaëlle

 

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio Garcia Murillo
Sent: Monday, December 08, 2014 11:10 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] WebRTC endpoint non-browser

 

Native or custom applications, audio gateways, mcus, transcoders, SBCs...

Best regards
Sergio


On 08/12/2014 17:03, Gaelle Martin-Cocher wrote:

All,

 

Is it possible to know who is going to develop services that belongs to the WebRTC  endpoint non-browser category?

I think it would really help if we can identify that.

Thanks,

 

Gaëlle








 




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

 


--------------000009060003050609030405-- From nobody Mon Dec 8 11:48:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BA61A8851 for ; Mon, 8 Dec 2014 11:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvmTxpgEV-89 for ; Mon, 8 Dec 2014 11:48:32 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1721A011E for ; Mon, 8 Dec 2014 11:48:31 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so5759690wiw.2 for ; Mon, 08 Dec 2014 11:48:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=wD8JIL6ooKXrRPSJK2szx/j8MQyqCEf1wHEgX6YRJVA=; b=tJjqkWm8nsXLps2QhovgWRCI4xnMj8lHXKQfeVjF9rPhX15dUB7/ZQCOwFMQ9hk2aC SNJUXfivSQbJAayvtyTVksVMVnPeKSCv5TFzg+Du2N3bohWMzuDjgSi2xW/bXzCK7/IN T1Hh9X3nNc1ZMQlcNO0qgbYkepCJPn9thBc1g5qJzjhnH9o6wAo1W3GzFthnMXaHTvLe ksc64CWXfvbESTHZ3o43ZA1cJnxm1yAO8FyuWEZ8+0+XYgWK3pxMwWTDN4pf/6JgsxWf xSRNUpDOccoSUkrYqRxuUDZJB16zjXi3vE2hpjj5vOV//inwQtQP/zZ60ArEYT9OPA7L q05Q== X-Received: by 10.180.88.33 with SMTP id bd1mr18495881wib.10.1418068110703; Mon, 08 Dec 2014 11:48:30 -0800 (PST) Received: from [192.168.0.194] ([95.61.111.78]) by mx.google.com with ESMTPSA id j1sm57811303wjw.25.2014.12.08.11.48.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Dec 2014 11:48:29 -0800 (PST) Message-ID: <54860094.6040703@gmail.com> Date: Mon, 08 Dec 2014 20:48:36 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <92D0D52F3A63344CA478CF12DB0648AADF35B076@XMB111CNC.rim.net> <5485CD70.4010605@gmail.com> <92D0D52F3A63344CA478CF12DB0648AADF35B132@XMB111CNC.rim.net> <92D0D52F3A63344CA478CF12DB0648AADF35B4D8@XMB111CNC.rim.net> In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF35B4D8@XMB111CNC.rim.net> Content-Type: multipart/alternative; boundary="------------090409000001040803030802" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TXnARlZGZONGGDPHnPvK_mSQ7AI Subject: Re: [rtcweb] WebRTC endpoint non-browser X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 19:48:34 -0000 This is a multi-part message in MIME format. --------------090409000001040803030802 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit The question, is who cares? My application will do whatever is needed for my service, implement one, two, three or none video codecs according to my business requirements. I don't really care (so won't my users) if you call it webrtc endpoint, webrtc-compatible endpoint or webrtc-non-compatible endpoint. So, from my point of view, we are just discussing about definitions of entities so we all speak same languages, any attempt to push a MTI codec is wishful thinking at best. Talking about reality, from my experience, most of the apps will be google's libwebrtc based, so they will implement whatever is provided in there. VP8 for sure, and h264 if supported by mobile and used by libwebrtc. On a side note, with current state of specs, a Microsoft based ORTC implementation on IE will be a webrtc endpoint. Best regards Sergio On 08/12/2014 19:00, Gaelle Martin-Cocher wrote: > > Do you have any concrete examples? > > Does this mobile app, needs to interact with another mobile app? > Again, I am looking for concrete example. > > I bet that every single webrtc service will be a webrtc compatible > endpoint. > > I would like to have a confirmation that this is not the case and that > those apps that you are mentioning will interact with other apps and > implement both codecs. > > Best, > > Gaëlle > > *From:*Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] > *Sent:* Monday, December 08, 2014 12:10 PM > *To:* Gaelle Martin-Cocher > *Subject:* RE: [rtcweb] WebRTC endpoint non-browser > > They may be webrtc endpoints, or compatible-endpoints depending if > they implement full webrtc-rtc stuff our just a minimum subset. > > Being specific, any mobile application not using a browser will be a > webrtc endpoint. So I bet every single webrtc service will implement > their own app, hence their own webrtc endpoint. > > Best regards > Sergio > > El 08/12/2014 17:24, "Gaelle Martin-Cocher" > > > escribió: > > You are listing webrtc-compatible endpoints, not webrtc “non browser†> endpoints. > > I am not asking of generic types of services but who actually belong > to the non browser endpoint category. > > Thanks > > Gaëlle > > *From:*rtcweb [mailto:rtcweb-bounces@ietf.org > ] *On Behalf Of *Sergio Garcia Murillo > *Sent:* Monday, December 08, 2014 11:10 AM > *To:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] WebRTC endpoint non-browser > > Native or custom applications, audio gateways, mcus, transcoders, SBCs... > > Best regards > Sergio > > > On 08/12/2014 17:03, Gaelle Martin-Cocher wrote: > > All, > > Is it possible to know who is going to develop services that > belongs to the WebRTC endpoint non-browser category? > > I think it would really help if we can identify that. > > Thanks, > > Gaëlle > --------------090409000001040803030802 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
The question, is who cares?

My  application will do whatever is needed for my service, implement one, two, three or none video codecs according to my business requirements. I don't really care (so won't my users) if you call it webrtc endpoint, webrtc-compatible endpoint or webrtc-non-compatible endpoint.

So, from my point of view, we are just discussing about definitions of entities so we all speak same languages, any attempt to push a MTI codec is wishful thinking at best.

Talking about reality, from my experience, most of the apps will be google's libwebrtc based, so they will implement whatever is provided in there. VP8 for sure, and h264 if supported by mobile and used by libwebrtc.

On a side note, with current state of specs, a Microsoft based ORTC implementation on IE will be a webrtc endpoint.

Best regards
Sergio
On 08/12/2014 19:00, Gaelle Martin-Cocher wrote:

Do you have any concrete examples?

Does this mobile app, needs to interact with another mobile app? Again, I am looking for concrete example.

I bet that every single webrtc service will be a webrtc compatible endpoint.

I would like to have a confirmation that this is not the case and that those apps that you are mentioning will interact with other apps and implement both codecs.

 

Best,

Gaëlle

 

 

From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com]
Sent: Monday, December 08, 2014 12:10 PM
To: Gaelle Martin-Cocher
Subject: RE: [rtcweb] WebRTC endpoint non-browser

 

They may be webrtc endpoints, or compatible-endpoints depending if they implement full webrtc-rtc stuff our just a minimum subset.

Being specific, any mobile application not using a browser will be a webrtc endpoint. So I bet every single webrtc service will implement their own app, hence their own webrtc endpoint.

Best regards
Sergio

El 08/12/2014 17:24, "Gaelle Martin-Cocher" <gmartincocher@blackberry.com> escribió:

You are listing webrtc-compatible endpoints, not webrtc “non browser†endpoints.

I am not asking of generic types of services but who actually belong to the non browser endpoint category.

 

Thanks

Gaëlle

 

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio Garcia Murillo
Sent: Monday, December 08, 2014 11:10 AM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] WebRTC endpoint non-browser

 

Native or custom applications, audio gateways, mcus, transcoders, SBCs...

Best regards
Sergio


On 08/12/2014 17:03, Gaelle Martin-Cocher wrote:

All,

 

Is it possible to know who is going to develop services that belongs to the WebRTC  endpoint non-browser category?

I think it would really help if we can identify that.

Thanks,

 

Gaëlle

--------------090409000001040803030802-- From nobody Mon Dec 8 11:53:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C0A1A0137 for ; Mon, 8 Dec 2014 11:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvw8UZ4cE_dl for ; Mon, 8 Dec 2014 11:53:16 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41EA81A011E for ; Mon, 8 Dec 2014 11:53:16 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wp4so4191833obc.11 for ; Mon, 08 Dec 2014 11:53:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CX9ZXQjJj6qRhupw9dKunlR2DYXxytHFOGPE5CimInE=; b=YI4fTEcmNuH0Cq+XBmwR8FK/IsMlszepPORs+S8Cg2dkH9BINwR/6eInBFojdmoD3H 2hafNuO1KojSxjWwKmwCvk5TkIQlkAVVnjgNTEZJXsfp5LhUJpwBf6sXNp5GAADRXzoo 2FUg2+gE3t5jtOOcx4kQXyMtF/lvzdxYLKmDJc0nA2vnipsxtfnIz7KYifFZH+GNZWP8 wV1F9oD005jXCPm1akXsE26jLet1TA5BdYLbYt/MwzQn++vBVqCIcGid7+5eiFRraRLu EcuE3/phUDOuQZVvWfZcXpRPuxL4Phb0B/HcGjGTUtr+Jam2AueQsPPqGjgcTxiDUPvY 5G6g== MIME-Version: 1.0 X-Received: by 10.182.165.69 with SMTP id yw5mr20797276obb.36.1418068395476; Mon, 08 Dec 2014 11:53:15 -0800 (PST) Received: by 10.202.227.77 with HTTP; Mon, 8 Dec 2014 11:53:15 -0800 (PST) In-Reply-To: <54860094.6040703@gmail.com> References: <92D0D52F3A63344CA478CF12DB0648AADF35B076@XMB111CNC.rim.net> <5485CD70.4010605@gmail.com> <92D0D52F3A63344CA478CF12DB0648AADF35B132@XMB111CNC.rim.net> <92D0D52F3A63344CA478CF12DB0648AADF35B4D8@XMB111CNC.rim.net> <54860094.6040703@gmail.com> Date: Mon, 8 Dec 2014 11:53:15 -0800 Message-ID: From: Dave Taht To: Sergio Garcia Murillo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bFbtIh-Xa90aQFvcv7XccDubvmI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC endpoint non-browser X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 19:53:18 -0000 I would like emacs support. I am not actually joking... I typically work in emacs with an erc window open and it would be nice to see who I am working with inside of emacs, rather than a browser. Have no idea how to do this.... /me goes to look at resiprocate.... On Mon, Dec 8, 2014 at 11:48 AM, Sergio Garcia Murillo wrote: > The question, is who cares? > > My application will do whatever is needed for my service, implement one, > two, three or none video codecs according to my business requirements. I > don't really care (so won't my users) if you call it webrtc endpoint, > webrtc-compatible endpoint or webrtc-non-compatible endpoint. > > So, from my point of view, we are just discussing about definitions of > entities so we all speak same languages, any attempt to push a MTI codec = is > wishful thinking at best. > > Talking about reality, from my experience, most of the apps will be googl= e's > libwebrtc based, so they will implement whatever is provided in there. VP= 8 > for sure, and h264 if supported by mobile and used by libwebrtc. > > On a side note, with current state of specs, a Microsoft based ORTC > implementation on IE will be a webrtc endpoint. > > Best regards > Sergio > On 08/12/2014 19:00, Gaelle Martin-Cocher wrote: > > Do you have any concrete examples? > > Does this mobile app, needs to interact with another mobile app? Again, I= am > looking for concrete example. > > I bet that every single webrtc service will be a webrtc compatible endpoi= nt. > > I would like to have a confirmation that this is not the case and that th= ose > apps that you are mentioning will interact with other apps and implement > both codecs. > > > > Best, > > Ga=C3=ABlle > > > > > > From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] > Sent: Monday, December 08, 2014 12:10 PM > To: Gaelle Martin-Cocher > Subject: RE: [rtcweb] WebRTC endpoint non-browser > > > > They may be webrtc endpoints, or compatible-endpoints depending if they > implement full webrtc-rtc stuff our just a minimum subset. > > Being specific, any mobile application not using a browser will be a webr= tc > endpoint. So I bet every single webrtc service will implement their own a= pp, > hence their own webrtc endpoint. > > Best regards > Sergio > > El 08/12/2014 17:24, "Gaelle Martin-Cocher" > escribi=C3=B3: > > You are listing webrtc-compatible endpoints, not webrtc =E2=80=9Cnon brow= ser=E2=80=9D > endpoints. > > I am not asking of generic types of services but who actually belong to t= he > non browser endpoint category. > > > > Thanks > > Ga=C3=ABlle > > > > > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio Garcia > Murillo > Sent: Monday, December 08, 2014 11:10 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] WebRTC endpoint non-browser > > > > Native or custom applications, audio gateways, mcus, transcoders, SBCs... > > Best regards > Sergio > > > On 08/12/2014 17:03, Gaelle Martin-Cocher wrote: > > All, > > > > Is it possible to know who is going to develop services that belongs to t= he > WebRTC endpoint non-browser category? > > I think it would really help if we can identify that. > > Thanks, > > > > Ga=C3=ABlle > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --=20 Dave T=C3=A4ht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks From nobody Mon Dec 8 12:07:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E261A8865 for ; Mon, 8 Dec 2014 12:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8f89To0OQz0d for ; Mon, 8 Dec 2014 12:07:27 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002-out2.apm-internet.net [85.119.248.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0DD1A01A9 for ; Mon, 8 Dec 2014 12:07:26 -0800 (PST) Received: (qmail 45344 invoked from network); 8 Dec 2014 20:07:24 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 13128 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 8 Dec 2014 20:07:24 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 800EA18A0B4C; Mon, 8 Dec 2014 20:07:19 +0000 (GMT) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 6744018A04C3; Mon, 8 Dec 2014 20:07:19 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_2CB902C5-0D93-45EE-B94F-CEAA0946D8A3" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Tim Panton In-Reply-To: Date: Mon, 8 Dec 2014 20:07:18 +0000 Message-Id: <4A665470-737A-424E-A5E1-610AB8EB826E@phonefromhere.com> References: <5485CC5B.2030104@alvestrand.no> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YhC1jHnutG0WdkTlau3iR3uoDoM Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 20:07:29 -0000 --Apple-Mail=_2CB902C5-0D93-45EE-B94F-CEAA0946D8A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 8 Dec 2014, at 17:39, Justin Uberti > wrote: >=20 > I support the rough consensus as presented by the chair.=20 >=20 > As stated before - I think this plan represents a legitimate = compromise in what had previously seemed like a stalemate. While not my = ideal outcome, I think this is good for the WebRTC ecosystem - it = ensures interoperability, and provides a reasonably clear path for = reaching a completely RF solution. >=20 > On Mon, Dec 8, 2014 at 9:27 AM, Martin Thomson = > wrote: > On 8 December 2014 at 08:05, Harald Alvestrand > wrote: > > Since others who were present in the room are repeating their = position > > on the list, I'll do so too. >=20 > That's probably a good thing to do. An almost anonymous humming sound > isn't a good basis for establishing a record. >=20 > > I support the rough consensus as presented by the chair. >=20 > +1 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = >=20 > ____ +1 P.S.=20 (Why are we still having this discussion? I feel like I fell into a time = vortex and wiped out 18 months of progress) Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk --Apple-Mail=_2CB902C5-0D93-45EE-B94F-CEAA0946D8A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 8 Dec 2014, at 17:39, Justin Uberti <juberti@google.com> = wrote:

I support the rough consensus as presented by the = chair. 

As stated before = - I = think this plan represents a legitimate compromise in what had = previously seemed like a stalemate. While not my ideal outcome, I think = this is good for the WebRTC ecosystem - it ensures interoperability, and = provides a reasonably clear path for reaching a completely RF = solution.

On Mon, Dec 8, 2014 at 9:27 AM, Martin Thomson = <martin.thomson@gmail.com> wrote:
On 8 = December 2014 at 08:05, Harald Alvestrand <harald@alvestrand.no> wrote:
> Since others who were present in the room are repeating their = position
> on the list, I'll do so too.

That's probably a good thing to do.  An almost anonymous = humming sound
isn't a good basis for establishing a record.

> I support the rough consensus as presented by the chair.

+1

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

____

+1

P.S. 
(Why are we still having this discussion? I feel like I fell = into a time vortex and wiped out 18 months of progress)


Tim Panton - = Web/VoIP consultant and implementor
www.westhawk.co.uk



= --Apple-Mail=_2CB902C5-0D93-45EE-B94F-CEAA0946D8A3-- From nobody Mon Dec 8 12:11:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD18C1A01E1 for ; Mon, 8 Dec 2014 12:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSBvWwhxkoRf for ; Mon, 8 Dec 2014 12:11:02 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809A61A017E for ; Mon, 8 Dec 2014 12:11:01 -0800 (PST) Received: (qmail 98719 invoked from network); 8 Dec 2014 20:10:59 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 13139 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 8 Dec 2014 20:10:59 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id C5F8418A06B5; Mon, 8 Dec 2014 20:10:55 +0000 (GMT) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id B6E7F18A04C3; Mon, 8 Dec 2014 20:10:55 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Tim Panton In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF35B343@XMB111CNC.rim.net> Date: Mon, 8 Dec 2014 20:09:52 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <8D9BE505-B27E-4845-B635-6B97FB6A5650@phonefromhere.com> References: <92D0D52F3A63344CA478CF12DB0648AADF35B076@XMB111CNC.rim.net> <5485CD70.4010605@gmail.com> <92D0D52F3A63344CA478CF12DB0648AADF35B132@XMB111CNC.rim.net> <92D0D52F3A63344CA478CF12DB0648AADF35B343@XMB111CNC.rim.net> To: Gaelle Martin-Cocher , "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Qs5EWT0tEQQbGSSMoJcNcL6O9pA Subject: Re: [rtcweb] WebRTC endpoint non-browser X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 20:11:04 -0000 > On 8 Dec 2014, at 17:24, Gaelle Martin-Cocher = wrote: >=20 > Are you building such app? Yes. I am currently working on the android version of one. see = https://yopet.us for a rough idea. I need native capabilites to manage notifications and wake/sleep = interactions so it can't be just a browser app (as shown in the old video) From nobody Mon Dec 8 12:17:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248151A6F1E for ; Mon, 8 Dec 2014 12:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zk_0VMZJuWsA for ; Mon, 8 Dec 2014 12:17:24 -0800 (PST) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473D21A01FA for ; Mon, 8 Dec 2014 12:17:24 -0800 (PST) Received: by mail-yh0-f51.google.com with SMTP id a41so2632480yho.24 for ; Mon, 08 Dec 2014 12:17:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AJryg6hjeLxwXer72ZUW3dVp3Z00nFg09Jae+wrKVOE=; b=RczmcpO+XBxnPbgBrp8vYYTjihgNVtFh5LiaNMvPdlIzXYJIMl6hqECdRxHM1qxK3r ZV7v9vyQXOWl3lCEF9xvOyv1om5d45YTjLwWTBBlHMci32GALakt0xbgqAOoaIXRdeS4 lsekKS+WtwjglAcOXHWhga27JJ8PXGklMixnNMS9yK2ehBhmA2OeoYjuVfs7j2ApqW3J /94hnk4T2P95I/r7ctbPu4KqeB3nkIIxLmQvpE0miLaEbVVz0Z9jVgYaLKCA1PhGzRrX R+0tlq8omGgcGs4oMmugGf5H+yjryb2iJ7DZFMi8FxK1paN4ZdNA/s5KT9r/8BonJ039 IvJw== MIME-Version: 1.0 X-Received: by 10.236.230.104 with SMTP id i98mr31239602yhq.169.1418069843487; Mon, 08 Dec 2014 12:17:23 -0800 (PST) Received: by 10.170.135.193 with HTTP; Mon, 8 Dec 2014 12:17:23 -0800 (PST) Received: by 10.170.135.193 with HTTP; Mon, 8 Dec 2014 12:17:23 -0800 (PST) In-Reply-To: References: <5485CC5B.2030104@alvestrand.no> Date: Tue, 9 Dec 2014 07:17:23 +1100 Message-ID: From: Silvia Pfeiffer To: Justin Uberti Content-Type: multipart/alternative; boundary=089e01634d6c49b3d70509ba1d46 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QG0aBaor2iIn4nTEgES8sTLs5Ns Cc: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 20:17:27 -0000 --089e01634d6c49b3d70509ba1d46 Content-Type: text/plain; charset=UTF-8 I wasn't at the meeting, but I too support the compromise. It's non optimal, but pragmatic and all that's achievable in the given circumstances. Best Regards, Silvia. On 9 Dec 2014 04:40, "Justin Uberti" wrote: > I support the rough consensus as presented by the chair. > > As stated before - I think this plan represents a legitimate compromise > in what had previously seemed like a stalemate. While not my ideal outcome, > I think this is good for the WebRTC ecosystem - it ensures > interoperability, and provides a reasonably clear path for reaching a > completely RF solution. > > On Mon, Dec 8, 2014 at 9:27 AM, Martin Thomson > wrote: > >> On 8 December 2014 at 08:05, Harald Alvestrand >> wrote: >> > Since others who were present in the room are repeating their position >> > on the list, I'll do so too. >> >> That's probably a good thing to do. An almost anonymous humming sound >> isn't a good basis for establishing a record. >> >> > I support the rough consensus as presented by the chair. >> >> +1 >> >> _______________________________________________ >> 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 > > --089e01634d6c49b3d70509ba1d46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I wasn't at the meeting, but I too support the compromis= e. It's non optimal, but pragmatic and all that's achievable in the= given circumstances.

Best Regards,
Silvia.

On 9 Dec 2014 04:40, "Justin Uberti" &= lt;juberti@google.com> wrote:<= br type=3D"attribution">
I support the rough consensus as = presented by the chair.=C2=A0

As stated before -=C2=A0I think this plan represents a legitimate compromise in what had previo= usly seemed like a stalemate. While not my ideal outcome, I think this is g= ood for the WebRTC ecosystem - it ensures interoperability, and provides a = reasonably clear path for reaching a completely RF solution.

On Mon, Dec 8= , 2014 at 9:27 AM, Martin Thomson <martin.thomson@gmail.com>= wrote:
On 8 December 2014 a= t 08:05, Harald Alvestrand <harald@alvestrand.no> wrote:
> Since others who were present in the room are repeating their position=
> on the list, I'll do so too.

That's probably a good thing to do.=C2=A0 An almost anonymous hu= mming sound
isn't a good basis for establishing a record.

> I support the rough consensus as presented by the chair.

+1

_______________________________________________
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

--089e01634d6c49b3d70509ba1d46-- From nobody Mon Dec 8 12:31:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719641ACE20 for ; Mon, 8 Dec 2014 12:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRha8J5ajvw3 for ; Mon, 8 Dec 2014 12:31:19 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id E677C1ACE21 for ; Mon, 8 Dec 2014 12:31:18 -0800 (PST) Received: from [IPv6:2001:470:40b8:0:8d1e:824c:377f:a248] (unknown [IPv6:2001:470:40b8:0:8d1e:824c:377f:a248]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 51967204A4 for ; Mon, 8 Dec 2014 21:31:16 +0100 (CET) Message-ID: <54860A92.8000707@acm.org> Date: Mon, 08 Dec 2014 13:31:14 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IPYi-hIgt9hMKDWX9wztXjPQ4-g Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 20:31:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I support the rough consensus reached during the meeting.. On 12/05/2014 06:36 AM, Sean Turner wrote: > All, > > At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about codecs, which I dubbed "the great codec compromise." The compromise text that was discussed appears in slides 12-14 at [4] (which is a slight editorial variation of the text proposed at [2]). > > This message serves to confirm the sense of the room. > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUhgqSAAoJECnERZXWan7EpzIP/jrUYORvOhx6Dj7gZENSzqjz Tx71LC0djkdjU7U7uIQoxLLh1QhiZ69nxNRPl5UBo3tgCVc/Rm0CgyAfttsEbG48 lj4gO00IpgqA78oA/X5oTdlu3/IDwyG64fYVzYXXgRLAnWHINQWNwZGrzc+x0+xC oDU/+pHj6dc3SNDfkPK2+msNssi+qJQM26qLgg0c2Ku3YA2uv1CmCJA9pMj1VkF0 O76nN3ERlVJZuvr5yWLH5w5ruESccHM/HvCNvO7KBcqZ1kJDVYok/Ag1zHV5lnBl H3QUYRcEUkRT6ANxuKx8i6m/RH/Fhel9P5X9L++7bqkaBMJu6ACCDiszyYiAjqLU pgrL4um6ddH6xC6SeGSn5jWeAg4kv+t9U2yUKKCgCv7ivrcaE9P6ePuiQf4FegF4 /jO/tJMPzVGFv0Vwpa9PiCMzILmS2CiJ+hyjmkRImfC4MkGteB4cahxsFi5XZ61j Lc0HSUmNH2Anl4PobfX+I+q+nPoNV5+Akp4zTSaNkKgvEjzsClmiLMWpN43ekCFD iUz7mhd+q7lW+lMBiAhtSe0Xyaa5JP+JTbX2OOgIVJ97U391ftjiJpeMnc09r2pF eyVibOjFO67+QaLCOVCSJdPMOWz12tBJRs6uMXMNJlN8x7VwQ/LO7hIxLxWO6/Ar wiqeqPAc3R/IXs5t6MKx =5ygP -----END PGP SIGNATURE----- From nobody Mon Dec 8 12:34:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E591ACE37 for ; Mon, 8 Dec 2014 12:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vqv9H2A_yEf2 for ; Mon, 8 Dec 2014 12:34:54 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D97DA1ACE38 for ; Mon, 8 Dec 2014 12:34:53 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y19so7128353wgg.14 for ; Mon, 08 Dec 2014 12:34:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=etetVv/bbxTj4aTOT3ahuh5B0SUMYVFX/k1ILXndRg0=; b=Malm4+XyseepT4i2rx7QiUuPpJPQnWVMPk3+4OPH/i4OH5Tagsn2yylKt/t1kwqAb0 E/fIUtHC2OiFN2jxx/zrEISAbNGGHgimJgpFu/sQ8nPExVQAIYjBqFsd6eh2z5Iuhd2c AVpKGFR58IBKwMxAnGo/z3Xx64FYsthsfMYbS0evfSGrj0SSTfa3scR6dQBg3QpaisxD P9MSREAI5XmCzchdjwztRHSIfH67LyIbhhPJwm+D7jDCbfKhRChANNflr1AvkIXnmN9G ixKl2JnO3pDweuksVCb7UN8xdlBIUYiKd+7sgWrtLNROTyHW4BfV4nKyuTLGZ88A6s6V y6Yg== X-Received: by 10.194.62.76 with SMTP id w12mr48540217wjr.5.1418070892704; Mon, 08 Dec 2014 12:34:52 -0800 (PST) Received: from Saturns-MBP.fritz.box ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id ef1sm11135573wic.0.2014.12.08.12.34.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Dec 2014 12:34:51 -0800 (PST) Message-ID: <54860B69.4090505@gmail.com> Date: Mon, 08 Dec 2014 21:34:49 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Ted Hardie References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <32C6F602-6818-4A36-B18E-BF21774F6761@apple.com> <20141205035706.GB21150@hex.shelbyville.oz> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OZw6pUdirnU-S-r5ScO4W5O4REo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.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: Mon, 08 Dec 2014 20:34:55 -0000 On 08/12/14 18:43, Iñaki Baz Castillo wrote: > 2014-12-05 20:55 GMT+01:00 Ted Hardie : >> This is fundamentally incorrect. The IETF writes voluntary standards. A >> MUST in an IETF standard is not an instruction to a company; it is a >> description of the expected behaviour of an interoperable implementation. >> You are not required to implement the standard at all. At most, it is a >> description of what someone who claimed compliance to the standard is >> expected to have done. > Let's imagine I want to build a new open-source browser from scratch > in my spare time. You don't need to build one from scratch, but make a custom build of an existing open source browser (e.g., from firefox, konqueror or chromium), say for removing some unnecessary 'features' or tailor it for special environment (e.g., remove/disable tcp to be sure it's on tls always). This kind of 'forking' is legit, anyone can do it without breaking exiting license and such variants already exist (ed). Cheers, Daniel > Basically (if I was smart enough) I could conform > with all the W3C specs... Really? can I safely include VP8 and H264 > (existing libraries or my own implementation of both) into my > open-source browser and publish the project and its source code? > > The "MUST implement VP8 and H264" is a break line in the W3C, meaning > that from now on just big vendors (those who can deal with licensing > stuff) can conform with the specifications. And that is no good at > all. > > -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From nobody Mon Dec 8 12:42:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FC41ACE58 for ; Mon, 8 Dec 2014 12:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2vx50C8Y82Z for ; Mon, 8 Dec 2014 12:42:25 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58E01ACE3E for ; Mon, 8 Dec 2014 12:42:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4437; q=dns/txt; s=iport; t=1418071344; x=1419280944; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=gJEtfTW3THxBgFSEa33uikyo7xdUMuN279hWwSQLa2E=; b=kyy3ZGlzF1vb/RSEOOTaL2YTQzHpgh3RpACPe5YlWNq8bLl80yMr5C4l 0nQVJwvUph1M6Q4xHAWZKeIQS/lcXxhRF94NaS5RweaGgt+mpAGoNzFuS iwJWHmu56pOTtEtNXPXgqkAeeLqSoUz806F5g5/ZOefVgHM9Yei5Z/wwo w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAKcMhlStJA2F/2dsb2JhbABZgwZSXMVlCoU7TgKBNBYBAQEBAX2EAwEBAgIBAQFrGwIBCEYnCyUCBAESCYgvDdYnAQEBAQEBBAEBAQEBAQEbj2sBARw1BYQ2BYkZhHSHHIF5gQ0NglKHSoY0g25vAYELOX4BAQE X-IronPort-AV: E=Sophos;i="5.07,540,1413244800"; d="scan'208";a="103779792" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP; 08 Dec 2014 20:42:24 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sB8KgORA004377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Dec 2014 20:42:24 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.121]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 14:42:24 -0600 From: "Mo Zanaty (mzanaty)" To: Sean Turner , "rtcweb@ietf.org" Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEyd3NIZ3XBlQlk60/sgruTGNow== Date: Mon, 8 Dec 2014 20:42:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.81.3.37] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lcqGQ5asHisQlkurPuPiMncNC58 Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 20:42:27 -0000 I support the rough consensus reached in the meeting. I support those willing to accept this compromise, and agree with the chair declaring that was the dominant sense of the room. I also support those unable to implement this compromise at this time for their stated reasons, in the sense that I understand their reasons for their reasonable positions. Despite the potential future importance of the current minority positions, I think proceeding with this compromise propels WebRTC forward on an important issue, because no other proposal has come remotely close to achieving even rough consensus. To reiterate another point from the meeting, there are technical advantages to supporting multiple codecs. Dynamic discovery of local capabilities, negotiation of remote capabilities, understanding how different error resilience mechanisms can work (or not) with different codecs, faster adoption of new (non-mandatory) codecs, easier path to deprecating old (mandatory) codecs, etc. All those legs never get exercised effectively in single-codec implementations, leaving land mines in browsers, apps, services and sometimes even specs. They become easier or free once the groundwork is laid for multiple codecs. While some have argued against that extra complexity, I see it as essential for any important standard. Mo On 12/5/14, 8:36 AM, Sean Turner wrote: All, At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about codecs, which I dubbed "the great codec compromise." The compromise text that was discussed appears in slides 12-14 at [4] (which is a slight editorial variation of the text proposed at [2]). This message serves to confirm the sense of the room. In the room, I heard the following objections and responses (and I=B9m paraphrasing here), which I=B9ll take the liberty of categorizing as IPR, Time, and Trigger: 1) IPR: Objections: There are still IPR concerns which may restrict what a particular organization feels comfortable with including in their browser implementations. Response: IPR concerns on this topic are well known. There is even a draft summarizing the current IPR status for VP8: draft-benham-rtcweb-vp8litigation. The sense of the room was still that adopting the compromise text was appropriate. 2) Time: 2.1) Time to consider decision: Objection: The decision to consider the compromise proposal at this meeting was provided on short notice and did not provide some the opportunity to attend in person. Response: Six months ago the chairs made it clear discussion would be revisited @ IETF 91 [0]. The first agenda proposal for the WG included this topic [1], and the topic was never removed by the chairs. More importantly, all decisions are confirmed on list; in person attendance is not required to be part of the process. 2.2) Time to consider text: Objection: The proposed text [2] is too new to be considered. Response: The requirement for browsers to support both VP8 and H.264 was among the options in the straw poll conducted more than six months ago. All decisions are confirmed on list so there will be ample time to discuss the proposal. 3) Trigger: Objection: The =B3trigger=B2 sentence [3] is all kinds of wrong because it= =B9s promising that the future IETF will update this specification. Response: Like any IETF proposal, an RFC that documents the current proposal can be changed through the consensus process at any other time. After the discussion, some clarifying questions about the hums, and typing the hum questions on the screen, there was rough consensus in the room to add (aka =B3shove=B2) the proposed text into draft-ietf-rtcweb-video. In keeping with IETF process, I am confirming this consensus call on the list. If anyone has any other issues that they would like to raise please do by December 19th. Cheers, spt (as chair) [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html [3] The one that begins with "If compelling evidence ..." [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Dec 8 13:03:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB6D1A1A48 for ; Mon, 8 Dec 2014 13:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddtZg7LdGauG for ; Mon, 8 Dec 2014 13:03:25 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 87E0D1A1A1D for ; Mon, 8 Dec 2014 13:03:24 -0800 (PST) Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail06.adl6.internode.on.net with ESMTP; 09 Dec 2014 07:33:23 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 53E79FFC86 for ; Tue, 9 Dec 2014 07:33:22 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3MakiaCzyRSi for ; Tue, 9 Dec 2014 07:33:20 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 7D229FFBC1 for ; Tue, 9 Dec 2014 07:33:20 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 712DC80470; Tue, 9 Dec 2014 07:33:20 +1030 (ACDT) Date: Tue, 9 Dec 2014 07:33:20 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141208210320.GF19538@hex.shelbyville.oz> References: <54820E74.90201@mozilla.com> <5485E627.5050706@jesup.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PRCo95g5N2pw4-nXNzx-o25OOto Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 21:03:28 -0000 On Mon, Dec 08, 2014 at 07:00:28PM +0100, Iñaki Baz Castillo wrote: > 2014-12-08 18:55 GMT+01:00 Randell Jesup : > > +1 - it's by no means my preferred solution, but it's one I can live with, > > and better than the alternative of the status-quo - no MTI at all. If it > > wasn't for OpenH264, my answer would be different. > > > > I can't see adopting H.264 as sole MTI, and I can't see that we'd get > > consensus to adopt VP8 as sole MTI. > > There was a much better solution: > > - And a W3C compromise: First video codec 100% royalty free would > become MTI in WebRTC. We've had a 100% RF codec on the table since the very beginning. Two if you include the later proposal of H.261 as the MTI fallback. (three if you include theora ...) We apparently failed to get consensus on either of those as sole MTI. I think the consensus that we do have, which at least includes an RF video codec, is better than perpetuating the chaos of no MTI. So I also confirm my support for this as being the consensus of the group. I still have a tiny candle burning with the hope that the people who have so far done everything they could to try to thwart having a single RF MTI codec, will finally come to their senses and pull the trigger we've given them to enable that to still happen. But even if they don't, I think this standard will benefit far more from this agreement than it would by letting the obstructing factions keep us locked in a stalemate with no MTI video at all. Ever the optimist, Ron > Things would be exactly as they are now, but at least we avoid a > "MUST" that will be ignored by 50% of the market. I'm not sure I follow your logic here? Right now 100% of the current implementations have not ignored this. That includes something like 75% of the browser user market share. The rest of the market will do whatever their market research dept. tells them their customers want them to do. This compromise gives the best chance for people who really are wedged through no fault of their own to be able to produce something that still will interop with that majority of 'the market'. The only people currently claiming they are inclined to ignore this are people who so far have shown no real indication that they are going to do anything but ignore this standard anyway, regardless of what we specify about anything. While the IETF does give everyone a voice to express real technical concerns and propose solutions, I don't think it grants a veto to people who simply want to obstruct something they feel their business is threatened by. Whatever their "market share". Anyway, if you want to discuss that (again), we probably ought to move it off the "sense of the room" thread, so as not to make the hard job of the chairs even harder :) From nobody Mon Dec 8 13:38:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86ABD1A88E9 for ; Mon, 8 Dec 2014 13:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfQbN1AyXHTR for ; Mon, 8 Dec 2014 13:38:53 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 07FC81A8931 for ; Mon, 8 Dec 2014 13:38:52 -0800 (PST) Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail06.adl6.internode.on.net with ESMTP; 09 Dec 2014 08:08:51 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 8A5B6FFC86; Tue, 9 Dec 2014 08:08:50 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ycqlH9hgzIyJ; Tue, 9 Dec 2014 08:08:50 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 11613FFB47; Tue, 9 Dec 2014 08:08:50 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 05B7980470; Tue, 9 Dec 2014 08:08:49 +1030 (ACDT) Date: Tue, 9 Dec 2014 08:08:49 +1030 From: Ron To: "Mo Zanaty (mzanaty)" Message-ID: <20141208213849.GG19538@hex.shelbyville.oz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ISZhl9i-jPA-OxGIB03NIwFAYWE Cc: rtcweb@ietf.org Subject: [rtcweb] Interop *and* robustness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 21:38:54 -0000 On Mon, Dec 08, 2014 at 08:42:23PM +0000, Mo Zanaty (mzanaty) wrote: > I support the rough consensus reached in the meeting. I support those > willing to accept this compromise, and agree with the chair declaring that > was the dominant sense of the room. I also support those unable to > implement this compromise at this time for their stated reasons, in the > sense that I understand their reasons for their reasonable positions. > Despite the potential future importance of the current minority positions, > I think proceeding with this compromise propels WebRTC forward on an > important issue, because no other proposal has come remotely close to > achieving even rough consensus. > > To reiterate another point from the meeting, there are technical > advantages to supporting multiple codecs. Dynamic discovery of local > capabilities, negotiation of remote capabilities, understanding how > different error resilience mechanisms can work (or not) with different > codecs, faster adoption of new (non-mandatory) codecs, easier path to > deprecating old (mandatory) codecs, etc. All those legs never get > exercised effectively in single-codec implementations, leaving land mines > in browsers, apps, services and sometimes even specs. They become easier > or free once the groundwork is laid for multiple codecs. While some have > argued against that extra complexity, I see it as essential for any > important standard. I think this might actually be the most sensible and important new thing anyone has actually said on the list on this topic for a long time now :) It gives me that warm fuzzy sense of hope that this is not just a difficult compromise we've become resigned to, but actually something with some real technical merits all of its own. It hadn't really crossed my mind in this discussion that there'd be some implementers who really would just ignore the whole negotiation thing to hardcode only their preferred codec -- which is kind of like saying I'd not thought about what colour my hair is, I don't have to think for very long to know what the real world answer to that would be. Thanks for bringing this up for those of us who didn't make it to the meeting and have been too busy to watch the recording yet! Ron From nobody Mon Dec 8 13:40:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF0D1A90E7 for ; Mon, 8 Dec 2014 13:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URq_otOErJEY for ; Mon, 8 Dec 2014 13:40:45 -0800 (PST) Received: from relay.mailchannels.net (tkt-001-i354.relay.mailchannels.net [174.136.5.215]) by ietfa.amsl.com (Postfix) with ESMTP id 996081A8943 for ; Mon, 8 Dec 2014 13:40:44 -0800 (PST) X-Sender-Id: wwwh|x-authuser|mdr%reavy.org@r2-chicago.webserversystems.com Received: from r2-chicago.webserversystems.com (ip-10-204-4-183.us-west-2.compute.internal [10.204.4.183]) by relay.mailchannels.net (Postfix) with ESMTPA id 9C8A1ADE50 for ; Mon, 8 Dec 2014 21:40:39 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|mdr%reavy.org@r2-chicago.webserversystems.com Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.245.17.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.2); Mon, 08 Dec 2014 21:40:42 GMT X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|mdr%reavy.org@r2-chicago.webserversystems.com X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1418074841831:3345634858 X-MC-Ingress-Time: 1418074841831 Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:54248 helo=[192.168.1.19]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xy62n-0006sc-CS for rtcweb@ietf.org; Mon, 08 Dec 2014 15:40:37 -0600 Message-ID: <54861AD6.8090603@reavy.org> Date: Mon, 08 Dec 2014 16:40:38 -0500 From: Maire Reavy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54820E74.90201@mozilla.com> In-Reply-To: <54820E74.90201@mozilla.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AuthUser: mdr%reavy.org@r2-chicago.webserversystems.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/W3EelTYtRBdWDho3HoS75NEIEE8 Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 21:40:48 -0000 On 12/5/2014 2:58 PM, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Considering that: > 1) We have committed to an MTI video codec > 2) All consensus calls on "VP8 only" and "H.264 only" have failed > 3) This is the only proposal that gets support from both camps > I strongly support this MTI proposal. > Please, let's close this debate once and for all. This compromise is > by no means great, but it's much better than anything else we're going > to get otherwise (i.e. more wasted time and still no MTI). A big +1 We have spent *so* many hours already considering, discussing, & debating what to do about the MTI video codec. One could argue an "insane amount" of time relative to the other issues we need to resolve. We did this because most of us realized that "no MTI" could be horrific for the standard. We should embrace consensus around anything less than horrific, and most of us agree that this compromise is less than horrific (not great, but less than horrific). Right now I fear we're on the verge of shooting ourselves in the foot or head (I'm not sure which) by reopening this discussion even though we're in sight of the end. I ask that the working group and the chairs put the proverbially safety back on the gun, declare consensus on this less-than-horrific proposal, and finish our work on "v1.0" of the spec. Please. -Maire ------------------------- Maire Reavy mdr@reavy.org From nobody Mon Dec 8 13:49:37 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A097F1A8943 for ; Mon, 8 Dec 2014 13:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.957 X-Spam-Level: X-Spam-Status: No, score=-0.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gno84briflGg for ; Mon, 8 Dec 2014 13:49:36 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6B01A8942 for ; Mon, 8 Dec 2014 13:49:35 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id n15so4535328lbi.16 for ; Mon, 08 Dec 2014 13:49:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc:content-type; bh=BrnQuUVarJ6iXnX8VKSpGdFTwGl5aO5cAhRIEz1lJGw=; b=UE6JZn8XWKtM6yqqfDxuJbOEaSuou6jB3D7igKJM9GvWT+7lVCCFnLHtd+6n3xwdog coJXDMdHjDgWnMZfnWmTbfkSbejdYnbyRkUVCsxxM6SdP9tsUs9sBtuRw2rnZ7MUGF+u +S2GdCADGEdhadXwAZCqYqugGcCyfGO5/N609hz4rC5bdWytSiolrMvXzU2giyKm6vsz It64vTE2hX83L2liMjA5BDNWadtdf5vC1Owa7oHhdZ3YW9ix4j07+CcXfuFVNFyFn6rn cGJYCHVy4/6gy8bnTwTUGVEcJO3l3DMd83mO2YuN475f5Oa8IM/Afl+jDmiNM6s8qU4k 1law== X-Gm-Message-State: ALoCoQkwLxn8y8CN0ru+52YDuXtcWAPsDsQMiqY+HOnnizJPZ3KWcIPxKfXyCWVEcRgd5LR8RtDJ MIME-Version: 1.0 X-Received: by 10.112.201.226 with SMTP id kd2mr18481530lbc.98.1418075374105; Mon, 08 Dec 2014 13:49:34 -0800 (PST) Received: by 10.25.84.145 with HTTP; Mon, 8 Dec 2014 13:49:33 -0800 (PST) In-Reply-To: <54861AD6.8090603@reavy.org> References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> Date: Mon, 8 Dec 2014 14:49:33 -0700 Message-ID: From: Simon Perreault Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a11c37eb4f04a570509bb66d1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dWXLKy5lKG47ggWPIGOzMUrvwIQ Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 21:49:36 -0000 --001a11c37eb4f04a570509bb66d1 Content-Type: text/plain; charset=UTF-8 I, too, support the Honolulu compromise. Simon --001a11c37eb4f04a570509bb66d1 Content-Type: text/html; charset=UTF-8
I, too, support the Honolulu compromise.

Simon
--001a11c37eb4f04a570509bb66d1-- From nobody Mon Dec 8 15:28:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2621A008B for ; Mon, 8 Dec 2014 15:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2Jex-YWtD6g for ; Mon, 8 Dec 2014 15:28:44 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id C86041A0062 for ; Mon, 8 Dec 2014 15:28:43 -0800 (PST) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 08 Dec 2014 18:28:34 -0500 Received: from XCT104CNC.rim.net (10.65.161.204) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.210.2; Mon, 8 Dec 2014 18:28:34 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Mon, 8 Dec 2014 18:28:34 -0500 From: Andrew Allen To: Maire Reavy , "rtcweb@ietf.org" Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEJCKEBti1FXXNkmH1ALOez9gJ5yBvm8AgATTdwD//69UkA== Date: Mon, 8 Dec 2014 23:28:33 +0000 Message-ID: References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> In-Reply-To: <54861AD6.8090603@reavy.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vhZ_w4cW8uoH0QIWU3Er9G7Izj0 Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 23:28:46 -0000 We are not re-opening this discussion. This list discussion is the decision= making process. What took place in Honolulu was only a consensus hum of those present in th= e room. In IETF all decisions are made on the list and it was clearly stated by the= chair in Honolulu that the decision would need to be endorsed on the list. On 1) We have committed to an MTI video codec I note the small word "an". If we decide on two MTI video codecs then we have clearly failed to meet th= is commitment. On 3) This is the only proposal that gets support from both camps As David pointed out we are not in two monolithic camps (this isn't the col= d war here). Different companies and different individuals have different p= ositions for different reasons. The fact that some people who might have be= en perceived as being in "one camp" have found a way to agree to a "comprom= ise" based upon a definition that doesn't force them in their product to im= plement what they don't agree to implement does not mean that the fundament= al reason behind the difficulty in reaching consensus on MTI video codecs b= y those whose products would be forced to implement both codecs has changed= . It's very easy to agree to someone else to have to do something that you ar= e not willing to do yourself. Andrew -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Maire Reavy Sent: Monday, December 08, 2014 4:41 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec On 12/5/2014 2:58 PM, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Considering that: > 1) We have committed to an MTI video codec > 2) All consensus calls on "VP8 only" and "H.264 only" have failed > 3) This is the only proposal that gets support from both camps I=20 > strongly support this MTI proposal. > Please, let's close this debate once and for all. This compromise is=20 > by no means great, but it's much better than anything else we're going=20 > to get otherwise (i.e. more wasted time and still no MTI). A big +1 We have spent *so* many hours already considering, discussing, & debating w= hat to do about the MTI video codec. One could argue an "insane amount" of= time relative to the other issues we need to resolve. We did this because= most of us realized that "no MTI" could be horrific for the standard. We = should embrace consensus around anything less than horrific, and most of us= agree that this compromise is less than horrific (not great, but less than= horrific). Right now I fear we're on the verge of shooting ourselves in the foot or he= ad (I'm not sure which) by reopening this discussion even though we're in s= ight of the end. I ask that the working group and the chairs put the prove= rbially safety back on the gun, declare consensus on this less-than-horrifi= c proposal, and finish our work on "v1.0" of the spec. Please. -Maire ------------------------- Maire Reavy mdr@reavy.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Dec 8 15:46:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959251A0203 for ; Mon, 8 Dec 2014 15:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wIWDgtZ-uO0 for ; Mon, 8 Dec 2014 15:46:37 -0800 (PST) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3056C1A0073 for ; Mon, 8 Dec 2014 15:46:36 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id w7so4359656qcr.14 for ; Mon, 08 Dec 2014 15:46:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=sc0eyCIsCnG7TL+AXiciBFJK0vob9bfDpI3ShDUHV70=; b=FXKYaXckWQVsc1jIHPJyBgz8tUv12XwRUMLVxEDaYRaqzLdzFpKxDdh7fOydrShXuG /GXSrzcOLgSuwTaGzGVFMfUILbLa3fJY1CvAQ8va0MZ0JDs7c94m23r+T0tSb9QOCJLp m9hPQyXNktTfGrBWSUksZhyiEf4Fd8982h1rmP7oowPLf3EGdkW3hTyf5dIrNBc4xgp+ vIqKw13hSq9ud9iFcDPN45ZUXpmt7nC/aj2sGQ3/NyLqY2PGiwxL5cuAVmG+9Qhr2s7f cVVRVlLMQ1JsD7j/qDSPWn/8GcwW383l6wgJLSE8GMIle+xXeLedqAZ109T3d0u3OWTN qWiQ== X-Gm-Message-State: ALoCoQllO4Q8IxCKGl9lVgcgtOY3vcbYKYjGMPgtqn4AV+vcQxCqPKplPu4xTq/hLXP3f/2Pql5c X-Received: by 10.229.196.70 with SMTP id ef6mr108796qcb.31.1418082395366; Mon, 08 Dec 2014 15:46:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Mon, 8 Dec 2014 15:46:15 -0800 (PST) In-Reply-To: <20141208210320.GF19538@hex.shelbyville.oz> References: <54820E74.90201@mozilla.com> <5485E627.5050706@jesup.org> <20141208210320.GF19538@hex.shelbyville.oz> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 9 Dec 2014 00:46:15 +0100 Message-ID: To: Ron Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/K-VlWL0ohUIUxnFZnOC9ySwcpc4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 23:46:38 -0000 2014-12-08 22:03 GMT+01:00 Ron : > On Mon, Dec 08, 2014 at 07:00:28PM +0100, I=C3=B1aki Baz Castillo wrote: >> There was a much better solution: >> >> - And a W3C compromise: First video codec 100% royalty free would >> become MTI in WebRTC. > > We've had a 100% RF codec on the table since the very beginning. > Two if you include the later proposal of H.261 as the MTI fallback. > (three if you include theora ...) > > We apparently failed to get consensus on either of those as sole MTI. My concern is that, regardless companies' interest on certain no RF codecs, the W3C should mandate some requirements in order to adopt a MTI codec. IMHO the main requirement should be being a 100% RF codec. Unfortunately IMHO such a requirement does not exist and here we are, mandating vendors and other players to implement non RF codecs to be W3C compliant. > I think the consensus that we do have, which at least includes an RF > video codec, is better than perpetuating the chaos of no MTI. So I > also confirm my support for this as being the consensus of the group. That sounds nice, but let's be realistic: will 50% of main vendors accept this resolution? For me it is clear that they already exposed their refusal to it. So what is solved here? >> Things would be exactly as they are now, but at least we avoid a >> "MUST" that will be ignored by 50% of the market. > > I'm not sure I follow your logic here? Right now 100% of the current > implementations have not ignored this. That includes something like > 75% of the browser user market share. The rest of the market will do > whatever their market research dept. tells them their customers want > them to do. This compromise gives the best chance for people who > really are wedged through no fault of their own to be able to produce > something that still will interop with that majority of 'the market'. Well, let's imagine both IE and Safari implement WebRTC within the next 4 months and, as announced, they just support H264. What is the value of having VP8 as MTI? I mean: a company providing a WebRTC service will need to implement H264 (because at least the 25% of their use IE or Safari), so? It may happen that certain famous applications just allow VP8 so "customers" will indeed demand Microsoft and Apple to add support for VP8 in their browsers. IMHO nothing would change (and this is what I meant) if the WG would have mandated no MTI video codec. The only difference (and a good one IMHO) is that vendors and players would not be required to assume "license / patent risks" in order to conform with a W3C specification. > The only people currently claiming they are inclined to ignore this > are people who so far have shown no real indication that they are going > to do anything but ignore this standard anyway, regardless of what we > specify about anything. While the IETF does give everyone a voice to > express real technical concerns and propose solutions, I don't think > it grants a veto to people who simply want to obstruct something they > feel their business is threatened by. Whatever their "market share". > > Anyway, if you want to discuss that (again), we probably ought to move > it off the "sense of the room" thread, so as not to make the hard job > of the chairs even harder :) AFAIU the resolution is already taken, and won't change. I don't want to spend more time on this (I would prefer to invest it into ORTC adoption which is the real next step). Regards. --=20 I=C3=B1aki Baz Castillo From nobody Mon Dec 8 15:54:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47DC1A0062 for ; Mon, 8 Dec 2014 15:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GUARANTEED_100_PERCENT=2.699, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzpEZZ2rkWOP for ; Mon, 8 Dec 2014 15:53:55 -0800 (PST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB711A026A for ; Mon, 8 Dec 2014 15:53:55 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 08 Dec 2014 15:53:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,541,1413270000"; d="scan'208,217";a="634697908" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by fmsmga001.fm.intel.com with ESMTP; 08 Dec 2014 15:53:54 -0800 Received: from orsmsx115.amr.corp.intel.com (10.22.240.11) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 8 Dec 2014 15:53:54 -0800 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by ORSMSX115.amr.corp.intel.com (10.22.240.11) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 8 Dec 2014 15:53:54 -0800 Received: from fmsmsx118.amr.corp.intel.com ([169.254.1.40]) by FMSMSX155.amr.corp.intel.com ([10.18.116.71]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 15:53:53 -0800 From: "Cavigioli, Chris" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEJCKEBti1FXXNkmH1ALOez9gJ5yBvm8AgATTdwD//69UkIAAG/Hw Date: Mon, 8 Dec 2014 23:53:53 +0000 Message-ID: References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.108] Content-Type: multipart/alternative; boundary="_000_E36D1A4AE0B6AA4091F1728D584A6AD24011C516fmsmsx118amrcor_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/beB78JEMyKPjU1EcGq8Aa6VcUDA Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 23:53:59 -0000 --_000_E36D1A4AE0B6AA4091F1728D584A6AD24011C516fmsmsx118amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Maire's sentiments. Let's *please* not re-open this endless d= iscussion. It is tedious and tiring. We achieved a consensus decision, = and it doesn't have to be unanimous. Let's declare victory for WebRTC and = move on. Here are 3 things that will never be decided 100% unanimously. Some things= just cannot be. 1. Electing a president to lead a nation 2. Deciding on codecs in a standards body 3. Solving the Israel - Palestine conflict I propose we work together as global citizens, move forward, get things don= e, ... -chris P.S. I think we have all realized that there is no such thing as a 100% gu= aranteed RF codec, especially one that is performant. Even ones that are = declared as RF can always be argued in court... -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Andrew Allen Sent: Monday, December 08, 2014 3:29 PM To: Maire Reavy; rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec We are not re-opening this discussion. This list discussion is the decision= making process. What took place in Honolulu was only a consensus hum of those present in th= e room. In IETF all decisions are made on the list and it was clearly stated by the= chair in Honolulu that the decision would need to be endorsed on the list. On 1) We have committed to an MTI video codec I note the small word "an". If we decide on two MTI video codecs then we have clearly failed to meet th= is commitment. On 3) This is the only proposal that gets support from both camps As David pointed out we are not in two monolithic camps (this isn't the col= d war here). Different companies and different individuals have different p= ositions for different reasons. The fact that some people who might have be= en perceived as being in "one camp" have found a way to agree to a "comprom= ise" based upon a definition that doesn't force them in their product to im= plement what they don't agree to implement does not mean that the fundament= al reason behind the difficulty in reaching consensus on MTI video codecs b= y those whose products would be forced to implement both codecs has changed= . It's very easy to agree to someone else to have to do something that you ar= e not willing to do yourself. Andrew -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Maire Reavy Sent: Monday, December 08, 2014 4:41 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec On 12/5/2014 2:58 PM, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Considering that: > 1) We have committed to an MTI video codec > 2) All consensus calls on "VP8 only" and "H.264 only" have failed > 3) This is the only proposal that gets support from both camps I > strongly support this MTI proposal. > Please, let's close this debate once and for all. This compromise is > by no means great, but it's much better than anything else we're going > to get otherwise (i.e. more wasted time and still no MTI). A big +1 We have spent *so* many hours already considering, discussing, & debating w= hat to do about the MTI video codec. One could argue an "insane amount" of= time relative to the other issues we need to resolve. We did this because= most of us realized that "no MTI" could be horrific for the standard. We = should embrace consensus around anything less than horrific, and most of us= agree that this compromise is less than horrific (not great, but less than= horrific). Right now I fear we're on the verge of shooting ourselves in the foot or he= ad (I'm not sure which) by reopening this discussion even though we're in s= ight of the end. I ask that the working group and the chairs put the prove= rbially safety back on the gun, declare consensus on this less-than-horrifi= c proposal, and finish our work on "v1.0" of the spec. Please. -Maire ------------------------- Maire Reavy mdr@reavy.org _______________________________________________ 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 --_000_E36D1A4AE0B6AA4091F1728D584A6AD24011C516fmsmsx118amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Maire’s sentiments.  Let'= s *please* not re-open this endless discussion.   It is tedious a= nd tiring.   We achieved a consensus decision, and it doesn’= ;t have to be unanimous.  Let’s declare victory for WebRTC and m= ove on.

Here are 3 things that will never be decided 100%= unanimously.  Some things just cannot be. 

1.       Electing a president to lead a nation

2.       Deciding on codecs in a standards body

3.       Solving the Israel - Palestine conflict<= /p>

I propose we work together as global citizens, mo= ve forward, get things done, ...

-chris

 

P.S.  I think we have all realized that ther= e is no such thing as a 100% guaranteed RF codec, especially one that is pe= rformant.   Even ones that are declared as RF can always be argue= d in court…

 

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Andrew Allen
Sent: Monday, December 08, 2014 3:29 PM
To: Maire Reavy; rtcweb@ietf.org
Subject: Re: [rtcweb] confirming sense of the room: mti codec

 

We are not re-opening this discussion. This list = discussion is the decision making process.

 

What took place in Honolulu was only a consensus = hum of those present in the room.

 

In IETF all decisions are made on the list and it= was clearly stated by the chair in Honolulu that the decision would need t= o be endorsed on the list.

 

On 1) We have committed to an MTI video codec

 

I note the small word "an".<= /p>

 

If we decide on two MTI video codecs then we have= clearly failed to meet this commitment.

 

On 3) This is the only proposal that gets support= from both camps

 

As David pointed out we are not in two monolithic= camps (this isn't the cold war here). Different companies and different in= dividuals have different positions for different reasons. The fact that som= e people who might have been perceived as being in "one camp" have found a way to agree to a "comp= romise" based upon a definition that doesn't force them in their produ= ct to implement what they don't agree to implement does not mean that the f= undamental reason behind the difficulty in reaching consensus on MTI video codecs by those whose products would be forced to i= mplement both codecs has changed.

 

It's very easy to agree to someone else to have t= o do something that you are not willing to do yourself.

 

Andrew

 

-----Original Message-----

From: rtcweb [mailto:rtcweb= -bounces@ietf.org] On Behalf Of Maire Reavy

Sent: Monday, December 08, 2014 4:41 PM

To: rtcweb@ietf.org=

Subject: Re: [rtcweb] confirming sense of the roo= m: mti codec

 

On 12/5/2014 2:58 PM, Jean-Marc Valin wrote:=

> -----BEGIN PGP SIGNED MESSAGE-----

> Hash: SHA1

> 

> Considering that:

> 1) We have committed to an MTI video codec

> 2) All consensus calls on "VP8 only&quo= t; and "H.264 only" have failed

> 3) This is the only proposal that gets suppo= rt from both camps I

> strongly support this MTI proposal.

> Please, let's close this debate once and for= all. This compromise is

> by no means great, but it's much better than= anything else we're going

> to get otherwise (i.e. more wasted time and = still no MTI).

A big +1

 

We have spent *so* many hours already considering= , discussing, & debating what to do about the MTI video codec.  On= e could argue an "insane amount" of time relative to the other is= sues we need to resolve.  We did this because most of us realized that "no MTI" could be horrific for the standard.&nb= sp; We should embrace consensus around anything less than horrific, and mos= t of us agree that this compromise is less than horrific (not great, but le= ss than horrific).

 

Right now I fear we're on the verge of shooting o= urselves in the foot or head (I'm not sure which) by reopening this discuss= ion even though we're in sight of the end.  I ask that the working gro= up and the chairs put the proverbially safety back on the gun, declare consensus on this less-than-horrific propo= sal, and finish our work on "v1.0" of the spec.

 

Please.

 

-Maire

-------------------------

Maire Reavy

mdr@reavy.org

 

_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.i= etf.org/mailman/listinfo/rtcweb

 

_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.i= etf.org/mailman/listinfo/rtcweb

--_000_E36D1A4AE0B6AA4091F1728D584A6AD24011C516fmsmsx118amrcor_-- From nobody Mon Dec 8 15:57:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318711A004C for ; Mon, 8 Dec 2014 15:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5rBmBvEwSg5 for ; Mon, 8 Dec 2014 15:57:33 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3684C1A0370 for ; Mon, 8 Dec 2014 15:57:26 -0800 (PST) Received: from [33.230.243.132] ([172.56.6.178]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB8NvHTV063190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2014 17:57:20 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [172.56.6.178] claimed to be [33.230.243.132] References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> X-Mailer: iPhone Mail (12B411) From: Adam Roach Date: Mon, 8 Dec 2014 17:57:13 -0600 To: Andrew Allen Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JWxw4vGb9ohxkoO1rWGAIdpSRzM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 23:57:35 -0000 > On Dec 8, 2014, at 17:28, Andrew Allen wrote: >=20 > If we decide on two MTI video codecs then we have clearly failed to meet t= his commitment. Do you have a constructive and plausible proposal? /a= From nobody Mon Dec 8 15:57:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05661A1A13 for ; Mon, 8 Dec 2014 15:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7tsONNNPIPk for ; Mon, 8 Dec 2014 15:57:52 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE921A004C for ; Mon, 8 Dec 2014 15:57:51 -0800 (PST) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 08 Dec 2014 18:57:51 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0210.002; Mon, 8 Dec 2014 18:57:50 -0500 From: Andrew Allen To: Peter Saint-Andre - &yet , "rtcweb@ietf.org" Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEJCKEBti1FXXNkmH1ALOez9gJ5yGNFiAgAAoiQD//6yQEIAAWRUA////TjA= Date: Mon, 8 Dec 2014 23:57:49 +0000 Message-ID: References: <5485CC5B.2030104@alvestrand.no> <5485F318.2090707@andyet.net> In-Reply-To: <5485F318.2090707@andyet.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9CRnSxWrp62YtONu09FZAUW05nM Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 08 Dec 2014 23:57:55 -0000 We didn't define two audio MTI codecs for interoperability between RTCweb c= ompatible devices.=20 We defined OPUS as MTI for interoperability between RTCweb compatible devic= es and G.711 for interoperability with just about everything else out there= (i.e with Legacy). Much to the consternation of some of my colleagues in t= he mobile industry I have been proactive in the audio codec discussion on r= esisting IETF defining any additional audio MTI codecs to these two. Selecting H.264 as the single MTI for video would have fulfilled both the R= TCweb interoperability and the legacy interoperability . It also should be noted that G.711 is trivial to implement and does not hav= e IPR concerns (G.711 is in that respect the equivalent of H.261 in the aud= io codec world). Andrew -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Peter Saint-Andr= e - &yet Sent: Monday, December 08, 2014 1:51 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec On 12/8/14, 11:34 AM, Andrew Allen wrote: > I think it's pretty clear from my statements in the IETF session on=20 > this topic and on this list that I don't support having two MTI video=20 > codecs for any WebRTC entity and I don't think it is technically=20 > justified. But I state this here formally. To those (not just Andrew) who are opposed to two MTI video codecs: were yo= u also opposed to two MTI audio codecs? I'm trying to understand the differ= ences between audio and video here... Peter _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Dec 8 16:21:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC841A028A for ; Mon, 8 Dec 2014 16:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eMAM4ey-bij for ; Mon, 8 Dec 2014 16:21:16 -0800 (PST) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB781A0079 for ; Mon, 8 Dec 2014 16:21:16 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id id10so2693179vcb.19 for ; Mon, 08 Dec 2014 16:21:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=e8Djgr1kKS6INWF3VOWFBS6kWcuO8X+/Gans8OnKLkM=; b=WdLq5mNf1wBXLKexfHYw/QX0yEEc38f+vxZAWNTQ7Ozpjj4r4w+CAUwExogJgmzSrz r0E8Q33kbW4N/m0RW1uynPCwv2qFKe0Nt5CxFObrwHTKTmK355UfdkKJi4WRflUU+Lyy f3YU7fOtggPPIleNMpa3Crmy5C+xxyzxViNLaF7oMrnojR/7GEgc4HyXg1scGu4Nqc+r cZsh8ojQGOI5Eps1fCv18Pj9fVx9F7RVqUFGgaShuJsqp8bTKyDgicjNi5zKQsPC8kbN 2o4k6kje7PdI4neLnO2aZoAKZOSovcZseCIshIjO58zIZZuaV87poFop0IQnbeTRL8I2 lGMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=e8Djgr1kKS6INWF3VOWFBS6kWcuO8X+/Gans8OnKLkM=; b=hVFOuImz54MWIVfXyO7GSn0gxKpJ/nKaz0Cg4ZbDEUZogpcwAobWS1E9ylSSqwvqGm uEWqvXmdyLIf/4W1heAfmXe3jfOFBt/aIJfx0lI2U17ocucLIxMjg5QGIJ230ibjjV5U iBV+3TBVcMq81W4efwDDsct4ZjBK4RR2NrCBb3OvlWCPRUsXkWqye3t8NTEaaERiJy3N tu7ONBQfTS/f7Fuy99glWh4dRx7gRPvpRlZxs6nrpM2ZxaWBaykyewozF+10UdQW8Q6v oeMFmPZWRctQBN3L58Ry5JrFPEQJnL18kPLluc1QYmqK/6YEj/JE1jXDyx3nhK2/I9c3 mXxw== X-Gm-Message-State: ALoCoQlNDrqafDZyBAHdxTIkszahLIiGYgONNZdnXUZHzmIYf8eZu2EPo/Y5MnbxbeqsLKJGnHzB X-Received: by 10.52.27.237 with SMTP id w13mr65499vdg.68.1418084475528; Mon, 08 Dec 2014 16:21:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.237.130 with HTTP; Mon, 8 Dec 2014 16:20:55 -0800 (PST) In-Reply-To: References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> From: Justin Uberti Date: Mon, 8 Dec 2014 16:20:55 -0800 Message-ID: To: Andrew Allen Content-Type: multipart/alternative; boundary=20cf307abed56d06840509bd85dc Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/H0w6O5QeOWPYPDNsS5wiemmtVT0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 00:21:18 -0000 --20cf307abed56d06840509bd85dc Content-Type: text/plain; charset=UTF-8 On Mon, Dec 8, 2014 at 3:28 PM, Andrew Allen wrote: > We are not re-opening this discussion. This list discussion is the > decision making process. > > What took place in Honolulu was only a consensus hum of those present in > the room. > > In IETF all decisions are made on the list and it was clearly stated by > the chair in Honolulu that the decision would need to be endorsed on the > list. > > On 1) We have committed to an MTI video codec > > I note the small word "an". > If we decide on two MTI video codecs then we have clearly failed to meet > this commitment. > Goodness. If you're going to descend to this level of pedantry, at least look at the charter: *"6. Define a set of media formats that must or should be supported by a client to improve interoperability."* Clearly this compromise is entirely satisfactory in this regard. > > On 3) This is the only proposal that gets support from both camps > > As David pointed out we are not in two monolithic camps (this isn't the > cold war here). Different companies and different individuals have > different positions for different reasons. The fact that some people who > might have been perceived as being in "one camp" have found a way to agree > to a "compromise" based upon a definition that doesn't force them in their > product to implement what they don't agree to implement does not mean that > the fundamental reason behind the difficulty in reaching consensus on MTI > video codecs by those whose products would be forced to implement both > codecs has changed. > > It's very easy to agree to someone else to have to do something that you > are not willing to do yourself. > > Andrew > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Maire Reavy > Sent: Monday, December 08, 2014 4:41 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] confirming sense of the room: mti codec > > On 12/5/2014 2:58 PM, Jean-Marc Valin wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Considering that: > > 1) We have committed to an MTI video codec > > 2) All consensus calls on "VP8 only" and "H.264 only" have failed > > 3) This is the only proposal that gets support from both camps I > > strongly support this MTI proposal. > > Please, let's close this debate once and for all. This compromise is > > by no means great, but it's much better than anything else we're going > > to get otherwise (i.e. more wasted time and still no MTI). > A big +1 > > We have spent *so* many hours already considering, discussing, & debating > what to do about the MTI video codec. One could argue an "insane amount" > of time relative to the other issues we need to resolve. We did this > because most of us realized that "no MTI" could be horrific for the > standard. We should embrace consensus around anything less than horrific, > and most of us agree that this compromise is less than horrific (not great, > but less than horrific). > > Right now I fear we're on the verge of shooting ourselves in the foot or > head (I'm not sure which) by reopening this discussion even though we're in > sight of the end. I ask that the working group and the chairs put the > proverbially safety back on the gun, declare consensus on this > less-than-horrific proposal, and finish our work on "v1.0" of the spec. > > Please. > > -Maire > ------------------------- > Maire Reavy > mdr@reavy.org > > _______________________________________________ > 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 > --20cf307abed56d06840509bd85dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 8, 2014 at 3:28 PM, Andrew Allen <aallen@blackberry.co= m> wrote:
We are not re-opening this disc= ussion. This list discussion is the decision making process.

What took place in Honolulu was only a consensus hum of those present in th= e room.

In IETF all decisions are made on the list and it was clearly stated by the= chair in Honolulu that the decision would need to be endorsed on the list.=

On 1) We have committed to an MTI video codec

I note the small word "an".=C2=A0

If we decide on two MTI video codecs then we have clearly failed to meet th= is commitment.

Goodness. If you're = going to descend to this level of pedantry, at least look at the charter:

"6. Define a set of media formats that must= or should be supported by a client to improve interoperability."<= br>

Clearly this compromise is entirely satisfacto= ry in this regard.

On 3) This is the only proposal that gets support from both camps

As David pointed out we are not in two monolithic camps (this isn't the= cold war here). Different companies and different individuals have differe= nt positions for different reasons. The fact that some people who might hav= e been perceived as being in "one camp" have found a way to agree= to a "compromise" based upon a definition that doesn't force= them in their product to implement what they don't agree to implement = does not mean that the fundamental reason behind the difficulty in reaching= consensus on MTI video codecs by those whose products would be forced to i= mplement both codecs has changed.

It's very easy to agree to someone else to have to do something that yo= u are not willing to do yourself.

Andrew

-----Original Message-----
From: rtcweb [mailto:rtcweb-boun= ces@ietf.org] On Behalf Of Maire Reavy
Sent: Monday, December 08, 2014 4:41 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] confirming sense of the room: mti codec

On 12/5/2014 2:58 PM, Jean-Marc Va= lin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Considering that:
> 1) We have committed to an MTI video codec
> 2) All consensus calls on "VP8 only" and "H.264 only&qu= ot; have failed
> 3) This is the only proposal that gets support from both camps I
> strongly support this MTI proposal.
> Please, let's close this debate once and for all. This compromise = is
> by no means great, but it's much better than anything else we'= re going
> to get otherwise (i.e. more wasted time and still no MTI).
A big +1

We have spent *so* many hours already considering, discussing, & debati= ng what to do about the MTI video codec.=C2=A0 One could argue an "ins= ane amount" of time relative to the other issues we need to resolve.= =C2=A0 We did this because most of us realized that "no MTI" coul= d be horrific for the standard.=C2=A0 We should embrace consensus around an= ything less than horrific, and most of us agree that this compromise is les= s than horrific (not great, but less than horrific).

Right now I fear we're on the verge of shooting ourselves in the foot o= r head (I'm not sure which) by reopening this discussion even though we= 're in sight of the end.=C2=A0 I ask that the working group and the cha= irs put the proverbially safety back on the gun, declare consensus on this = less-than-horrific proposal, and finish our work on "v1.0" of the= spec.

Please.

-Maire
-------------------------
Maire Reavy
mdr@reavy.org

_______________________________________________
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

--20cf307abed56d06840509bd85dc-- From nobody Mon Dec 8 16:45:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0581A1A87 for ; Mon, 8 Dec 2014 16:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hy6E4wQ-xtla for ; Mon, 8 Dec 2014 16:45:36 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 14FA31A1A7E for ; Mon, 8 Dec 2014 16:45:35 -0800 (PST) Received: from smtp-pop.rim.net (HELO XCT103CNC.rim.net) ([10.65.161.203]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 08 Dec 2014 19:45:04 -0500 Received: from XCT114CNC.rim.net (10.65.161.214) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.3.210.2; Mon, 8 Dec 2014 19:45:04 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT114CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Mon, 8 Dec 2014 19:45:03 -0500 From: Andrew Allen To: Adam Roach Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEJCKEBti1FXXNkmH1ALOez9gJ5yBvm8AgATTdwD//69UkIAAdtWA//+sviA= Date: Tue, 9 Dec 2014 00:45:03 +0000 Message-ID: References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> In-Reply-To: <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/G6pMcZoDsmazkuA4A2ywqmxGtWA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 00:45:38 -0000 Adam Our preference is for H.264 to be the single MTI. We believe that Cisco's o= pen source royalty free code offer goes a long long way to address the conc= erns of many related to IPR on H.264 and the prevalence now of APIs to acce= ss embedded codecs (such as H.264) on mobile devices goes even further to a= ddress those concerns. See http://www.ietf.org/id/draft-burman-rtcweb-h264-= proposal-05.txt We also have proposed as a compromise having 2 MTI decoders but only have t= o implement one encoder. I know the above doesn't make everyone happy either.=20 But this current proposed "compromise" whilst succeeding in garnering a sig= nificant hum in the room is opposed by some rather significant vendors in t= he browser space. So whilst it may make the RTCWEB Video RFC look pretty an= d complete it is unlikely to ensure interoperability in the market any more= than simply leaving it to the market to decide (which is what will happen = if we fail to agree on a single MTI video codec). Having a standard that i= s not fully implemented by some of the primary participants in the market d= oes not bode well for the success of the standard even more than not agree= ing on a single MTI codec IMHO. CLUE has agreed not to define MTI codecs bu= t does this mean that telepresence interoperability will be a failure - I t= hink not. BetaMax vs VHS and Blu Ray vs HD DVD have shown that ultimately the market = will resolve these entrenched interoperability issues which are based on bu= siness reasons not technical merit without everyone having to agree in a st= andards body to support both or to support only one. Andrew -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Monday, December 08, 2014 6:57 PM To: Andrew Allen Cc: Maire Reavy; rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec > On Dec 8, 2014, at 17:28, Andrew Allen wrote: >=20 > If we decide on two MTI video codecs then we have clearly failed to meet = this commitment. Do you have a constructive and plausible proposal? /a From nobody Mon Dec 8 16:53:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80EEE1A1AC8 for ; Mon, 8 Dec 2014 16:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FP3CV5d917Z for ; Mon, 8 Dec 2014 16:53:42 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DCCA1A1A87 for ; Mon, 8 Dec 2014 16:53:42 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id lj1so6281579pab.4 for ; Mon, 08 Dec 2014 16:53:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZdXL+xw9+xACVQxvnE+cVZ6opp2s6V/OUO2MC6mUa20=; b=pNrgH/NXM2Oj48+GxcH3csB4jN59+7W09IOE9bg7+A3E7cvwlU+ocSApXQS8qYXGD5 YJu/qlk66y3fbx2Ofe0349LGRc3xKX6ozIPwBpkQp+PMJeIbZOlqdBy6NcwQ9Kiha9SD NbVfqfAi2EPgpEGe+1KyjSlASyEPGP0rA6jxDT2kGWjpNmF/UF3gYGbyeEGMIipSZrzd UZhO3rsA0Ti2qUB8Zve7VizyBXV5WtI/E9lL01GWRDdFYA3x50/kjW5LEw+scbRyStxX tWOtBdukV+54TPDeJeaT3wrRkp5O8yOsR248qIash1pm2Rlkm0TSRshcuM4hSQwLKTyx s4/g== MIME-Version: 1.0 X-Received: by 10.66.235.74 with SMTP id uk10mr531388pac.16.1418086421693; Mon, 08 Dec 2014 16:53:41 -0800 (PST) Received: by 10.70.60.201 with HTTP; Mon, 8 Dec 2014 16:53:41 -0800 (PST) In-Reply-To: References: <5485CC5B.2030104@alvestrand.no> Date: Tue, 9 Dec 2014 06:23:41 +0530 Message-ID: From: Suhas Nandakumar To: Eric Rescorla Content-Type: multipart/alternative; boundary=047d7b15a4bd6d0ac00509bdf95e Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/idlKqqtRSK37Cf57I8ZAiQxKToA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 00:53:45 -0000 --047d7b15a4bd6d0ac00509bdf95e Content-Type: text/plain; charset=UTF-8 +1 for the rough consensus as presented by the chair and totally in favor of the novel solution in the spirit of moving RTCweb forward. Keeping end user's experience in mind and making RTCWeb an interoperable platform the consensus reached in Hawaii is a worthy compromise to proceed further. Cheers Suhas On Tue, Dec 9, 2014 at 12:35 AM, Eric Rescorla wrote: > Just to reiterate what I said in the room, I agree with this. > > -Ekr > > > On Mon, Dec 8, 2014 at 6:39 PM, Justin Uberti wrote: > >> I support the rough consensus as presented by the chair. >> >> As stated before - I think this plan represents a legitimate compromise >> in what had previously seemed like a stalemate. While not my ideal outcome, >> I think this is good for the WebRTC ecosystem - it ensures >> interoperability, and provides a reasonably clear path for reaching a >> completely RF solution. >> >> On Mon, Dec 8, 2014 at 9:27 AM, Martin Thomson >> wrote: >> >>> On 8 December 2014 at 08:05, Harald Alvestrand >>> wrote: >>> > Since others who were present in the room are repeating their position >>> > on the list, I'll do so too. >>> >>> That's probably a good thing to do. An almost anonymous humming sound >>> isn't a good basis for establishing a record. >>> >>> > I support the rough consensus as presented by the chair. >>> >>> +1 >>> >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b15a4bd6d0ac00509bdf95e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 f= or the rough consensus as presented by the chair and totally in favor of th= e novel solution in the spirit of moving RTCweb forward.=C2=A0
=
Keeping end user'= s experience in mind and making RTCWeb an interoperable platform =C2=A0the = consensus reached in Hawaii is a worthy compromise to proceed further.

Cheers
Suhas
<= div style=3D"font-size:13px">


On Tue, Dec 9, 2014 at 12:35 AM, = Eric Rescorla <ekr@rtfm.com> wrote:
Just to reiterate what I said in the room, I agree w= ith this.

-Ekr


On Mon, Dec 8, 2014 at 6:39 PM, Justin Uberti <= ;juberti@google.com= > wrote:
<= span>I support the rough conse= nsus as presented by the chair.=C2=A0

As stated before -=C2=A0I think this plan represents a legitimate compromise in = what had previously seemed like a stalemate. While not my ideal outcome, I = think this is good for the WebRTC ecosystem - it ensures interoperability, = and provides a reasonably clear path for reaching a completely RF solution.=

On Mon, Dec 8, 2014 at 9:27 AM, Martin Thomson <martin.= thomson@gmail.com> wrote:
<= span>On 8 December 2014 at 08:05, Harald Alvestrand <harald@alvestrand.no> wrote:<= br> > Since others who were present in the room are repeating their position=
> on the list, I'll do so too.

That's probably a good thing to do.=C2=A0 An almost anonymous hu= mming sound
isn't a good basis for establishing a record.

> I support the rough consensus as presented by the chair.

+1

_______________________________________________
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



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--047d7b15a4bd6d0ac00509bdf95e-- From nobody Mon Dec 8 17:19:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40C11A6FF6 for ; Mon, 8 Dec 2014 17:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7MDmTDeDV1Q for ; Mon, 8 Dec 2014 17:19:25 -0800 (PST) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB92E1A885B for ; Mon, 8 Dec 2014 17:19:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418087965; x=2282001565; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2Orx7NhbdOjm8MF/ZMc77jE6O1BrrQrFsBJ/7Br0OuE=; b=l8tOIVFGNIAqOi5/aRDeKxWe7dGU2EW0CkjLyaAc7bPKIY14YET/w+CN07V49b8o kD+3weMH30nXv4VU3XI8SXvv5J+GV/cinIZtRH54CHbbT6laZTvKAoJLThwnCvp/ eGm1FpqNwvernYFEEpu9azA9iK3QMqdn4DtY4V6aBHXvtO5iYzNjPRh0e3hhroL9 MIvJA9r21vErnKveXB7pdV3Khhinqk7LWmpYBaBVP0XHgez+C56bmpv+L9k9hgIF X610qm4bqPA53XI3i3GRAXm1HlUB9upOBgrhuLxWHdtkmXv036AK5xUVRn/QnCLI l4+lKR4uxe4KEWil9RhBLg==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 5D.BD.26546.D1E46845; Mon, 8 Dec 2014 17:19:25 -0800 (PST) X-AuditID: 11973e11-f79af6d0000067b2-3c-54864e1de357 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 9F.5E.05998.E2E46845; Mon, 8 Dec 2014 17:19:42 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGA001FNJOCMS60@marigold.apple.com> for rtcweb@ietf.org; Mon, 08 Dec 2014 17:19:25 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: Date: Mon, 08 Dec 2014 17:19:24 -0800 Content-transfer-encoding: quoted-printable Message-id: <21E818AE-0F44-4BA1-AA59-8322C982446E@apple.com> References: <54820E74.90201@mozilla.com> <5485E627.5050706@jesup.org> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FAYrivr1xZiMGWhpMXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOLL0NVvBZZGK/kk/2BoYNwt0MXJwSAiYSDTfie1i5AQyxSQu 3FvP1sXIxSEksJdR4s6iRjaIhInEp8//mCESk5gk9q75zQLhzGeS2Dh3MTvIJGYBdYkpU3JB GngF9CSanjxmAgkLC9hKbL0eBBJmE1CVeDDnGCOIzSkQLHGoYRkLiM0CFJ//6z0ziM0soC3x 5N0FVogxNhLvn1yDWrWPUaJ1xz6wIhGgVZcfXmCHOE5W4t/FM+wgRRICD1klpi7bzzKBUWgW wkmzkJw0C8mOBYzMqxiFchMzc3Qz84z0EgsKclL1kvNzNzGCgnW6neAOxuOrrA4xCnAwKvHw ali2hQixJpYVV+YeYpTmYFES571hAxQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAKHF+65Jc 1RvKSSmpVd5b3RTuTe05dHQyq/CymynnT8r/eaHwPJWbpylIpkr50sR9obtfOzT+93YrCr4j nyxzZ5v9imkNF5b+6I2f25bxILsqWCexkldJUilabEHj8g696DmV/Bov8yaeeCKaKGbiy+Oq c6ogvZ3zc6XphpRvMy5e61g1y2GvEktxRqKhFnNRcSIAr5RNVTcCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUi2FDcoqvn1xZicO2JhsXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOLL0NVvBZZGK/kk/2BoYNwt0MXJySAiYSHz6/I8ZwhaTuHBv PVsXIxeHkMAkJom9a36zQDjzmSQ2zl3M3sXIwcEsoC4xZUouSAOvgJ5E05PHTCBhYQFbia3X g0DCbAKqEg/mHGMEsTkFgiUONSxjAbFZgOLzf70H28UsoC3x5N0FVogxNhLvn1yDWrWPUaJ1 xz6wIhGgVZcfXmCHOE5W4t/FM+wTGPlnIVwxC8kVs5CMXcDIvIpRoCg1J7HSRC+xoCAnVS85 P3cTIzi8CsN3MP5bZnWIUYCDUYmHV8OyLUSINbGsuDL3EKMEB7OSCO/yna0hQrwpiZVVqUX5 8UWlOanFhxilOViUxHmb3zWGCAmkJ5akZqemFqQWwWSZODilGhh3sUie2T/3X3a2t6rdO4vC uwZuLqzBi5Ybn+3WFpX6/+ijgiTrxNoKLl0dphp9/WtLKzvCkowqv6m9LW3+E2HaIqy7v8rG R/PMjk9vXot/KUwL7inYck5kLUu9elD74avFbxf/zzR9viko7f7h+wcOyzr6eaY8UF32Mvbx 9pwvnmLVEQkHfZRYijMSDbWYi4oTAe+PnGwrAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/23F1rnu3_QREq3eLaZ9kCWrX6pI Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 01:19:28 -0000 > On Dec 8, 2014, at 10:00 , I=C3=B1aki Baz Castillo = wrote: >=20 > 2014-12-08 18:55 GMT+01:00 Randell Jesup : >> +1 - it's by no means my preferred solution, but it's one I can live = with, >> and better than the alternative of the status-quo - no MTI at all. = If it >> wasn't for OpenH264, my answer would be different. >>=20 >> I can't see adopting H.264 as sole MTI, and I can't see that we'd get >> consensus to adopt VP8 as sole MTI. >=20 > There was a much better solution: >=20 > - Don't make VP8 nor H264 MTI. > - So for now no MTI video codec. > - And a W3C compromise: First video codec 100% royalty free would > become MTI in WebRTC. >=20 > Things would be exactly as they are now, but at least we avoid a > "MUST" that will be ignored by 50% of the market. That would be more honest, indeed. It is effectively where we are going = to be. And it offers a carrot in the right direction. I am curious to know how many of the people supporting the proposed = position actually would implement both encode and decode of both codecs? = This follows from comments on this thread that people who feel they = fall into a different category are asking others to solve their problem. So, rather than +1, please say =E2=80=9CI would expect to implement = both=E2=80=9D (non-binding, of course) =E2=80=94 it would be a more = useful thing to see, I think. Another possible choice: * admit that we already have possible non-interoperability = (WebRTC-compatible Endpoints that choose differently), and that anyone = who doesn=E2=80=99t want to do both will say that this what they are = making (as was suggested): simply delete the requirement or definitions = for WebRTC User-agent and Device. Nothing stops those that want to from = implementing both, without or without the mandate. I don=E2=80=99t = think this would make any material difference to what happens, but it = makes the spec and reality a little closer. Finally, I wonder, what would it be like if we actually tried to get = closer to interop: ALL endpoints =E2=80=94 anything that can operate at = one end of a WebRTC session, be it device, UA, gateway, = compatible-endpoint, whatever =E2=80=94 must be able to decode = (actually, offer to receive) both, and must be able to encode at least = one? I=E2=80=99d have to think about the consequences of doing = decode-only, but it=E2=80=99s a loss less work than a decent encoder, = for a start. This would result in interop if people actually did it. David Singer Manager, Software Standards, Apple Inc. From nobody Mon Dec 8 18:41:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F081A010C for ; Mon, 8 Dec 2014 18:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiCNLA2l8DA1 for ; Mon, 8 Dec 2014 18:41:43 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DB01A00AA for ; Mon, 8 Dec 2014 18:41:42 -0800 (PST) Received: by mail-oi0-f47.google.com with SMTP id v63so4325102oia.6 for ; Mon, 08 Dec 2014 18:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=woy4NP9Ue83A0cCQ4jChxhUIDIU27n4Ecxks7o/FUJU=; b=zflFQ19kvHOptBqlo50xfdJCTyUFVb9ezo+IezrxhuUivDB15F2LfDek/vwfGpyX8V et0u/tk2+4g+qP6f+AxBnlq0q7JQdIlVwGn8pE6xtFPfMCy7rg5lj7k8ol1msVBOjyGz 4tO7x9+lBxPho226xJ2SMVihQHsOzY1leOg/5ucPycozsQj0rS+lATWrTEA3ZNAgkfZ6 nPLmvPFf/tBjBu9to4D370UVLJICdGLjneGh857rJ8zoFNQaJPNMH7IzCZTrowTHdAUV rh+yez7vOB23hy/hYkaa7Znjkp1MEyN4XY3zTtfVn6zS+YusbF1QgNLbZt8VmmXJ9MwN Vgpg== MIME-Version: 1.0 X-Received: by 10.182.87.37 with SMTP id u5mr391347obz.38.1418092902158; Mon, 08 Dec 2014 18:41:42 -0800 (PST) Received: by 10.202.85.133 with HTTP; Mon, 8 Dec 2014 18:41:41 -0800 (PST) In-Reply-To: <21E818AE-0F44-4BA1-AA59-8322C982446E@apple.com> References: <54820E74.90201@mozilla.com> <5485E627.5050706@jesup.org> <21E818AE-0F44-4BA1-AA59-8322C982446E@apple.com> Date: Tue, 9 Dec 2014 10:41:41 +0800 Message-ID: From: Alexandre GOUAILLARD To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e013c7210b118580509bf7b2b Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bdNGR0KWv-2oTxgSjRiS_Dxnp64 Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 02:41:46 -0000 --089e013c7210b118580509bf7b2b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support the rough consensus as presented by the chair. On Tue, Dec 9, 2014 at 9:19 AM, David Singer wrote: > > > On Dec 8, 2014, at 10:00 , I=C3=B1aki Baz Castillo wrot= e: > > > > 2014-12-08 18:55 GMT+01:00 Randell Jesup : > >> +1 - it's by no means my preferred solution, but it's one I can live > with, > >> and better than the alternative of the status-quo - no MTI at all. If > it > >> wasn't for OpenH264, my answer would be different. > >> > >> I can't see adopting H.264 as sole MTI, and I can't see that we'd get > >> consensus to adopt VP8 as sole MTI. > > > > There was a much better solution: > > > > - Don't make VP8 nor H264 MTI. > > - So for now no MTI video codec. > > - And a W3C compromise: First video codec 100% royalty free would > > become MTI in WebRTC. > > > > Things would be exactly as they are now, but at least we avoid a > > "MUST" that will be ignored by 50% of the market. > > That would be more honest, indeed. It is effectively where we are going t= o > be. And it offers a carrot in the right direction. > > I am curious to know how many of the people supporting the proposed > position actually would implement both encode and decode of both codecs? > This follows from comments on this thread that people who feel they fall > into a different category are asking others to solve their problem. > > So, rather than +1, please say =E2=80=9CI would expect to implement both= =E2=80=9D > (non-binding, of course) =E2=80=94 it would be a more useful thing to see= , I think. > > > > Another possible choice: > > * admit that we already have possible non-interoperability > (WebRTC-compatible Endpoints that choose differently), and that anyone wh= o > doesn=E2=80=99t want to do both will say that this what they are making (= as was > suggested): simply delete the requirement or definitions for WebRTC > User-agent and Device. Nothing stops those that want to from implementing > both, without or without the mandate. I don=E2=80=99t think this would m= ake any > material difference to what happens, but it makes the spec and reality a > little closer. > > > > Finally, I wonder, what would it be like if we actually tried to get > closer to interop: ALL endpoints =E2=80=94 anything that can operate at o= ne end of > a WebRTC session, be it device, UA, gateway, compatible-endpoint, whateve= r > =E2=80=94 must be able to decode (actually, offer to receive) both, and m= ust be > able to encode at least one? I=E2=80=99d have to think about the consequ= ences of > doing decode-only, but it=E2=80=99s a loss less work than a decent encode= r, for a > start. This would result in interop if people actually did it. > > > David Singer > Manager, Software Standards, Apple Inc. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --=20 Alex. Gouaillard, PhD, PhD, MBA ---------------------------------------------------------------------------= --------- CTO - Temasys Communications, S'pore / Mountain View President - CoSMo Software, Cambridge, MA ---------------------------------------------------------------------------= --------- sg.linkedin.com/agouaillard - --089e013c7210b118580509bf7b2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the rough consens= us as presented by the chair.
On Tue, Dec 9, 2014 at 9:19 AM, David Singer <= span dir=3D"ltr"><= singer@apple.com> wrote:

> On Dec 8, 2014, at 10:00 , I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
>
> 2014-12-08 18:55 GMT+01:00 Randell Jesup <randell-ietf@jesup.org>:
>> +1 - it's by no means my preferred solution, but it's one = I can live with,
>> and better than the alternative of the status-quo - no MTI at all.= =C2=A0 If it
>> wasn't for OpenH264, my answer would be different.
>>
>> I can't see adopting H.264 as sole MTI, and I can't see th= at we'd get
>> consensus to adopt VP8 as sole MTI.
>
> There was a much better solution:
>
> - Don't make VP8 nor H264 MTI.
> - So for now no MTI video codec.
> - And a W3C compromise: First video codec 100% royalty free would
> become MTI in WebRTC.
>
> Things would be exactly as they are now, but at least we avoid a
> "MUST" that will be ignored by 50% of the market.

That would be more honest, indeed. It is effectively where we are go= ing to be.=C2=A0 And it offers a carrot in the right direction.

I am curious to know how many of the people supporting the proposed positio= n actually would implement both encode and decode of both codecs?=C2=A0 Thi= s follows from comments on this thread that people who feel they fall into = a different category are asking others to solve their problem.

So, rather than +1, please say =E2=80=9CI would expect to implement both=E2= =80=9D (non-binding, of course) =E2=80=94 it would be a more useful thing t= o see, I think.



Another possible choice:

* admit that we already have possible non-interoperability (WebRTC-compatib= le Endpoints that choose differently), and that anyone who doesn=E2=80=99t = want to do both will say that this what they are making (as was suggested):= =C2=A0 simply delete the requirement or definitions for WebRTC User-agent a= nd Device. Nothing stops those that want to from implementing both, without= or without the mandate.=C2=A0 I don=E2=80=99t think this would make any ma= terial difference to what happens, but it makes the spec and reality a litt= le closer.



Finally, I wonder, what would it be like if we actually tried to get closer= to interop: ALL endpoints =E2=80=94 anything that can operate at one end o= f a WebRTC session, be it device, UA, gateway, compatible-endpoint, whateve= r =E2=80=94 must be able to decode (actually, offer to receive) both, and m= ust be able to encode at least one?=C2=A0 I=E2=80=99d have to think about t= he consequences of doing decode-only, but it=E2=80=99s a loss less work tha= n a decent encoder, for a start. This would result in interop if people act= ually did it.


David Singer
Manager, Software Standards, Apple Inc.

____________________________= ___________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb



--
=
Alex. Gouaillard, PhD, PhD,= MBA
------------------------------------------------------------------= ------------------
CTO - Temasys Communications, S'pore / Mou= ntain View
President - CoSMo Software, Cambridge, MA
--= ---------------------------------------------------------------------------= -------

<= /div>
--089e013c7210b118580509bf7b2b-- From nobody Mon Dec 8 19:19:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587341A00EA for ; Mon, 8 Dec 2014 19:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrKqxLZIwToS for ; Mon, 8 Dec 2014 19:19:10 -0800 (PST) Received: from relay.mailchannels.net (nov-007-i568.relay.mailchannels.net [46.232.183.122]) by ietfa.amsl.com (Postfix) with ESMTP id 816C41A0187 for ; Mon, 8 Dec 2014 19:19:07 -0800 (PST) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-204-4-183.us-west-2.compute.internal [10.204.4.183]) by relay.mailchannels.net (Postfix) with ESMTPA id 0D56F120530 for ; Tue, 9 Dec 2014 03:19:02 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.245.17.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.2); Tue, 09 Dec 2014 03:19:03 GMT X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1418095143248:745308746 X-MC-Ingress-Time: 1418095143248 Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:58136 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XyBKI-0005Iy-1B for rtcweb@ietf.org; Mon, 08 Dec 2014 21:19:02 -0600 Message-ID: <54866A1A.5050502@jesup.org> Date: Mon, 08 Dec 2014 22:18:50 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54820E74.90201@mozilla.com> <5485E627.5050706@jesup.org> <21E818AE-0F44-4BA1-AA59-8322C982446E@apple.com> In-Reply-To: <21E818AE-0F44-4BA1-AA59-8322C982446E@apple.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-AuthUser: randell@jesup.org Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IJk0Fg5relA2Ukjul3WnMvKy84c Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 03:19:14 -0000 On 12/8/2014 8:19 PM, David Singer wrote: >> On Dec 8, 2014, at 10:00 , I=C3=B1aki Baz Castillo wro= te: >> >> 2014-12-08 18:55 GMT+01:00 Randell Jesup : >>> +1 - it's by no means my preferred solution, but it's one I can live = with, >>> and better than the alternative of the status-quo - no MTI at all. I= f it >>> wasn't for OpenH264, my answer would be different. >>> >>> I can't see adopting H.264 as sole MTI, and I can't see that we'd get >>> consensus to adopt VP8 as sole MTI. >> There was a much better solution: >> >> - Don't make VP8 nor H264 MTI. >> - So for now no MTI video codec. >> - And a W3C compromise: First video codec 100% royalty free would >> become MTI in WebRTC. And engender endless further discussions about what is "100% royalty=20 free". I'll note that even MPEG-LA deciding to RF baseline H.264=20 doesn't mean it's 100% royalty-free (witness Nokia's lawsuits). You can=20 never say "100%" with royalties/patents unless something is so old every=20 possible patent has expired - and you're still not really safe on your=20 encoder even then, unless you use an old, published encoder largely=20 unchanged. I hear we haven't boiled the Indian Ocean yet.... ;-) >> Things would be exactly as they are now, but at least we avoid a >> "MUST" that will be ignored by 50% of the market. > That would be more honest, indeed. It is effectively where we are going= to be. And it offers a carrot in the right direction. > > I am curious to know how many of the people supporting the proposed pos= ition actually would implement both encode and decode of both codecs? Th= is follows from comments on this thread that people who feel they fall in= to a different category are asking others to solve their problem. > > So, rather than +1, please say =E2=80=9CI would expect to implement bot= h=E2=80=9D (non-binding, of course) =E2=80=94 it would be a more useful t= hing to see, I think. Easy for me. Mozilla has already implemented both, and have been=20 shipping them for months. > Another possible choice: > > * admit that we already have possible non-interoperability (WebRTC-comp= atible Endpoints that choose differently), and that anyone who doesn=E2=80= =99t want to do both will say that this what they are making (as was sugg= ested): simply delete the requirement or definitions for WebRTC User-age= nt and Device. Nothing stops those that want to from implementing both, w= ithout or without the mandate. I don=E2=80=99t think this would make any= material difference to what happens, but it makes the spec and reality a= little closer. > > > > Finally, I wonder, what would it be like if we actually tried to get cl= oser to interop: ALL endpoints =E2=80=94 anything that can operate at one= end of a WebRTC session, be it device, UA, gateway, compatible-endpoint,= whatever =E2=80=94 must be able to decode (actually, offer to receive) b= oth, and must be able to encode at least one? I=E2=80=99d have to think = about the consequences of doing decode-only, but it=E2=80=99s a loss less= work than a decent encoder, for a start. This would result in interop if= people actually did it. That option was floated when we did the survey. I rated it above many=20 others myself (though not as good as vp8-only). IIRC it didn't do well;=20 too many people in the A and not B or B and not A camps. --=20 Randell Jesup -- rjesup a t mozilla d o t com From nobody Mon Dec 8 19:44:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55AE1A1B7F for ; Mon, 8 Dec 2014 19:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9_ttW3oAwAo for ; Mon, 8 Dec 2014 19:44:22 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B02A1A1B5E for ; Mon, 8 Dec 2014 19:44:22 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB93iIQS081574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2014 21:44:19 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54867014.7000709@nostrum.com> Date: Mon, 08 Dec 2014 21:44:20 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Andrew Allen References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dQV7nphtDRVEgtTzIpawdLiigyE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 03:44:24 -0000 I see two proposals in your response, both of which have been explored already. One is "choice 1" from the straw poll, which garnered only 48% support, and the other is "choice 12", which received only 7%. Which is to say that these are not merely implausible, but demonstrably non-viable. So, when I asked whether you had a "constructive and plausible proposal," you could have saved us all some time by simply saying "no." /a On 12/8/14 18:45, Andrew Allen wrote: > Adam > > Our preference is for H.264 to be the single MTI. We believe that Cisco's open source royalty free code offer goes a long long way to address the concerns of many related to IPR on H.264 and the prevalence now of APIs to access embedded codecs (such as H.264) on mobile devices goes even further to address those concerns. See http://www.ietf.org/id/draft-burman-rtcweb-h264-proposal-05.txt > > We also have proposed as a compromise having 2 MTI decoders but only have to implement one encoder. > > I know the above doesn't make everyone happy either. > > But this current proposed "compromise" whilst succeeding in garnering a significant hum in the room is opposed by some rather significant vendors in the browser space. So whilst it may make the RTCWEB Video RFC look pretty and complete it is unlikely to ensure interoperability in the market any more than simply leaving it to the market to decide (which is what will happen if we fail to agree on a single MTI video codec). Having a standard that is not fully implemented by some of the primary participants in the market does not bode well for the success of the standard even more than not agreeing on a single MTI codec IMHO. CLUE has agreed not to define MTI codecs but does this mean that telepresence interoperability will be a failure - I think not. > > BetaMax vs VHS and Blu Ray vs HD DVD have shown that ultimately the market will resolve these entrenched interoperability issues which are based on business reasons not technical merit without everyone having to agree in a standards body to support both or to support only one. > > Andrew > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Monday, December 08, 2014 6:57 PM > To: Andrew Allen > Cc: Maire Reavy; rtcweb@ietf.org > Subject: Re: [rtcweb] confirming sense of the room: mti codec > > > >> On Dec 8, 2014, at 17:28, Andrew Allen wrote: >> >> If we decide on two MTI video codecs then we have clearly failed to meet this commitment. > Do you have a constructive and plausible proposal? > > /a From nobody Mon Dec 8 20:06:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9C01A1B98 for ; Mon, 8 Dec 2014 20:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjooYFdmMEnS for ; Mon, 8 Dec 2014 20:06:54 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by ietfa.amsl.com (Postfix) with ESMTP id D8F2D1A7013 for ; Mon, 8 Dec 2014 20:06:49 -0800 (PST) Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail06.adl2.internode.on.net with ESMTP; 09 Dec 2014 14:36:45 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 0616FFF8FA for ; Tue, 9 Dec 2014 14:36:44 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UtlfPcAU1sg4 for ; Tue, 9 Dec 2014 14:36:42 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 0AFA9FF819 for ; Tue, 9 Dec 2014 14:36:42 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id EA8EA80470; Tue, 9 Dec 2014 14:36:41 +1030 (ACDT) Date: Tue, 9 Dec 2014 14:36:41 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141209040641.GH19538@hex.shelbyville.oz> References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BFfGYRrtMpjstTG9R6btwBg9OqM Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 04:06:56 -0000 On Tue, Dec 09, 2014 at 12:45:03AM +0000, Andrew Allen wrote: > > Our preference is for H.264 to be the single MTI. We believe that > Cisco's open source royalty free code offer goes a long long way to > address the concerns of many related to IPR on H.264 and the > prevalence now of APIs to access embedded codecs (such as H.264) on > mobile devices goes even further to address those concerns. "Our preference is for VP8 to be the single MTI. We believe that Google's open source royalty free code offer goes a long long way to address the concerns of many related to IPR on H.264 and the prevalence now of APIs to access embedded codecs (such as VP8) on mobile devices goes even further to address those concerns." Do you see how this works? If you don't care about my concerns, why should I give the smallest rat's about yours? When your only argument to dismiss mine is a straw man, and a pretty shabbily stuffed one at that, then it's going to get torn to shreds by the cold steel facts of the matter -- because despite the mirrored expression, those two statements aren't direct equivalents in their veracity at all once you really look into them. I'd invite you to (re)read: http://www.ietf.org/mail-archive/web/rtcweb/current/msg13739.html Repeatedly. Until you begin to gather some glimmering of understanding about why it's not the IPR on H.264 that is a problem, it's the crippling *licence* conditions on it. And the farce of pretending there's a pool you can maybe try to licence it from, if they'll even talk to you, when there are numerous companies outside of it, which also demand you have separate agreements with them. It's not just Nokia. AT&T also has their own out of pool IPR on H.264. All of which the people pushing H.264-only have pretended do not exist and handwaved away every time someone asks. None of which goes away just because somebody else was kind enough to pay the first installment of the protection racket bill for you. You are right that there are more than just these two camps though. There's also a (clearly large) subset of both that cares enough about the success of this project to compromise with each other in its best interests. With enough options and workarounds to get by until we have an IETF video codec to solve it properly (and I still do think that clarifying that is important here. If we're going to do something as audacious as mandate a patent minefield like H.264 when there is an equivalent that actually meets the IETF's aspirational requirements for RF technology, we need a better reason for that than "some people with H.264 patents insisted" if it's going to survive being challenged, or ridiculed, in later review). It's kind of laughable to describe people who don't share that interest who've not participated in the implementation and interop testing, who only seem concerned about their own narrow business interest (which may well be in direct conflict to the charter of this group) as being some form of "primary participants" we ought to kowtow to. If they can't come up with a proposal that is more acceptable than the current compromise, that doesn't give them a right to veto it. It just means they are in the rough. If they weren't going to implement it anyway, then nothing changes for them. If they are, the onus is on them now to offer something workably constructive. Stamping your feet and repeating the same old, tired, thoroughly debunked, chestnuts isn't actually challenging the emerging consensus at all. This group formed precisely to avoid the sort of "VHS vs Beta" debacle that you are proposing as a solution. I'm not sure why you'd be at all surprised that the answer to that suggestion is a resounding ... Uh. No. We can't stop you from doing that yourself anyway. But we can stand together united behind this group's charter. And I suspect you know who'll win that competition if we do ... The users. From nobody Mon Dec 8 20:47:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981041A1A92 for ; Mon, 8 Dec 2014 20:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AnI8nDj2D66 for ; Mon, 8 Dec 2014 20:47:03 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3DADB1A0242 for ; Mon, 8 Dec 2014 20:47:02 -0800 (PST) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 08 Dec 2014 23:46:52 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT105CNC.rim.net ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.03.0210.002; Mon, 8 Dec 2014 23:46:51 -0500 From: Andrew Allen To: Adam Roach Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEJCKEBti1FXXNkmH1ALOez9gJ5yBvm8AgATTdwD//69UkIAAdtWA//+sviCAAJK3AP//sTDw Date: Tue, 9 Dec 2014 04:46:50 +0000 Message-ID: References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <54867014.7000709@nostrum.com> In-Reply-To: <54867014.7000709@nostrum.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_K7a76cwZaVd37aVd_Fz8E8kIQU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 04:47:05 -0000 QW5kIHRoZSAzcmQgYWx0ZXJuYXRpdmUgaXMgdGhhdCB3ZSBhZ3JlZSB0aGF0IHdlIGNhbm5vdCBh Z3JlZSBvbiBhIHNpbmdsZSBNVEkgdmlkZW8gY29kZWMgYW5kIGxldCB0aGUgbWFya2V0IGRlY2lk ZS4gSU1ITyB0aGUgc2t5IHdpbGwgbm90IGZhbGwgaWYgdGhhdCBlbmRzIHVwIGJlaW5nIHRoZSBv dXRjb21lLiBUaGVyZSBpcyB0b28gbXVjaCBpbnRlcmVzdCBpbiBXZWJSVEMgZm9yIGl0IHRvIGZh aWwganVzdCBiZWNhdXNlIHdlIGZhaWxlZCB0byBtYW5kYXRlIGEgc2luZ2xlIHZpZGVvIGNvZGVj LiBTSVAgYmFzZWQgY29tbXVuaWNhdGlvbiBoYXMgaGFkIGNvbnNpZGVyYWJsZSBtYXJrZXQgc3Vj Y2VzcyB3aXRob3V0IG1hbmRhdGluZyBhbnkgYXVkaW8gb3IgdmlkZW8gY29kZWNzIGFuZCBDTFVF IGRvIG5vdCBzZWUgaXQgbmVjZXNzYXJ5IHRvIG1hbmRhdGUgY29kZWNzIGZvciB0ZWxlcHJlc2Vu Y2UuDQoNCkkgYmVsaWV2ZSB0aGUgY3VycmVudCBwcm9wb3NhbCBhbHNvIGZhaWxlZCB0byBnYXJu ZXIgNTAlIGluIHRoZSBvcmlnaW5hbCBzdHJhdyBwb2xsIGFuZCBJTUhPIG9ubHkgZ2FybmVycyBt b3JlIHN1cHBvcnQgbm93IGJlY2F1c2UgYSB3YXkgaGFzIGJlZW4gZm91bmQgdGhyb3VnaCB0aGUg dXNlIG9mIGRlZmluaXRpb25zIHRoYXQgaW1tdW5pemUgbWFueSBvZiB0aGUgcGFydGllcyBmcm9t IGJlaW5nIGltcGFjdGVkIGJ5IHRoaXMgZGVjaXNpb24uIFN1cHBvcnQgbGV2ZWwgZm9yIGEgdmFy aWFudCBvZiAiY2hvaWNlIDEyIiBpbiB0YW5kZW0gd2l0aCB0aGUgZGVmaW5pdGlvbnMgaW4gdGhl IG92ZXJ2aWV3IGRvY3VtZW50IGhhcyBub3QgeWV0IGJlZW4gcG9sbGVkLg0KDQpJbiB0ZXJtcyBv ZiB0aGUgcGFydGllcyBhY3R1YWxseSBpbXBhY3RlZCBieSB0aGUgZGVjaXNpb24gYSBzaWduaWZp Y2FudCBzZWN0aW9uIG9mIHRoYXQgY29tbXVuaXR5IHN0aWxsIG9wcG9zZXMgdGhlIGN1cnJlbnQg cHJvcG9zYWwuIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWRhbSBSb2Fj aCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5jb21dIA0KU2VudDogTW9uZGF5LCBEZWNlbWJlciAwOCwg MjAxNCAxMDo0NCBQTQ0KVG86IEFuZHJldyBBbGxlbg0KQ2M6IE1haXJlIFJlYXZ5OyBydGN3ZWJA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBjb25maXJtaW5nIHNlbnNlIG9mIHRoZSBy b29tOiBtdGkgY29kZWMNCg0KSSBzZWUgdHdvIHByb3Bvc2FscyBpbiB5b3VyIHJlc3BvbnNlLCBi b3RoIG9mIHdoaWNoIGhhdmUgYmVlbiBleHBsb3JlZCBhbHJlYWR5LiBPbmUgaXMgImNob2ljZSAx IiBmcm9tIHRoZSBzdHJhdyBwb2xsLCB3aGljaCBnYXJuZXJlZCBvbmx5IDQ4JSBzdXBwb3J0LCBh bmQgdGhlIG90aGVyIGlzICJjaG9pY2UgMTIiLCB3aGljaCByZWNlaXZlZCBvbmx5IDclLg0KDQpX aGljaCBpcyB0byBzYXkgdGhhdCB0aGVzZSBhcmUgbm90IG1lcmVseSBpbXBsYXVzaWJsZSwgYnV0 IGRlbW9uc3RyYWJseSBub24tdmlhYmxlLiBTbywgd2hlbiBJIGFza2VkIHdoZXRoZXIgeW91IGhh ZCBhICJjb25zdHJ1Y3RpdmUgYW5kIHBsYXVzaWJsZSBwcm9wb3NhbCwiIHlvdSBjb3VsZCBoYXZl IHNhdmVkIHVzIGFsbCBzb21lIHRpbWUgYnkgc2ltcGx5IHNheWluZyAibm8uIg0KDQovYQ0KDQpP biAxMi84LzE0IDE4OjQ1LCBBbmRyZXcgQWxsZW4gd3JvdGU6DQo+IEFkYW0NCj4NCj4gT3VyIHBy ZWZlcmVuY2UgaXMgZm9yIEguMjY0IHRvIGJlIHRoZSBzaW5nbGUgTVRJLiBXZSBiZWxpZXZlIHRo YXQgQ2lzY28ncyBvcGVuIHNvdXJjZSByb3lhbHR5IGZyZWUgY29kZSBvZmZlciBnb2VzIGEgbG9u ZyBsb25nIHdheSB0byBhZGRyZXNzIHRoZSBjb25jZXJucyBvZiBtYW55IHJlbGF0ZWQgdG8gSVBS IG9uIEguMjY0IGFuZCB0aGUgcHJldmFsZW5jZSBub3cgb2YgQVBJcyB0byBhY2Nlc3MgZW1iZWRk ZWQgY29kZWNzIChzdWNoIGFzIEguMjY0KSBvbiBtb2JpbGUgZGV2aWNlcyBnb2VzIGV2ZW4gZnVy dGhlciB0byBhZGRyZXNzIHRob3NlIGNvbmNlcm5zLiBTZWUgaHR0cDovL3d3dy5pZXRmLm9yZy9p ZC9kcmFmdC1idXJtYW4tcnRjd2ViLWgyNjQtcHJvcG9zYWwtMDUudHh0DQo+DQo+IFdlIGFsc28g aGF2ZSBwcm9wb3NlZCBhcyBhIGNvbXByb21pc2UgaGF2aW5nIDIgTVRJIGRlY29kZXJzIGJ1dCBv bmx5IGhhdmUgdG8gaW1wbGVtZW50IG9uZSBlbmNvZGVyLg0KPg0KPiBJIGtub3cgdGhlIGFib3Zl IGRvZXNuJ3QgbWFrZSBldmVyeW9uZSBoYXBweSBlaXRoZXIuDQo+DQo+IEJ1dCB0aGlzIGN1cnJl bnQgcHJvcG9zZWQgImNvbXByb21pc2UiIHdoaWxzdCBzdWNjZWVkaW5nIGluIGdhcm5lcmluZyBh IHNpZ25pZmljYW50IGh1bSBpbiB0aGUgcm9vbSBpcyBvcHBvc2VkIGJ5IHNvbWUgcmF0aGVyIHNp Z25pZmljYW50IHZlbmRvcnMgaW4gdGhlIGJyb3dzZXIgc3BhY2UuIFNvIHdoaWxzdCBpdCBtYXkg bWFrZSB0aGUgUlRDV0VCIFZpZGVvIFJGQyBsb29rIHByZXR0eSBhbmQgY29tcGxldGUgaXQgaXMg dW5saWtlbHkgdG8gZW5zdXJlIGludGVyb3BlcmFiaWxpdHkgaW4gdGhlIG1hcmtldCBhbnkgbW9y ZSB0aGFuIHNpbXBseSBsZWF2aW5nIGl0IHRvIHRoZSBtYXJrZXQgdG8gZGVjaWRlICh3aGljaCBp cyB3aGF0IHdpbGwgaGFwcGVuIGlmIHdlIGZhaWwgdG8gYWdyZWUgb24gYSBzaW5nbGUgTVRJIHZp ZGVvIGNvZGVjKS4gIEhhdmluZyBhIHN0YW5kYXJkIHRoYXQgaXMgbm90IGZ1bGx5IGltcGxlbWVu dGVkIGJ5IHNvbWUgb2YgdGhlIHByaW1hcnkgcGFydGljaXBhbnRzIGluIHRoZSBtYXJrZXQgZG9l cyBub3QgIGJvZGUgd2VsbCBmb3IgdGhlIHN1Y2Nlc3Mgb2YgdGhlIHN0YW5kYXJkIGV2ZW4gbW9y ZSB0aGFuIG5vdCBhZ3JlZWluZyBvbiBhIHNpbmdsZSBNVEkgY29kZWMgSU1ITy4gQ0xVRSBoYXMg YWdyZWVkIG5vdCB0byBkZWZpbmUgTVRJIGNvZGVjcyBidXQgZG9lcyB0aGlzIG1lYW4gdGhhdCB0 ZWxlcHJlc2VuY2UgaW50ZXJvcGVyYWJpbGl0eSB3aWxsIGJlIGEgZmFpbHVyZSAtIEkgdGhpbmsg bm90Lg0KPg0KPiBCZXRhTWF4IHZzIFZIUyBhbmQgQmx1IFJheSB2cyBIRCBEVkQgaGF2ZSBzaG93 biB0aGF0IHVsdGltYXRlbHkgdGhlIG1hcmtldCB3aWxsIHJlc29sdmUgdGhlc2UgZW50cmVuY2hl ZCBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyB3aGljaCBhcmUgYmFzZWQgb24gYnVzaW5lc3MgcmVh c29ucyBub3QgdGVjaG5pY2FsIG1lcml0IHdpdGhvdXQgZXZlcnlvbmUgaGF2aW5nIHRvIGFncmVl IGluIGEgc3RhbmRhcmRzIGJvZHkgdG8gc3VwcG9ydCBib3RoIG9yIHRvIHN1cHBvcnQgb25seSBv bmUuDQo+DQo+IEFuZHJldw0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBBZGFtIFJvYWNoIFttYWlsdG86YWRhbUBub3N0cnVtLmNvbV0NCj4gU2VudDogTW9uZGF5LCBE ZWNlbWJlciAwOCwgMjAxNCA2OjU3IFBNDQo+IFRvOiBBbmRyZXcgQWxsZW4NCj4gQ2M6IE1haXJl IFJlYXZ5OyBydGN3ZWJAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtydGN3ZWJdIGNvbmZpcm1p bmcgc2Vuc2Ugb2YgdGhlIHJvb206IG10aSBjb2RlYw0KPg0KPg0KPg0KPj4gT24gRGVjIDgsIDIw MTQsIGF0IDE3OjI4LCBBbmRyZXcgQWxsZW4gPGFhbGxlbkBibGFja2JlcnJ5LmNvbT4gd3JvdGU6 DQo+Pg0KPj4gSWYgd2UgZGVjaWRlIG9uIHR3byBNVEkgdmlkZW8gY29kZWNzIHRoZW4gd2UgaGF2 ZSBjbGVhcmx5IGZhaWxlZCB0byBtZWV0IHRoaXMgY29tbWl0bWVudC4NCj4gRG8geW91IGhhdmUg YSBjb25zdHJ1Y3RpdmUgYW5kIHBsYXVzaWJsZSBwcm9wb3NhbD8NCj4NCj4gL2ENCg0K From nobody Mon Dec 8 21:56:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE171A1BFC for ; Mon, 8 Dec 2014 21:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akDgb1QKjslu for ; Mon, 8 Dec 2014 21:56:01 -0800 (PST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4261A1BF8 for ; Mon, 8 Dec 2014 21:56:00 -0800 (PST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 08 Dec 2014 21:55:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="426768464" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by FMSMGA003.fm.intel.com with ESMTP; 08 Dec 2014 21:44:47 -0800 Received: from fmsmsx116.amr.corp.intel.com (10.18.116.20) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 8 Dec 2014 21:55:24 -0800 Received: from fmsmsx118.amr.corp.intel.com ([169.254.1.40]) by fmsmsx116.amr.corp.intel.com ([169.254.2.16]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 21:55:23 -0800 From: "Cavigioli, Chris" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQE04qEBti1FXXNkmH1ALOez9gJ5yGwRTA Date: Tue, 9 Dec 2014 05:55:23 +0000 Message-ID: References: <54820E74.90201@mozilla.com> <5485E627.5050706@jesup.org> <21E818AE-0F44-4BA1-AA59-8322C982446E@apple.com> In-Reply-To: <21E818AE-0F44-4BA1-AA59-8322C982446E@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.108] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0_0bO_yNtYESJ6Cm9Dwx0GndIEA Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 05:56:03 -0000 SSBsaWtlIHRoYXQgcHJvcG9zYWwsIERhdmUuDQoNCisxICAgIElOVEVMIENPUlAgaGFzIGFscmVh ZHkgaW1wbGVtZW50ZWQgYm90aCBILjI2NCBhbmQgVlA4IC4uLiBib3RoIGVuY29kZSBhbmQgZGVj b2RlLiAgIERvbmUuICAgDQoNCldlIGFscmVhZHkgZGVtb25zdHJhdGVkIGhhcmR3YXJlIFdlYlJU QyB0byB0aGUgcHVibGljIGF0IE1XQycxNCBpbiBCYXJjZWxvbmEgaW4gRmVicnVhcnkgb24gb3Vy IHNtYXJ0cGhvbmUgcGxhdGZvcm0uICAgRG9uZS4NCg0KV2Ugd2VsY29tZSB0aGUgY29uc2Vuc3Vz IGRlY2lzaW9uIG1hZGUgYnkgSUVURiBhbmQgbG9vayBmb3J3YXJkIHRvIG1vdmluZyBmb3J3YXJk IHdpdGggV2ViUlRDLg0KLWNocmlzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERh dmlkIFNpbmdlcg0KU2VudDogTW9uZGF5LCBEZWNlbWJlciAwOCwgMjAxNCA1OjE5IFBNDQpUbzog cnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gY29uZmlybWluZyBzZW5zZSBv ZiB0aGUgcm9vbTogbXRpIGNvZGVjDQoNCg0KPiBPbiBEZWMgOCwgMjAxNCwgYXQgMTA6MDAgLCBJ w7Fha2kgQmF6IENhc3RpbGxvIDxpYmNAYWxpYXgubmV0PiB3cm90ZToNCj4gDQo+IDIwMTQtMTIt MDggMTg6NTUgR01UKzAxOjAwIFJhbmRlbGwgSmVzdXAgPHJhbmRlbGwtaWV0ZkBqZXN1cC5vcmc+ Og0KPj4gKzEgLSBpdCdzIGJ5IG5vIG1lYW5zIG15IHByZWZlcnJlZCBzb2x1dGlvbiwgYnV0IGl0 J3Mgb25lIEkgY2FuIGxpdmUgDQo+PiArd2l0aCwNCj4+IGFuZCBiZXR0ZXIgdGhhbiB0aGUgYWx0 ZXJuYXRpdmUgb2YgdGhlIHN0YXR1cy1xdW8gLSBubyBNVEkgYXQgYWxsLiAgDQo+PiBJZiBpdCB3 YXNuJ3QgZm9yIE9wZW5IMjY0LCBteSBhbnN3ZXIgd291bGQgYmUgZGlmZmVyZW50Lg0KPj4gDQo+ PiBJIGNhbid0IHNlZSBhZG9wdGluZyBILjI2NCBhcyBzb2xlIE1USSwgYW5kIEkgY2FuJ3Qgc2Vl IHRoYXQgd2UnZCBnZXQgDQo+PiBjb25zZW5zdXMgdG8gYWRvcHQgVlA4IGFzIHNvbGUgTVRJLg0K PiANCj4gVGhlcmUgd2FzIGEgbXVjaCBiZXR0ZXIgc29sdXRpb246DQo+IA0KPiAtIERvbid0IG1h a2UgVlA4IG5vciBIMjY0IE1USS4NCj4gLSBTbyBmb3Igbm93IG5vIE1USSB2aWRlbyBjb2RlYy4N Cj4gLSBBbmQgYSBXM0MgY29tcHJvbWlzZTogRmlyc3QgdmlkZW8gY29kZWMgMTAwJSByb3lhbHR5 IGZyZWUgd291bGQgDQo+IGJlY29tZSBNVEkgaW4gV2ViUlRDLg0KPiANCj4gVGhpbmdzIHdvdWxk IGJlIGV4YWN0bHkgYXMgdGhleSBhcmUgbm93LCBidXQgYXQgbGVhc3Qgd2UgYXZvaWQgYSANCj4g Ik1VU1QiIHRoYXQgd2lsbCBiZSBpZ25vcmVkIGJ5IDUwJSBvZiB0aGUgbWFya2V0Lg0KDQpUaGF0 IHdvdWxkIGJlIG1vcmUgaG9uZXN0LCBpbmRlZWQuIEl0IGlzIGVmZmVjdGl2ZWx5IHdoZXJlIHdl IGFyZSBnb2luZyB0byBiZS4gIEFuZCBpdCBvZmZlcnMgYSBjYXJyb3QgaW4gdGhlIHJpZ2h0IGRp cmVjdGlvbi4NCg0KSSBhbSBjdXJpb3VzIHRvIGtub3cgaG93IG1hbnkgb2YgdGhlIHBlb3BsZSBz dXBwb3J0aW5nIHRoZSBwcm9wb3NlZCBwb3NpdGlvbiBhY3R1YWxseSB3b3VsZCBpbXBsZW1lbnQg Ym90aCBlbmNvZGUgYW5kIGRlY29kZSBvZiBib3RoIGNvZGVjcz8gIFRoaXMgZm9sbG93cyBmcm9t IGNvbW1lbnRzIG9uIHRoaXMgdGhyZWFkIHRoYXQgcGVvcGxlIHdobyBmZWVsIHRoZXkgZmFsbCBp bnRvIGEgZGlmZmVyZW50IGNhdGVnb3J5IGFyZSBhc2tpbmcgb3RoZXJzIHRvIHNvbHZlIHRoZWly IHByb2JsZW0uDQoNClNvLCByYXRoZXIgdGhhbiArMSwgcGxlYXNlIHNheSDigJxJIHdvdWxkIGV4 cGVjdCB0byBpbXBsZW1lbnQgYm90aOKAnSAobm9uLWJpbmRpbmcsIG9mIGNvdXJzZSkg4oCUIGl0 IHdvdWxkIGJlIGEgbW9yZSB1c2VmdWwgdGhpbmcgdG8gc2VlLCBJIHRoaW5rLg0KDQoNCg0KQW5v dGhlciBwb3NzaWJsZSBjaG9pY2U6DQoNCiogYWRtaXQgdGhhdCB3ZSBhbHJlYWR5IGhhdmUgcG9z c2libGUgbm9uLWludGVyb3BlcmFiaWxpdHkgKFdlYlJUQy1jb21wYXRpYmxlIEVuZHBvaW50cyB0 aGF0IGNob29zZSBkaWZmZXJlbnRseSksIGFuZCB0aGF0IGFueW9uZSB3aG8gZG9lc27igJl0IHdh bnQgdG8gZG8gYm90aCB3aWxsIHNheSB0aGF0IHRoaXMgd2hhdCB0aGV5IGFyZSBtYWtpbmcgKGFz IHdhcyBzdWdnZXN0ZWQpOiAgc2ltcGx5IGRlbGV0ZSB0aGUgcmVxdWlyZW1lbnQgb3IgZGVmaW5p dGlvbnMgZm9yIFdlYlJUQyBVc2VyLWFnZW50IGFuZCBEZXZpY2UuIE5vdGhpbmcgc3RvcHMgdGhv c2UgdGhhdCB3YW50IHRvIGZyb20gaW1wbGVtZW50aW5nIGJvdGgsIHdpdGhvdXQgb3Igd2l0aG91 dCB0aGUgbWFuZGF0ZS4gIEkgZG9u4oCZdCB0aGluayB0aGlzIHdvdWxkIG1ha2UgYW55IG1hdGVy aWFsIGRpZmZlcmVuY2UgdG8gd2hhdCBoYXBwZW5zLCBidXQgaXQgbWFrZXMgdGhlIHNwZWMgYW5k IHJlYWxpdHkgYSBsaXR0bGUgY2xvc2VyLg0KDQoNCg0KRmluYWxseSwgSSB3b25kZXIsIHdoYXQg d291bGQgaXQgYmUgbGlrZSBpZiB3ZSBhY3R1YWxseSB0cmllZCB0byBnZXQgY2xvc2VyIHRvIGlu dGVyb3A6IEFMTCBlbmRwb2ludHMg4oCUIGFueXRoaW5nIHRoYXQgY2FuIG9wZXJhdGUgYXQgb25l IGVuZCBvZiBhIFdlYlJUQyBzZXNzaW9uLCBiZSBpdCBkZXZpY2UsIFVBLCBnYXRld2F5LCBjb21w YXRpYmxlLWVuZHBvaW50LCB3aGF0ZXZlciDigJQgbXVzdCBiZSBhYmxlIHRvIGRlY29kZSAoYWN0 dWFsbHksIG9mZmVyIHRvIHJlY2VpdmUpIGJvdGgsIGFuZCBtdXN0IGJlIGFibGUgdG8gZW5jb2Rl IGF0IGxlYXN0IG9uZT8gIEnigJlkIGhhdmUgdG8gdGhpbmsgYWJvdXQgdGhlIGNvbnNlcXVlbmNl cyBvZiBkb2luZyBkZWNvZGUtb25seSwgYnV0IGl04oCZcyBhIGxvc3MgbGVzcyB3b3JrIHRoYW4g YSBkZWNlbnQgZW5jb2RlciwgZm9yIGEgc3RhcnQuIFRoaXMgd291bGQgcmVzdWx0IGluIGludGVy b3AgaWYgcGVvcGxlIGFjdHVhbGx5IGRpZCBpdC4NCg0KDQpEYXZpZCBTaW5nZXINCk1hbmFnZXIs IFNvZnR3YXJlIFN0YW5kYXJkcywgQXBwbGUgSW5jLg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K From nobody Mon Dec 8 22:09:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6C91A1EF3 for ; Mon, 8 Dec 2014 22:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQtGJpkIHlIK for ; Mon, 8 Dec 2014 22:09:32 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id CAB281A1C04 for ; Mon, 8 Dec 2014 22:09:31 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id C4E8932E56F; Tue, 9 Dec 2014 15:08:45 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 34c8_2e58_a7507f15_bc77_4ba7_a68e_81485fe96e14; Tue, 09 Dec 2014 15:08:45 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 20A27BF544; Tue, 9 Dec 2014 15:08:45 +0900 (JST) Message-ID: <548691EB.30600@it.aoyama.ac.jp> Date: Tue, 09 Dec 2014 15:08:43 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Silvia Pfeiffer , Justin Uberti References: <5485CC5B.2030104@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5ViNINYIoJognKGa85zMmu5T4rw Cc: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 06:09:40 -0000 +1. Regards, Martin. On 2014/12/09 05:17, Silvia Pfeiffer wrote: > I wasn't at the meeting, but I too support the compromise. It's non > optimal, but pragmatic and all that's achievable in the given circumstances. > > Best Regards, > Silvia. > On 9 Dec 2014 04:40, "Justin Uberti" wrote: > >> I support the rough consensus as presented by the chair. >> >> As stated before - I think this plan represents a legitimate compromise >> in what had previously seemed like a stalemate. While not my ideal outcome, >> I think this is good for the WebRTC ecosystem - it ensures >> interoperability, and provides a reasonably clear path for reaching a >> completely RF solution. >> >> On Mon, Dec 8, 2014 at 9:27 AM, Martin Thomson >> wrote: >> >>> On 8 December 2014 at 08:05, Harald Alvestrand >>> wrote: >>>> Since others who were present in the room are repeating their position >>>> on the list, I'll do so too. >>> >>> That's probably a good thing to do. An almost anonymous humming sound >>> isn't a good basis for establishing a record. >>> >>>> I support the rough consensus as presented by the chair. >>> >>> +1 >>> >>> _______________________________________________ >>> 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 >> >> > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Tue Dec 9 01:44:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126BB1A1AA5 for ; Tue, 9 Dec 2014 01:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQRe0FGOrgyQ for ; Tue, 9 Dec 2014 01:44:48 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 180471A00BB for ; Tue, 9 Dec 2014 01:44:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5489C7C3761 for ; Tue, 9 Dec 2014 10:44:47 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpbnDV62XEeK for ; Tue, 9 Dec 2014 10:44:46 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:603b:7836:2531:29df] (unknown [IPv6:2001:470:de0a:27:603b:7836:2531:29df]) by mork.alvestrand.no (Postfix) with ESMTPSA id EA6C87C363F for ; Tue, 9 Dec 2014 10:44:45 +0100 (CET) Message-ID: <5486C48D.8040602@alvestrand.no> Date: Tue, 09 Dec 2014 10:44:45 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/d30QkODhXNUEgyJlf9GBb8Y2Vmg Subject: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 09:44:50 -0000 I note that the "confirming sense of the room" thread has gotten a lot of messages that are not declaring a position on the question. I also note that from the messages on the thread, I can't figure out if Keith Drage, Gili, Monty Montgomery or Peter Saint-Andre have taken a position (I could guess, but I don't want to - besides, they might not want to take a position, which is perfectly OK). It would be nice for me as a reader if people could: - state their position on the "confirming sense of the room" thread - change the subject line when they want to say anything else That's my preference - of course, people who have "mute thread" in their email readers might want the whole discussion to stay on thread, and will hate me for the last suggestion.... Harald From nobody Tue Dec 9 02:11:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84201A0030 for ; Tue, 9 Dec 2014 02:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNLgr7Z81W8Y for ; Tue, 9 Dec 2014 02:11:16 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6936D1A0020 for ; Tue, 9 Dec 2014 02:11:16 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hz20so213736lab.34 for ; Tue, 09 Dec 2014 02:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Du087F2/XQ7n3SINrWI+Wxm9ym8a+OPSIO0PLgLCRG8=; b=yU6uJ9uWKbsHwbJlNJziNQoczI9t7lQezB1GUhLXQMFXQ4zmKPOVCgBqAZnYf1tQe9 y9bVn6nxjtVHLWqRSWNI7DxkaMyEFhWsEh2ulACYA9fYa1il426LYQzQ8Pg1k6+2se7L gq5lRQv+wNfuLuiNCzN9Y1KU1mkjykKxYrLKnp9ahH/77JCZcAVncs7WJ3qfyrlry5OB 5g2PCUMCT0xkwnwFVGR8Ig6h0epQgUQ14KeMiUAIGI0abz8HbyaVsHdA590OwKeZ6pGH wR7q8sgS5yga3aR+OVg27SLwNBDqzYUKHsZ+DjCBncP8YaCiwjKZaivK78qGb4CCip6f etXA== MIME-Version: 1.0 X-Received: by 10.152.116.79 with SMTP id ju15mr20854869lab.84.1418119874698; Tue, 09 Dec 2014 02:11:14 -0800 (PST) Received: by 10.112.188.229 with HTTP; Tue, 9 Dec 2014 02:11:14 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Dec 2014 05:11:14 -0500 Message-ID: From: Monty Montgomery To: Sean Turner Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Eu_i1aeJ4fBcFhgLmcWN4fNDtu4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 10:11:19 -0000 +1; I agree there was rough consensus (the overwhelming majority appeared to support the compromise, though there were strong objections from the remaining minority). (See also ietfmemes 'Am I the only one here who wants to make a decision?") My personal position is in favor of the compromise as presented and hummed. I don't _like_ it, but it's better than the alternatives, including doing nothing. Monty From nobody Tue Dec 9 03:04:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97ED1A1B18 for ; Tue, 9 Dec 2014 03:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y87ScgOPOCEy for ; Tue, 9 Dec 2014 03:04:35 -0800 (PST) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14901A1AE8 for ; Tue, 9 Dec 2014 03:04:34 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id hq12so135611vcb.41 for ; Tue, 09 Dec 2014 03:04:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8UpytODkmGevzplpVzKype1l4YWPhmYm67ldaelT7Gk=; b=jirK0Wy+8ygQBnAeAOaSXlDf8vgxZOYLdcc7CwqHQsG4lyObDBc6s9Lvj7aENru4d3 GB7os+5bXtWqY8im1Q5QjU+t/NTqY0K1IEvGOhmZkw2yM9PZrdbPUcsuM3ZYQQ2oDmuC vkp8XMw4J8U361fZJPe+sgWCE3+V7ZfYPif9l3+/z3K/eoo71igReeVaInZTZ5s2WF06 FiDJR5miKGtwjEoIO7PHxGLrj+xC9g3YVSK8F3Jf0InjZHLQc6jA/JY/McVU1hNT8ckQ xISVtXgcVZLKMA5yo0rR+cV6simLa3oM9da6cDLcEJSrTYMD4/KucnJkm6N6HCbQgb/k No0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8UpytODkmGevzplpVzKype1l4YWPhmYm67ldaelT7Gk=; b=LBXI+uJ1lhEcFMDjcBLsgw3q3sjoG+lr4Kyp6vMsD10OA+CdJxuFCIMjpgqyODmg8u 1GJ9ahCR68MX6R233Y6dD20JXSgP8FXgSaz05FbQiRp0NsgdujkjZkvuRGpda7rea8B0 C/cWMk+x3wGCeHU2yQYrefcGZyh4sMsllysbtWcfw/kkjif+4rwRodqoEJvEdD5FqPIw crdxtlX7wlCvG2IbU7d+IvTljvVaOg2mjaqr/concpFnKoejXuvfdKqkgecFQvbNaIzc z3lnlb5u7KciNFrTJyoRvHZt6Tib4wr5Z/xUOrWkJ6EYCy1UYZhdbc9/yxC9sOAqrbaq imcg== X-Gm-Message-State: ALoCoQmxDjFf1b38In4S1+Lj70yPexXlU4PfEBkiwq3fuo09p8JtNQzqX+X5UhobLQQdtFlME6zp X-Received: by 10.52.117.161 with SMTP id kf1mr667115vdb.65.1418123073687; Tue, 09 Dec 2014 03:04:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.84.69 with HTTP; Tue, 9 Dec 2014 03:03:53 -0800 (PST) In-Reply-To: References: From: Peter Thatcher Date: Tue, 9 Dec 2014 03:03:53 -0800 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=bcaec547cbdd0e2bd90509c682ef Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Dii0_G7n-fwqWkcE8ASL1T-aIPo Cc: "" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 11:04:37 -0000 --bcaec547cbdd0e2bd90509c682ef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support the rough consensus as presented by the chair. On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner wrote: > All, > > At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about > codecs, which I dubbed "the great codec compromise." The compromise text > that was discussed appears in slides 12-14 at [4] (which is a slight > editorial variation of the text proposed at [2]). > > This message serves to confirm the sense of the room. > > In the room, I heard the following objections and responses (and I=E2=80= =99m > paraphrasing here), which I=E2=80=99ll take the liberty of categorizing a= s IPR, > Time, and Trigger: > > 1) IPR: > > Objections: There are still IPR concerns which may restrict what a > particular organization feels comfortable with including in their browser > implementations. > > Response: IPR concerns on this topic are well known. There is even a > draft summarizing the current IPR status for VP8: > draft-benham-rtcweb-vp8litigation. The sense of the room was still that > adopting the compromise text was appropriate. > > 2) Time: > > 2.1) Time to consider decision: > > Objection: The decision to consider the compromise proposal at this > meeting was provided on short notice and did not provide some the > opportunity to attend in person. > > Response: Six months ago the chairs made it clear discussion would be > revisited @ IETF 91 [0]. The first agenda proposal for the WG included th= is > topic [1], and the topic was never removed by the chairs. More > importantly, all decisions are confirmed on list; in person attendance is > not required to be part of the process. > > 2.2) Time to consider text: > > Objection: The proposed text [2] is too new to be considered. > > Response: The requirement for browsers to support both VP8 and H.264 was > among the options in the straw poll conducted more than six months ago. > All decisions are confirmed on list so there will be ample time to discus= s > the proposal. > > 3) Trigger: > > Objection: The =E2=80=9Ctrigger=E2=80=9D sentence [3] is all kinds of wro= ng because it=E2=80=99s > promising that the future IETF will update this specification. > > Response: Like any IETF proposal, an RFC that documents the current > proposal can be changed through the consensus process at any other time. > > > After the discussion, some clarifying questions about the hums, and typin= g > the hum questions on the screen, there was rough consensus in the room to > add (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draft-ietf-rtcwe= b-video. In > keeping with IETF process, I am confirming this consensus call on the lis= t. > > If anyone has any other issues that they would like to raise please do by > December 19th. > > Cheers, > spt (as chair) > > [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html > [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html > [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html > [3] The one that begins with "If compelling evidence ..." > [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec547cbdd0e2bd90509c682ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0I support the rough consensus as presented by the cha= ir.

On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner <= turners@ieca.com&= gt; wrote:
All,

At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about co= decs, which I dubbed "the great codec compromise."=C2=A0 The comp= romise text that was discussed appears in slides 12-14 at [4] (which is a s= light editorial variation of the text proposed at [2]).

This message serves to confirm the sense of the room.

In the room, I heard the following objections and responses (and I=E2=80=99= m paraphrasing here), which I=E2=80=99ll take the liberty of categorizing a= s IPR, Time, and Trigger:

1) IPR:

Objections: There are still IPR concerns which may restrict what a particul= ar organization feels comfortable with including in their browser implement= ations.

Response:=C2=A0 IPR concerns on this topic are well known.=C2=A0 There is e= ven a draft summarizing the current IPR status for VP8: draft-benham-rtcweb= -vp8litigation.=C2=A0 The sense of the room was still that adopting the com= promise text was appropriate.

2) Time:

2.1) Time to consider decision:

Objection: The decision to consider the compromise proposal at this meeting= was provided on short notice and did not provide some the opportunity to a= ttend in person.

Response:=C2=A0 Six months ago the chairs made it clear discussion would be= revisited @ IETF 91 [0]. The first agenda proposal for the WG included thi= s topic [1], and the topic was never removed by the chairs.=C2=A0 =C2=A0 Mo= re importantly, all decisions are confirmed on list; in person attendance i= s not required to be part of the process.

2.2) Time to consider text:

Objection: The proposed text [2] is too new to be considered.

Response: The requirement for browsers to support both VP8 and H.264 was am= ong the options in the straw poll conducted more than six months ago.=C2=A0= All decisions are confirmed on list so there will be ample time to discuss= the proposal.

3) Trigger:

Objection: The =E2=80=9Ctrigger=E2=80=9D sentence [3] is all kinds of wrong= because it=E2=80=99s promising that the future IETF will update this speci= fication.

Response: Like any IETF proposal, an RFC that documents the current proposa= l can be changed through the consensus process at any other time.


After the discussion, some clarifying questions about the hums, and typing = the hum questions on the screen, there was rough consensus in the room to a= dd (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draft-ietf-rtcweb-v= ideo.=C2=A0 In keeping with IETF process, I am confirming this consensus ca= ll on the list.

If anyone has any other issues that they would like to raise please do by D= ecember 19th.

Cheers,
spt (as chair)

[0] http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg11194.html
[1] http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg13150.html
[2] http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg13432.html
[3] The one that begins with "If compelling evidence ..."
[4] http://www.ietf.org/proceedings/91/slides/slides-91= -rtcweb-7.pdf
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--bcaec547cbdd0e2bd90509c682ef-- From nobody Tue Dec 9 04:24:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B62C1A1BF8 for ; Tue, 9 Dec 2014 04:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzgP2ZHkWeHo for ; Tue, 9 Dec 2014 04:24:30 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0480B1A1BEE for ; Tue, 9 Dec 2014 04:24:29 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-b6-5486e9fc1271 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F2.08.04231.CF9E6845; Tue, 9 Dec 2014 13:24:28 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.198]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 13:24:28 +0100 From: Bo Burman To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEJCFhsu2EGhtiU+0E+mY/Iij7JyFz8OAgAAWtgCAAAOXgIAAK/+AgAClN4CAAELMcA== Date: Tue, 9 Dec 2014 12:24:27 +0000 Message-ID: References: <5485CC5B.2030104@alvestrand.no> <548691EB.30600@it.aoyama.ac.jp> In-Reply-To: <548691EB.30600@it.aoyama.ac.jp> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvje6fl20hBv0TxSzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpej+5kK5ghVnP18g6WB8QZfFyMnh4SAiUTb3JnsELaYxIV7 69m6GLk4hASOMEo8+XUEylnMKPG68x9YFZuAhsT8HXcZQWwRAXWJyw8vgMWFBWwlrrx7CRW3 kzixfxaUHSax+9cZZhCbRUBFou0bRC+vgK/EpolbGSEWXGOSuLB7ORNIglNAV+LP980sIDaj gKzE/e/3wGxmAXGJW0/mM0GcKiCxZM95ZghbVOLl43+sELaiRPvTBkaIej2JG1OnsEHY2hLL Fr5mhlgsKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFC1OLS7OTTcy1kstykwuLs7P08tL LdnECIyLg1t+6+5gXP3a8RCjAAejEg/vhtS2ECHWxLLiytxDjNIcLErivIvOzQsWEkhPLEnN Tk0tSC2KLyrNSS0+xMjEwSnVwOizvapnwjk+zdPbnpyY2HxAcardwzmnluzqCJHbtSW3bfLu Bxf/bN9fcqSB2Y9Pu0POb00p007Zs1b1F/rm56bmtaVd5zintCbBNpRzpvkPcyHGc3H/WQ6n P/j6w1NqWZKkx5tWE4HSOtuJxibOCsfnLObhl2D/33T+hOjPea2yWVKHb10zX6/EUpyRaKjF XFScCABQ1VtObAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PjXFa4WjrtZitvc0amhzFkek3hQ Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 12:24:32 -0000 +1. I support the rough consensus as presented by the chair. Best Regards, Bo > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of "Martin J. D= =FCrst" > Sent: den 9 december 2014 07:09 > To: Silvia Pfeiffer; Justin Uberti > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] confirming sense of the room: mti codec >=20 > +1. Regards, Martin. >=20 > On 2014/12/09 05:17, Silvia Pfeiffer wrote: > > I wasn't at the meeting, but I too support the compromise. It's non > > optimal, but pragmatic and all that's achievable in the given circumsta= nces. > > > > Best Regards, > > Silvia. > > On 9 Dec 2014 04:40, "Justin Uberti" wrote: > > > >> I support the rough consensus as presented by the chair. > >> > >> As stated before - I think this plan represents a legitimate > >> compromise in what had previously seemed like a stalemate. While not > >> my ideal outcome, I think this is good for the WebRTC ecosystem - it > >> ensures interoperability, and provides a reasonably clear path for > >> reaching a completely RF solution. > >> > >> On Mon, Dec 8, 2014 at 9:27 AM, Martin Thomson > >> > >> wrote: > >> > >>> On 8 December 2014 at 08:05, Harald Alvestrand > >>> > >>> wrote: > >>>> Since others who were present in the room are repeating their > >>>> position on the list, I'll do so too. > >>> > >>> That's probably a good thing to do. An almost anonymous humming > >>> sound isn't a good basis for establishing a record. > >>> > >>>> I support the rough consensus as presented by the chair. > >>> > >>> +1 > >>> > >>> _______________________________________________ > >>> 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 > >> > >> > > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Dec 9 05:52:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603B81A1A9C for ; Tue, 9 Dec 2014 05:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSn_MNW9Ph8z for ; Tue, 9 Dec 2014 05:52:02 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0F01A1A7A for ; Tue, 9 Dec 2014 05:52:02 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id E0B5D23F0569 for ; Tue, 9 Dec 2014 14:52:00 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.192]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 14:52:00 +0100 From: "Hutton, Andrew" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEy+of4TO2bgXw0CYmosb75uvLJyHRcDQ Date: Tue, 9 Dec 2014 13:51:59 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E638036@MCHP04MSX.global-ad.net> References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> In-Reply-To: <54861AD6.8090603@reavy.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/llf89myAndkXSimyq7anrjJ62vs Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 13:52:08 -0000 +1 I support the compromise plan as presented by the chair. Also agree with Maire and hope we can put a lid on this and return to usefu= l discussion. Andy > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Maire Reavy > Sent: 08 December 2014 21:41 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] confirming sense of the room: mti codec >=20 > On 12/5/2014 2:58 PM, Jean-Marc Valin wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Considering that: > > 1) We have committed to an MTI video codec > > 2) All consensus calls on "VP8 only" and "H.264 only" have failed > > 3) This is the only proposal that gets support from both camps > > I strongly support this MTI proposal. > > Please, let's close this debate once and for all. This compromise is > > by no means great, but it's much better than anything else we're > going > > to get otherwise (i.e. more wasted time and still no MTI). > A big +1 >=20 > We have spent *so* many hours already considering, discussing, & > debating what to do about the MTI video codec. One could argue an > "insane amount" of time relative to the other issues we need to > resolve. We did this because most of us realized that "no MTI" could > be > horrific for the standard. We should embrace consensus around anything > less than horrific, and most of us agree that this compromise is less > than horrific (not great, but less than horrific). >=20 > Right now I fear we're on the verge of shooting ourselves in the foot > or > head (I'm not sure which) by reopening this discussion even though > we're > in sight of the end. I ask that the working group and the chairs put > the proverbially safety back on the gun, declare consensus on this > less-than-horrific proposal, and finish our work on "v1.0" of the spec. >=20 > Please. >=20 > -Maire > ------------------------- > Maire Reavy > mdr@reavy.org >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Dec 9 06:28:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0751A1A42 for ; Tue, 9 Dec 2014 06:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4skBKSeydEll for ; Tue, 9 Dec 2014 06:28:06 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F0A1A0103 for ; Tue, 9 Dec 2014 06:28:06 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gm9so616554lab.12 for ; Tue, 09 Dec 2014 06:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ToycZhHNLV9TBQjFycX0dmdvapo8jFHfcecsM2JgRyE=; b=oDGXL2oocOnC7cBLg45Y+mwmjaE3kDtumg665x4Ujq/nqGaq4tBbtONxbypbCJi71f w8bGe4v/u8wbhKexZxrHi9pOvj8reO6+qzTasbX5jwcFfknMK2OYR7zwHgUOSYdxPSHW 4weVLcPgu/bcJQay/6XRAIedlifcpJU++sFv7Ukk0H6Xp6k9uHU55RdURRvDxZxtAKNn 7f/wXvixBoMFens59c0bw8netQ5Bx2WIK+a7UWSk5EetIbz39mbi85mjF4rmSBg39OtS Z8QXpDbJNHc4aFSxW2nRmdmtppIx9jLEzrNRUdkHPJogzZUh9Qbp9DrrRYo9Bl3ql7By neoA== MIME-Version: 1.0 X-Received: by 10.112.199.138 with SMTP id jk10mr22026646lbc.86.1418135284736; Tue, 09 Dec 2014 06:28:04 -0800 (PST) Received: by 10.25.205.201 with HTTP; Tue, 9 Dec 2014 06:28:04 -0800 (PST) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E638036@MCHP04MSX.global-ad.net> References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <9F33F40F6F2CD847824537F3C4E37DDF1E638036@MCHP04MSX.global-ad.net> Date: Tue, 9 Dec 2014 15:28:04 +0100 Message-ID: From: Victor Pascual Avila To: "Hutton, Andrew" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/J9c83EI9IzQVBSzzcwPONb1r3VM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 14:28:08 -0000 I support having both VP8 and H.264 as MTI -- however, believe decision should be revisited not only for non-browsers but also browsers. Current text: "To promote the use of non-royalty bearing video codecs, participants in the RTCWEB working group, and any successor working groups in the IETF, intend to monitor the evolving licensing landscape as it pertains to the two mandatory-to- implement codecs. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, the working group plans to revisit the question of which codecs are required for Non-Browsers, with the intention being that the royalty-free codec will remain mandatory to implement, and the other will become optional. These provisions apply to WebRTC Non-Browsers only. There is no plan to revisit the codecs required for WebRTC Browsers." -Victor On Tue, Dec 9, 2014 at 2:51 PM, Hutton, Andrew wr= ote: > +1 I support the compromise plan as presented by the chair. > > Also agree with Maire and hope we can put a lid on this and return to use= ful discussion. > > Andy > > > >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Maire Reavy >> Sent: 08 December 2014 21:41 >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] confirming sense of the room: mti codec >> >> On 12/5/2014 2:58 PM, Jean-Marc Valin wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > Considering that: >> > 1) We have committed to an MTI video codec >> > 2) All consensus calls on "VP8 only" and "H.264 only" have failed >> > 3) This is the only proposal that gets support from both camps >> > I strongly support this MTI proposal. >> > Please, let's close this debate once and for all. This compromise is >> > by no means great, but it's much better than anything else we're >> going >> > to get otherwise (i.e. more wasted time and still no MTI). >> A big +1 >> >> We have spent *so* many hours already considering, discussing, & >> debating what to do about the MTI video codec. One could argue an >> "insane amount" of time relative to the other issues we need to >> resolve. We did this because most of us realized that "no MTI" could >> be >> horrific for the standard. We should embrace consensus around anything >> less than horrific, and most of us agree that this compromise is less >> than horrific (not great, but less than horrific). >> >> Right now I fear we're on the verge of shooting ourselves in the foot >> or >> head (I'm not sure which) by reopening this discussion even though >> we're >> in sight of the end. I ask that the working group and the chairs put >> the proverbially safety back on the gun, declare consensus on this >> less-than-horrific proposal, and finish our work on "v1.0" of the spec. >> >> Please. >> >> -Maire >> ------------------------- >> Maire Reavy >> mdr@reavy.org >> >> _______________________________________________ >> 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 --=20 Victor Pascual =C3=81vila From nobody Tue Dec 9 08:09:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A991A0373 for ; Tue, 9 Dec 2014 08:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjaNCmplLUe6 for ; Tue, 9 Dec 2014 08:09:07 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B48F1A0262 for ; Tue, 9 Dec 2014 08:09:07 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB9G903k077254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2014 10:09:00 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54871E9B.4010005@nostrum.com> Date: Tue, 09 Dec 2014 10:08:59 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Andrew Allen References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <54867014.7000709@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GYAJrm8DSpfL0Q5AD5sj7VPynjI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 16:09:08 -0000 On 12/8/14 22:46, Andrew Allen wrote: > And the 3rd alternative is that we agree that we cannot agree on a single MTI video codec and let the market decide. Wait... didn't this subthread start with your objecting to the proposal on the grounds that that it failed to meet some commitment to specify "an MTI codec"? How do you believe this alternative meets that commitment? I'm sorry, you're grasping at straws so furiously that you can't even argue on the same side of the issue for very long -- but I guess that's to be expected when you're simply fast-forwarding through other people's old arguments that have been heard and considered by the group already. It's hard to believe that this is anything but a clumsy attempt at targeted obstruction. /a From nobody Tue Dec 9 08:50:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB4C1A8953 for ; Tue, 9 Dec 2014 08:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-uvE6O2BX-8 for ; Tue, 9 Dec 2014 08:50:06 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301A41A897D for ; Tue, 9 Dec 2014 08:49:54 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id rd18so867871iec.36 for ; Tue, 09 Dec 2014 08:49:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wxOIxfbyRIFC4oGtl0P0Q8bVuVGjustYcqYWND5GS9M=; b=EXIxA8z1F3509fxSn9YtpA8BFU0JrXttv5/JvXxOlOkq0JH06tBYkqViY+WzWdNkuM KuH89zKZEPV1ht+nW0lRw8fMMBGtzK2502yBR5ewZWEeN1qLMldeI9rDV5tnJdVEqJ+K w0tEMpSWGcKjhPIGy3BUXzN8uChrPe1Gpl8e455qARNA1RZKUZGAafu6cMZ35yjXGg1/ ceozsOrEgSDH7IJ00/EV/nul6W8oSxLqRm5BqG2Igf+7Lpg4Qselu9gQZRTyz4mA+LKN mwaIdb+UETpgJ0sPR71Hfj/uOix990l740/3tm+zDPmYmmMBlPNWrbSgAsVasBqxO5n8 IxrQ== X-Gm-Message-State: ALoCoQktzsceohc9el8oPQ/5Y5F+6Y4nSv8yx5jdkGNrGXWyUYmF6qeLqrL7ErYKNzDC+JFanEED X-Received: by 10.107.170.162 with SMTP id g34mr17372117ioj.2.1418143793570; Tue, 09 Dec 2014 08:49:53 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id w6sm5712705igp.15.2014.12.09.08.49.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Dec 2014 08:49:53 -0800 (PST) Message-ID: <54872804.9090700@bbs.darktech.org> Date: Tue, 09 Dec 2014 11:49:08 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7aWBTTMoauLWmZ_X66W9P7JfEDM Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 16:50:07 -0000 Hi Harald, I am in favor of the compromise as presented by the chair. (I also second Victor Pascual Avila's suggestion to revisit this decision for browsers as well as non-browsers in the future should anything of substance change.) Gili On 09/12/2014 4:44 AM, Harald Alvestrand wrote: > I note that the "confirming sense of the room" thread has gotten a lot > of messages that are not declaring a position on the question. > > I also note that from the messages on the thread, I can't figure out if > Keith Drage, Gili, Monty Montgomery or Peter Saint-Andre have taken a > position (I could guess, but I don't want to - besides, they might not > want to take a position, which is perfectly OK). > > It would be nice for me as a reader if people could: > > - state their position on the "confirming sense of the room" thread > - change the subject line when they want to say anything else > > That's my preference - of course, people who have "mute thread" in their > email readers might want the whole discussion to stay on thread, and > will hate me for the last suggestion.... > > Harald > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Dec 9 08:57:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313401A894F for ; Tue, 9 Dec 2014 08:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVloNCha9s0v for ; Tue, 9 Dec 2014 08:57:26 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0DD1A6F03 for ; Tue, 9 Dec 2014 08:57:26 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 25AA0C94BE; Tue, 9 Dec 2014 11:57:19 -0500 (EST) Date: Tue, 9 Dec 2014 11:57:19 -0500 From: John Leslie To: Victor Pascual Avila Message-ID: <20141209165719.GD47023@verdi> References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <9F33F40F6F2CD847824537F3C4E37DDF1E638036@MCHP04MSX.global-ad.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jZ_evhCBvxeC51VBDurjFqlQz3s Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 16:57:29 -0000 Victor Pascual Avila wrote: > > Current text: "To promote the use of non-royalty bearing video codecs, > > participants in the RTCWEB working group, and any successor > working groups in the IETF, intend to monitor the evolving > licensing landscape as it pertains to the two mandatory-to- > implement codecs. If compelling evidence arises that one of the > codecs is available for use on a royalty-free basis, the working > group plans to revisit the question of which codecs are required > for Non-Browsers, with the intention being that the royalty-free > codec will remain mandatory to implement, and the other will > become optional. > > These provisions apply to WebRTC Non-Browsers only. There is no > plan to revisit the codecs required for WebRTC Browsers." This indeed is quite close to what I remember hearing. But the WGC calling consensus is the person who should post it. Indeed, I am unable to correctly respond to the consensus-call without seeing the entire text in question. (It's obvious that many people posting don't share a single belief of what text they're agreeing or not agreeing to.) -- John Leslie From nobody Tue Dec 9 09:12:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864331A1A83 for ; Tue, 9 Dec 2014 09:12:43 -0800 (PST) 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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9eGcAhnnak1 for ; Tue, 9 Dec 2014 09:12:41 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F7F1A1A0B for ; Tue, 9 Dec 2014 09:12:40 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 0394A2DC35A for ; Tue, 9 Dec 2014 18:12:39 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D3CEA27C0F9 for ; Tue, 9 Dec 2014 18:12:38 +0100 (CET) Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Tue, 9 Dec 2014 18:12:38 +0100 From: To: "'rtcweb@ietf.org'" Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEJCGNHB/i7pqT0agQOt9XFm8VZyHgkSQ Date: Tue, 9 Dec 2014 17:12:38 +0000 Message-ID: <3654_1418145158_54872D86_3654_4024_1_2842AD9A45C83B44B57635FD4831E60A0C20EA1B@PEXCVZYM14.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.9.150619 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eRrsV-gkBQK-QeSxRr_-Hs0pAr4 Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 17:12:43 -0000 I support the rough consensus as declared by the Chair:=20 There is no more "no decision" option and all the work done on this topic a= nd the time and effort spent to achieve this result show there is no more a= ny other possible option. -----Message d'origine----- De=A0: rtcweb [mailto:rtcweb-bounces@ietf.org] De la part de Sean Turner Envoy=E9=A0: vendredi 5 d=E9cembre 2014 14:37 =C0=A0: rtcweb@ietf.org Objet=A0: [rtcweb] confirming sense of the room: mti codec All, At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about co= decs, which I dubbed "the great codec compromise." The compromise text tha= t was discussed appears in slides 12-14 at [4] (which is a slight editorial= variation of the text proposed at [2]). This message serves to confirm the sense of the room. In the room, I heard the following objections and responses (and I'm paraph= rasing here), which I'll take the liberty of categorizing as IPR, Time, and= Trigger: 1) IPR: Objections: There are still IPR concerns which may restrict what a particul= ar organization feels comfortable with including in their browser implement= ations. Response: IPR concerns on this topic are well known. There is even a draf= t summarizing the current IPR status for VP8: draft-benham-rtcweb-vp8litiga= tion. The sense of the room was still that adopting the compromise text wa= s appropriate. 2) Time: 2.1) Time to consider decision: Objection: The decision to consider the compromise proposal at this meeting= was provided on short notice and did not provide some the opportunity to a= ttend in person. Response: Six months ago the chairs made it clear discussion would be revi= sited @ IETF 91 [0]. The first agenda proposal for the WG included this top= ic [1], and the topic was never removed by the chairs. More importantly,= all decisions are confirmed on list; in person attendance is not required = to be part of the process. 2.2) Time to consider text: Objection: The proposed text [2] is too new to be considered. Response: The requirement for browsers to support both VP8 and H.264 was am= ong the options in the straw poll conducted more than six months ago. All = decisions are confirmed on list so there will be ample time to discuss the = proposal. 3) Trigger: Objection: The "trigger" sentence [3] is all kinds of wrong because it's pr= omising that the future IETF will update this specification. Response: Like any IETF proposal, an RFC that documents the current proposa= l can be changed through the consensus process at any other time. After the discussion, some clarifying questions about the hums, and typing = the hum questions on the screen, there was rough consensus in the room to a= dd (aka "shove") the proposed text into draft-ietf-rtcweb-video. In keepin= g with IETF process, I am confirming this consensus call on the list. If anyone has any other issues that they would like to raise please do by D= ecember 19th. Cheers, spt (as chair) [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html [3] The one that begins with "If compelling evidence ..." [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Dec 9 09:28:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0071A1A28 for ; Tue, 9 Dec 2014 09:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, GUARANTEED_100_PERCENT=2.699, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ9IA5D0wGXl for ; Tue, 9 Dec 2014 09:28:21 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16FA1A07BD for ; Tue, 9 Dec 2014 09:28:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418146100; x=2282059700; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aNeNiEqbYRTJcvOejuPFNIGBaYxHAgrbApAGXuBuqv0=; b=p+a3L3OsNjw4+QKa4pWIEtEISxy+POouhBGRJEklDsjYDaWPAq/qY3Pqt8idjLLF KM08y18NopkZMqE3fZioNJZ1/ydeTrQQ9AReVtWjOWFYXKM1VNu2HZU4sqGxYLyj XU4yE2d6tsFkwLwGw47oUvDlzHz+lABaG5+aw5CODt6WR9MOqCNWZqTQv3NgveF2 0LEarNunHL1tbR6HhjajK+N01oDysL8hgeCb4pcCUE6HLrXnLSUX4HZA/odaNUtG 3TWv0KDIHEVZ+ArHNEiDrbtPxcZJ/r+Ba4meEVZE39Pn/vbVooD6wF1evGCWSB2x 7VS5KMjtKasUwSQL+9z6eg==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 34.DD.06819.43137845; Tue, 9 Dec 2014 09:28:20 -0800 (PST) X-AuditID: 11973e13-f79656d000001aa3-52-5487313460a0 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 77.30.05439.A3137845; Tue, 9 Dec 2014 09:28:26 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGB0084PSJ7WX30@marigold.apple.com> for rtcweb@ietf.org; Tue, 09 Dec 2014 09:28:20 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: Date: Tue, 09 Dec 2014 09:28:19 -0800 Content-transfer-encoding: quoted-printable Message-id: <8FB76A79-5BCD-4A94-B3B7-C835625AA735@apple.com> References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> To: "Cavigioli, Chris" X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUi2FAYrGti2B5icP2HqMXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKaPnayVbwWL1i8a57bA2M1+W7GDk5JARMJFaffcYIYYtJXLi3 nq2LkYtDSGAvo8S31WtZuhg5wIrmTq+HiE9ikrjafZkZpEFIYD6TxJRluSA1zALqElOm5IKE eQX0JJqePGYCCQsL2EpsvR4EEmYTUJV4MOcY2CpOgTCJ/0ubWUFsFqD4+c1/wOIgU5ZObmCD sLUlnry7wAox0kbi54uVUKc1MEm07mwFaxARMJLY8/QvC8T9shL/Lp5hBymSEHjLKjFpej/z BEbhWQjnzUJy3iwkOxYwMq9iFMpNzMzRzcwz1UssKMhJ1UvOz93ECArh6XbCOxhPr7I6xCjA wajEw6th2RYixJpYVlyZe4hRmoNFSZz3pg1QSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+P2 aTOyfm5d3eNVUl1TxGgaU1vz7qD+DPuQ5F33swuV2bi/OHU88lj3fuPi911f5jRX3LummCu4 1TthjvCHllS5N/JzpK7EaR+b/OFAUJJ7Cuvip5Hf/P82Fs3d+NhdKjA7dmeGWUS3Sou7sQ6X Iz9rgM/qa0ufnTXzuDn9+vZik19CTCmu+5VYijMSDbWYi4oTAXTiyWdCAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUi2FDcomtl2B5icOKtoMXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKaPnayVbwWL1i8a57bA2M1+W7GDk4JARMJOZOr+9i5AQyxSQu 3FvP1sXIxSEkMIlJ4mr3ZWaQhJDAfCaJKctyQeqZBdQlpkzJBQnzCuhJND15zAQSFhawldh6 PQgkzCagKvFgzjFGEJtTIEzi/9JmVhCbBSh+fvMfsDjIlKWTG9ggbG2JJ+8usEKMtJH4+WIl 1AkNTBKtO1vBGkQEjCT2PP3LAnGnrMS/i2fYJzAKzEK4aBaSi2YhGbuAkXkVo0BRak5ipbFe YkFBTqpecn7uJkZwyBUG72D8s8zqEKMAB6MSD6+GZVuIEGtiWXFl7iFGCQ5mJRHetSztIUK8 KYmVValF+fFFpTmpxYcYpTlYlMR5K941hggJpCeWpGanphakFsFkmTg4pRoYxZdIlssn36ly rFHdsGz6vfndUzZNa+n8v7+F+cbWv29mn9M7qquftT+gV3LLZ2mbPQZJf28Hx1iU32RjXJSu va39h4yijKrUnqyEAI+F8UYbl8fdVVTbdkt6jckBTucbwjOD78pPMYphStjTnnXszuX4G9nC cZluW6QuXE3eu+zltEa7eon/SizFGYmGWsxFxYkA6Sa3TTUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dmaXVhQY1OckeFPgE4WiA9BVvMs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 17:28:22 -0000 > On Dec 8, 2014, at 15:53 , Cavigioli, Chris = wrote: >=20 > I agree with Maire=E2=80=99s sentiments. Let's *please* not re-open = this endless discussion. It is tedious and tiring. We achieved a = consensus decision, and it doesn=E2=80=99t have to be unanimous. = Let=E2=80=99s declare victory for WebRTC and move on. Because (a) we didn=E2=80=99t; there was a tentative direction selected = by the room and (b) it=E2=80=99s not a victory, not even for interop. > Here are 3 things that will never be decided 100% unanimously. Some = things just cannot be.=20 > 1. Electing a president to lead a nation=20 > 2. Deciding on codecs in a standards body > 3. Solving the Israel - Palestine conflict > I propose we work together as global citizens, move forward, get = things done, =E2=80=A6 That would be great. > -chris > =20 > P.S. I think we have all realized that there is no such thing as a = 100% guaranteed RF codec, especially one that is performant. Even ones = that are declared as RF can always be argued in court=E2=80=A6 > =20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Andrew = Allen > Sent: Monday, December 08, 2014 3:29 PM > To: Maire Reavy; rtcweb@ietf.org > Subject: Re: [rtcweb] confirming sense of the room: mti codec > =20 > We are not re-opening this discussion. This list discussion is the = decision making process. > =20 > What took place in Honolulu was only a consensus hum of those present = in the room. > =20 > In IETF all decisions are made on the list and it was clearly stated = by the chair in Honolulu that the decision would need to be endorsed on = the list. > =20 > On 1) We have committed to an MTI video codec > =20 > I note the small word "an". > =20 > If we decide on two MTI video codecs then we have clearly failed to = meet this commitment. > =20 > On 3) This is the only proposal that gets support from both camps > =20 > As David pointed out we are not in two monolithic camps (this isn't = the cold war here). Different companies and different individuals have = different positions for different reasons. The fact that some people who = might have been perceived as being in "one camp" have found a way to = agree to a "compromise" based upon a definition that doesn't force them = in their product to implement what they don't agree to implement does = not mean that the fundamental reason behind the difficulty in reaching = consensus on MTI video codecs by those whose products would be forced to = implement both codecs has changed. > =20 > It's very easy to agree to someone else to have to do something that = you are not willing to do yourself. > =20 > Andrew > =20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Maire Reavy > Sent: Monday, December 08, 2014 4:41 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] confirming sense of the room: mti codec > =20 > On 12/5/2014 2:58 PM, Jean-Marc Valin wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > >=20 > > Considering that: > > 1) We have committed to an MTI video codec > > 2) All consensus calls on "VP8 only" and "H.264 only" have failed > > 3) This is the only proposal that gets support from both camps I > > strongly support this MTI proposal. > > Please, let's close this debate once and for all. This compromise is > > by no means great, but it's much better than anything else we're = going > > to get otherwise (i.e. more wasted time and still no MTI). > A big +1 > =20 > We have spent *so* many hours already considering, discussing, & = debating what to do about the MTI video codec. One could argue an = "insane amount" of time relative to the other issues we need to resolve. = We did this because most of us realized that "no MTI" could be horrific = for the standard. We should embrace consensus around anything less than = horrific, and most of us agree that this compromise is less than = horrific (not great, but less than horrific). > =20 > Right now I fear we're on the verge of shooting ourselves in the foot = or head (I'm not sure which) by reopening this discussion even though = we're in sight of the end. I ask that the working group and the chairs = put the proverbially safety back on the gun, declare consensus on this = less-than-horrific proposal, and finish our work on "v1.0" of the spec. > =20 > Please. > =20 > -Maire > ------------------------- > Maire Reavy > mdr@reavy.org > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > =20 > _______________________________________________ > 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 David Singer Manager, Software Standards, Apple Inc. From nobody Tue Dec 9 09:32:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AB11A89AD for ; Tue, 9 Dec 2014 09:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EKMzmoVg6UF for ; Tue, 9 Dec 2014 09:32:47 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA321A899C for ; Tue, 9 Dec 2014 09:32:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418146367; x=2282059967; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8/eb52QoGZS07j6xMxu/3TqNo4QpFptefvLzVssA6f8=; b=GnHYfnadGwMtamUfIImf4ruR9MedZEztTpZtjBFI0PHvBWnin623yz/2pLVu+O9+ oELgumrn/nWNckiQmZ1Vd6JSQLOsz5oZiMkrCylk2RasVNoeA4bBtYyv8r3ld6cx hMI9fddZVS28NIUtvZdG+sPL0EsUhTGwXZJBIe1uMDc43Yn1qwGHpihi3liZSEvB rY3tCZnnPKhy4uTbCasQcaCFo2RnhQLQ/05obNSCBY44LJ8QWiIS/FSt7tdL/ya4 w8ctBR3XjcpM/pR41hqIsCZ7mu6MkcV/kLpXWO+8Bz8hl+gk7ypgz+i3z8GcdCFk 78FxL+ht5PLi4+8zoeA03g==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id D6.42.12074.F3237845; Tue, 9 Dec 2014 09:32:47 -0800 (PST) X-AuditID: 11973e12-f79f86d000002f2a-fe-5487323fe76c Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 28.2C.06123.04237845; Tue, 9 Dec 2014 09:32:48 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGB008C6SQMWX30@marigold.apple.com> for rtcweb@ietf.org; Tue, 09 Dec 2014 09:32:46 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <5486C48D.8040602@alvestrand.no> Date: Tue, 09 Dec 2014 09:32:46 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <5486C48D.8040602@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUi2FAYoWtv1B5isOEFk8Xaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKWD33FFPBc66K+02TGRsYj3F0MXJySAiYSMx4upINwhaTuHBv PZDNxSEksJdR4lzzNpYuRg6wop9P+SHik5gkenpaGCGc+UwSze+nM4EUMQuoS0yZkgsyiFdA T6LpyWMmEFtYwFxiY9cRZhCbTUBV4sGcY4wgNqeArsT5L/PZQWwWoPi2iS1g9SBjlk5uYIOw tSWevLvACjHTRuLVh5lg9UICOhJnly8FqxcBsh/ub2CCeEBW4t/FM+wgt0kIvGWVuP95FusE RuFZCOfNQnLeLCQrFjAyr2IUyk3MzNHNzDPRSywoyEnVS87P3cQICuLpdkI7GE+tsjrEKMDB qMTDq2HZFiLEmlhWXJl7iFGag0VJnPemDVBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo/vv qOysd5zz5v3XPhWVZP2XIZqTeUHlti3hfk/D/unEWoZonhThfLSw7jlLxEO1/58C29Uyuto0 a701G5V4Ft9x0opWsara2p4zI5FtSZn5pU2blup+2iRvcfrVdvEpPPeX8V1XaXh+Lft1gdIn X2+lP4+X3goXVTbYfd3y5K4rFSt3Bu13UGIpzkg01GIuKk4EAMeU66lDAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FDcoutg1B5isOCAmcXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKWD33FFPBc66K+02TGRsYj3F0MXJwSAiYSPx8yt/FyAlkiklc uLeerYuRi0NIYBKTRE9PCyOEM59Jovn9dCaQBmYBdYkpU3JBGngF9CSanjxmArGFBcwlNnYd YQax2QRUJR7MOcYIYnMK6Eqc/zKfHcRmAYpvm9gCVg8yZunkBjYIW1viybsLrBAzbSRefZgJ Vi8koCNxdvlSsHoRIPvh/gYmiENlJf5dPMM+gVFgFsJFs5BcNAvJ1AWMzKsYBYpScxIrTfUS CwpyUvWS83M3MYKDrjBiB+P/ZVaHGAU4GJV4eDUs20KEWBPLiitzDzFKcDArifCuZWkPEeJN SaysSi3Kjy8qzUktPsQozcGiJM5b8q4xREggPbEkNTs1tSC1CCbLxMEp1cA4ZVH19DXSB3PE xS9o5WYGNj/TfLnq8TrvKt9S/apcH+l90w/2yBy1+ewo4MFj/es3Q9qZso+hRxcZFuVVPtt0 eNvCrWqtm3MbGmzE9qfpfxR7a/rnxouo96Xvtl5zvv5b8Lv3mk5VwTvmjeucTr1JaLm8/uvX PtkiZdYDN6QbzcVnuy9T46pTYinOSDTUYi4qTgQAS2nf/jYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EyRzPLWQ3XD3KdCqUqnhdsknXBQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 17:32:49 -0000 > On Dec 9, 2014, at 1:44 , Harald Alvestrand = wrote: >=20 > I note that the "confirming sense of the room" thread has gotten a lot > of messages that are not declaring a position on the question. >=20 > I also note that from the messages on the thread, I can't figure out = if > Keith Drage, Gili, Monty Montgomery or Peter Saint-Andre have taken a > position (I could guess, but I don't want to - besides, they might not > want to take a position, which is perfectly OK). >=20 > It would be nice for me as a reader if people could: >=20 > - state their position on the "confirming sense of the room" thread > - change the subject line when they want to say anything else >=20 > That's my preference - of course, people who have "mute thread" in = their > email readers might want the whole discussion to stay on thread, and > will hate me for the last suggestion.... >=20 > Harald Thanks, Harald, that would help. I would also like to know from those confirming the sense of the room, = whether THEY THEMSELVES intend to implement both codecs, or whether they = conveniently think they don=E2=80=99t need to, and it=E2=80=99s just a = problem for other people to handle. Honestly, a +1 for =E2=80=9Cthose other people should do it=E2=80=9D is = meaningless. =20 David Singer Manager, Software Standards, Apple Inc. From nobody Tue Dec 9 09:36:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0571E1A8A0E for ; Tue, 9 Dec 2014 09:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EK72IjPO0AB for ; Tue, 9 Dec 2014 09:36:42 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDC81A8973 for ; Tue, 9 Dec 2014 09:36:42 -0800 (PST) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 09 Dec 2014 12:36:38 -0500 Received: from XCT113CNC.rim.net (10.65.161.213) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.210.2; Tue, 9 Dec 2014 12:36:36 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT113CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Tue, 9 Dec 2014 12:36:36 -0500 From: Gaelle Martin-Cocher To: David Singer , Harald Alvestrand Thread-Topic: [rtcweb] Video codecs: Clear positions.... Thread-Index: AQHQE5TJNpSyqVzPpUy8iOzGO3iX/ZyH2PIA//+smSA= Date: Tue, 9 Dec 2014 17:36:36 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF35D371@XMB111CNC.rim.net> References: <5486C48D.8040602@alvestrand.no> In-Reply-To: Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/as4G8kM-dcb28nSRgG94wtTmcIQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 17:36:44 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhdmlkIFNpbmdlcg0KU2VudDogVHVl c2RheSwgRGVjZW1iZXIgMDksIDIwMTQgMTI6MzMgUE0NClRvOiBIYXJhbGQgQWx2ZXN0cmFuZA0K Q2M6IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFZpZGVvIGNvZGVjczog Q2xlYXIgcG9zaXRpb25zLi4uLg0KDQouLi4NCg0KSSB3b3VsZCBhbHNvIGxpa2UgdG8ga25vdyBm cm9tIHRob3NlIGNvbmZpcm1pbmcgdGhlIHNlbnNlIG9mIHRoZSByb29tLCB3aGV0aGVyIFRIRVkg VEhFTVNFTFZFUyBpbnRlbmQgdG8gaW1wbGVtZW50IGJvdGggY29kZWNzLCBvciB3aGV0aGVyIHRo ZXkgY29udmVuaWVudGx5IHRoaW5rIHRoZXkgZG9u4oCZdCBuZWVkIHRvLCBhbmQgaXTigJlzIGp1 c3QgYSBwcm9ibGVtIGZvciBvdGhlciBwZW9wbGUgdG8gaGFuZGxlLg0KDQpIb25lc3RseSwgYSAr MSBmb3Ig4oCcdGhvc2Ugb3RoZXIgcGVvcGxlIHNob3VsZCBkbyBpdOKAnSBpcyBtZWFuaW5nbGVz cy4gIA0KDQoNCltHTUNdIFZlcnkgbXVjaCBhZ3JlZS4gQW5kIGFsc28gY2xhcmlmeWluZyBpbiB3 aGljaCBjYXRlZ29yeSB0aGV5IGJlbG9uZy4uLi4gYnJvd3Nlciwgbm9uIGJyb3dzZXIsIGNvbXBh dGlibGUgZW5kcG9pbnQuDQoNCg0KDQo= From nobody Tue Dec 9 09:37:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E8E1A8A1E for ; Tue, 9 Dec 2014 09:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOLL77_jnx9A for ; Tue, 9 Dec 2014 09:37:34 -0800 (PST) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93761A8A0B for ; Tue, 9 Dec 2014 09:37:33 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id y20so970970ier.32 for ; Tue, 09 Dec 2014 09:37:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BnjBVhk9bTYUJcMErasyA+KZlKxGVyTDUzi6kiBZwQo=; b=XnOongNjX4SUPwTejnUatXUqzdAfHeHTMGdZlIyeRnxQW28mAFvw8XJsbxEKygQi+B nJuGZq8AdLt8xPc79IIDJcVG4WFxLENPaKUvURremA075K19rzLRTn6CD4PbzPXZi3nO Egwbe3pnOHmIs9AIHRdaZnin+zQCLZzFRx2ln4eCfzaGEz9PcTds4BfsKN/uoRrXEjcg 5x3EHTfJ9GU9f1rgCO/CWlZFTyHOXrUqnY2jR5+QzYbwHN66uooxnl3z6rrCifBUwsqu Yf1CNt0gVNPo4RAnztbFZAS7OkGT+/H93d8+TK/5Bb00pGFf7NKM2264RE50igE6B90k Vq/A== X-Gm-Message-State: ALoCoQkt8i2EgiTB96UoOYUfP7TozqeC3qvoLEs/GNmlkfDR5edj7PfTtmVUQc2vTljtp68dKnLa X-Received: by 10.107.19.9 with SMTP id b9mr17786303ioj.48.1418146653226; Tue, 09 Dec 2014 09:37:33 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id g139sm841499iog.41.2014.12.09.09.37.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Dec 2014 09:37:32 -0800 (PST) Message-ID: <5487331F.8050404@bbs.darktech.org> Date: Tue, 09 Dec 2014 12:36:31 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5486C48D.8040602@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bZlYcaBXYki54NCfriRHZ8tbISo Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 17:37:35 -0000 On 09/12/2014 12:32 PM, David Singer wrote: >> On Dec 9, 2014, at 1:44 , Harald Alvestrand wrote: >> >> I note that the "confirming sense of the room" thread has gotten a lot >> of messages that are not declaring a position on the question. >> >> I also note that from the messages on the thread, I can't figure out if >> Keith Drage, Gili, Monty Montgomery or Peter Saint-Andre have taken a >> position (I could guess, but I don't want to - besides, they might not >> want to take a position, which is perfectly OK). >> >> It would be nice for me as a reader if people could: >> >> - state their position on the "confirming sense of the room" thread >> - change the subject line when they want to say anything else >> >> That's my preference - of course, people who have "mute thread" in their >> email readers might want the whole discussion to stay on thread, and >> will hate me for the last suggestion.... >> >> Harald > Thanks, Harald, that would help. > > I would also like to know from those confirming the sense of the room, whether THEY THEMSELVES intend to implement both codecs, or whether they conveniently think they don’t need to, and it’s just a problem for other people to handle. > > Honestly, a +1 for “those other people should do it†is meaningless. That's a fair point. I'm guessing the vast majority of people answering on the mailing list only plan to implement one codec because they are non-browser implementors. Gili From nobody Tue Dec 9 09:40:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FF11A802A for ; Tue, 9 Dec 2014 09:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPI-bJkrQmMK for ; Tue, 9 Dec 2014 09:40:26 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842B61A047A for ; Tue, 9 Dec 2014 09:40:25 -0800 (PST) Received: (qmail 78117 invoked from network); 9 Dec 2014 17:40:24 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 12777 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 9 Dec 2014 17:40:24 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 6A7AE18A0FEE; Tue, 9 Dec 2014 17:40:18 +0000 (GMT) Received: from [192.168.157.34] (unknown [192.67.4.66]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 4DDFA18A0E0B; Tue, 9 Dec 2014 17:40:18 +0000 (GMT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: tim panton In-Reply-To: Date: Tue, 9 Dec 2014 17:40:17 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5486C48D.8040602@alvestrand.no> To: David Singer X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AC2KUx7J_qjVK8gHfbat-9RW9u0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 17:40:27 -0000 > On 9 Dec 2014, at 17:32, David Singer wrote: >=20 > Honestly, a +1 for =E2=80=9Cthose other people should do it=E2=80=9D = is meaningless. =20 That=E2=80=99s dangerous logic if you work for a company that won=E2=80=99= t say it will implement or use rtcweb in any form at all,=20 I could use it to say that your views are meaningless in this matter ;-) From nobody Tue Dec 9 09:44:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F5D1A6F05 for ; Tue, 9 Dec 2014 09:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3Dj_AeDKy44 for ; Tue, 9 Dec 2014 09:44:08 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900F41A8A40 for ; Tue, 9 Dec 2014 09:44:07 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id 10so943918lbg.33 for ; Tue, 09 Dec 2014 09:44:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kX0Gm8/yqD/aDbVuemkOk4i4WHkZxgkJjRUNtJwvqWk=; b=WGT13HEr3PW6EhPwZk9F834LHs0GkjImEQ7mhB7dpjjC/lz0ylQuun6aS4mN+sR35d PlU7ANL2tCwF7cXh/8iSyI3PSluz91PCiRTxMTwY7wQy7DuQaiwxz8AUTHKCnnZRADhm lWEIHFnTv4KrEyLbP2InibLgp5qCYJg/m/P/qS9kZ5jo/+DWFxQZjG5WZBZvmcvcln7H oa0Kp/+68GmuNeh9x+DU5L1CYsx2LJA7C+Ptdddodc2uLfpR1VHmO94i2iY+1dwIkIds oQFt9fiutd6fRNNLbSILqsG6ei7IBEKrICsgZFYwJE0zeHkxQQ0xI91Cw8r0NTz7oBYN +hbg== X-Gm-Message-State: ALoCoQmFFKB6MI/n5LV+uLJSkhJNbxamVGhRSoTUPpllLn/O40gGoORX8v2AshQ5zwj0UU+QRt1W MIME-Version: 1.0 X-Received: by 10.152.2.74 with SMTP id 10mr22836348las.38.1418147045742; Tue, 09 Dec 2014 09:44:05 -0800 (PST) Received: by 10.25.84.145 with HTTP; Tue, 9 Dec 2014 09:44:05 -0800 (PST) In-Reply-To: <5487331F.8050404@bbs.darktech.org> References: <5486C48D.8040602@alvestrand.no> <5487331F.8050404@bbs.darktech.org> Date: Tue, 9 Dec 2014 10:44:05 -0700 Message-ID: From: Simon Perreault To: cowwoc Content-Type: multipart/alternative; boundary=089e01228e5ae6b2c50509cc1602 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_DFu8rPlhn-KRLfureDfFtFg_X0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 17:44:09 -0000 --089e01228e5ae6b2c50509cc1602 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 9, 2014 at 10:36 AM, cowwoc wrote: > I would also like to know from those confirming the sense of the room, >> whether THEY THEMSELVES intend to implement both codecs, or whether they >> conveniently think they don=E2=80=99t need to, and it=E2=80=99s just a p= roblem for other >> people to handle. >> >> Honestly, a +1 for =E2=80=9Cthose other people should do it=E2=80=9D is = meaningless. >> > > That's a fair point. I'm guessing the vast majority of people answering o= n > the mailing list only plan to implement one codec because they are > non-browser implementors. FWIW, I'm planning on implementing both and, believe me or not, I'm not writing a browser. Simon --089e01228e5ae6b2c50509cc1602 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Dec 9, 2014 at 10:36 AM, cowwoc <cowwoc@bbs.darktech.org= > wrote:
I would also like to know from those confirming t= he sense of the room, whether THEY THEMSELVES intend to implement both code= cs, or whether they conveniently think they don=E2=80=99t need to, and it= =E2=80=99s just a problem for other people to handle.

Honestly, a +1 for =E2=80=9Cthose other people should do it=E2=80=9D is mea= ningless.

That's a fair point. I'm guessing the vast majority of people answe= ring on the mailing list only plan to implement one codec because they are = non-browser implementors.

FWIW, I'm planning on i= mplementing both and, believe me or not, I'm not writing a browser.

Simon
--089e01228e5ae6b2c50509cc1602-- From nobody Tue Dec 9 09:45:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E151A1DFA for ; Tue, 9 Dec 2014 09:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Wx_5Kckd2kF for ; Tue, 9 Dec 2014 09:45:45 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E77ED1A1A07 for ; Tue, 9 Dec 2014 09:45:44 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id r20so8700533wiv.6 for ; Tue, 09 Dec 2014 09:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=JQlEHz0cdySd5uFg0lEQzBLP53jMjoneuWvhFzmklyw=; b=qcXuXTjhURm/kE3RUW+3MupfArwoAnkrpuTbubLe6o/bDA3r53Wsf4b8ZWvdi78X2N vIsR/p2DkVrVIZxLEaZG+Q4CELAsQ1q7py/kcmiTZRIJSB0j3AR8zYkSUY6odFtA6gL+ JoRt1STxSfIoyDL0FuJwlo6Lz9e11QKbKJ0SDsCQLKEW4wJ6mxGDU6znV7BnQbptfg5u xnpNfWDyfjMPbRPMXuW/maftfzBJa2OS7vxMdVkM6GjDyA2mI4U3+1dvvNMEvGa93oTX a/xYR/udH70zppddEQqEtjvpRBGb9jJtlLOsY2d2v0nbpJYOGGWRvmzlrSa5bldvGtLG u7wA== X-Received: by 10.180.84.198 with SMTP id b6mr34552241wiz.41.1418147135365; Tue, 09 Dec 2014 09:45:35 -0800 (PST) Received: from [192.168.1.37] (136.Red-81-39-109.dynamicIP.rima-tde.net. [81.39.109.136]) by mx.google.com with ESMTPSA id ry19sm2653496wjb.3.2014.12.09.09.45.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Dec 2014 09:45:34 -0800 (PST) Message-ID: <5487353D.8030106@gmail.com> Date: Tue, 09 Dec 2014 18:45:33 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5486C48D.8040602@alvestrand.no> <5487331F.8050404@bbs.darktech.org> In-Reply-To: <5487331F.8050404@bbs.darktech.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/h2-pdyBP6kQq7YnbHKjV_5zCwh0 Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 17:45:46 -0000 On 09/12/2014 18:36, cowwoc wrote: > On 09/12/2014 12:32 PM, David Singer wrote: >> >> I would also like to know from those confirming the sense of the >> room, whether THEY THEMSELVES intend to implement both codecs, or >> whether they conveniently think they don’t need to, and it’s just a >> problem for other people to handle. >> >> Honestly, a +1 for “those other people should do it†is meaningless. > > That's a fair point. I'm guessing the vast majority of people > answering on the mailing list only plan to implement one codec because > they are non-browser implementors. No, that's not a fair point. I don't see most of the people making taking decisions on other topics (SDP, FEC, DTLS, CC, SVC/Simulcasting/Multicasting, Plan A/PlanB/No plan) implementing them themselves. So if this going to be the rule about who-can-vote-what we should redefine the whole IETF process. Everyone should be aware of what are they voting and what is the amount of burden/costs it requires to be implemented, and see how that will contribute to the success/failure of webrtc and vote accordingly. Not just in this topic, but in any topic. Best regards Sergio From nobody Tue Dec 9 09:46:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543A01A8A15 for ; Tue, 9 Dec 2014 09:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrFaEXSsW4cZ for ; Tue, 9 Dec 2014 09:46:31 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002-out2.apm-internet.net [85.119.248.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452F41A8A0E for ; Tue, 9 Dec 2014 09:46:31 -0800 (PST) Received: (qmail 19968 invoked from network); 9 Dec 2014 17:46:29 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 12874 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 9 Dec 2014 17:46:29 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 36E7A18A0FEE; Tue, 9 Dec 2014 17:46:26 +0000 (GMT) Received: from [192.168.157.34] (unknown [192.67.4.66]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 2545318A0CC3; Tue, 9 Dec 2014 17:46:26 +0000 (GMT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: tim panton In-Reply-To: <5487331F.8050404@bbs.darktech.org> Date: Tue, 9 Dec 2014 17:46:26 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5486C48D.8040602@alvestrand.no> <5487331F.8050404@bbs.darktech.org> To: cowwoc X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/iwxSuRc--RmAoOisQdXbhBmfywo Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 17:46:35 -0000 > On 9 Dec 2014, at 17:36, cowwoc wrote: >=20 > On 09/12/2014 12:32 PM, David Singer wrote: >>> On Dec 9, 2014, at 1:44 , Harald Alvestrand = wrote: >>>=20 >>> I note that the "confirming sense of the room" thread has gotten a = lot >>> of messages that are not declaring a position on the question. >>>=20 >>> I also note that from the messages on the thread, I can't figure out = if >>> Keith Drage, Gili, Monty Montgomery or Peter Saint-Andre have taken = a >>> position (I could guess, but I don't want to - besides, they might = not >>> want to take a position, which is perfectly OK). >>>=20 >>> It would be nice for me as a reader if people could: >>>=20 >>> - state their position on the "confirming sense of the room" thread >>> - change the subject line when they want to say anything else >>>=20 >>> That's my preference - of course, people who have "mute thread" in = their >>> email readers might want the whole discussion to stay on thread, and >>> will hate me for the last suggestion.... >>>=20 >>> Harald >> Thanks, Harald, that would help. >>=20 >> I would also like to know from those confirming the sense of the = room, whether THEY THEMSELVES intend to implement both codecs, or = whether they conveniently think they don=E2=80=99t need to, and it=E2=80=99= s just a problem for other people to handle. >>=20 >> Honestly, a +1 for =E2=80=9Cthose other people should do it=E2=80=9D = is meaningless. >=20 > That's a fair point. I'm guessing the vast majority of people = answering on the mailing list only plan to implement one codec because = they are non-browser implementors. I think you may find quite a few people here building APIs toolkits, = libraries and gateways who will want the webRTC-compatible sticker on their product or project, so will probably end up offering a = free version with VP8 support and a crazy expensive one that does both codecs. T. From nobody Tue Dec 9 09:46:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EBB1A1A07 for ; Tue, 9 Dec 2014 09:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNPPQZI2MIBB for ; Tue, 9 Dec 2014 09:46:35 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3531A8A0E for ; Tue, 9 Dec 2014 09:46:35 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB9HkUoG085763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2014 11:46:30 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54873575.3030804@nostrum.com> Date: Tue, 09 Dec 2014 11:46:29 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: David Singer , Harald Alvestrand References: <5486C48D.8040602@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vr3V1W6ZdrR9kFE0JjCpTm6NHb4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 17:46:39 -0000 On 12/9/14 11:32, David Singer wrote: > I would also like to know from those confirming the sense of the room, whether THEY THEMSELVES intend to... Wait, you're pressing other companies for future product plans? With the implication that doing so is a prerequisite to participating in the discussion? That's a mighty sharp blade there. You might check where it's pointed. /a From nobody Tue Dec 9 09:47:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A51D1A8A54 for ; Tue, 9 Dec 2014 09:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0404igaKNY2 for ; Tue, 9 Dec 2014 09:47:00 -0800 (PST) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5517F1A8A4B for ; Tue, 9 Dec 2014 09:47:00 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id hq12so513986vcb.41 for ; Tue, 09 Dec 2014 09:46:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rlSJiGK4JCFdKmCN8yRj/7JuCAYn+pX+qD8WQSAH/oM=; b=HKoO7J7DVqbGXx4CIKOUVjTAW6Ca24zzCiT9cKMas3g77jPPj2/lcLEs+3oZoNvdvH tQqOjTnRkEUZDsTyryK41gsDivD+KbH5A8fV2SR3mV8uso0/zh/hHCqI5exTITGM4lpD uvbSpjwHu/BFzg0CLBKBtcuwgXJPGHVoihFzzW6dzrBDutc9l42zI+DlqqItduWKCHmp rL1Lz2yDPEN6OcjwZDb2SEC+2rx2/eqxna60adwb2jF6imZwvOynxGiSsR1/oZB2TTGT c/kmmfkKfCxdPOIgVu0EQwf+skU2zJ7CEhPSFiIeo07s4Mdu27pnD7rUwRCDMgdQVcFQ pTLw== X-Gm-Message-State: ALoCoQnFu5kYzT97ZhD/dk1amp6bI0qcuwALNRNPFFwiJn+vabz764PYSucA2ljzSyf8fErXklUJ MIME-Version: 1.0 X-Received: by 10.220.165.130 with SMTP id i2mr1765630vcy.7.1418147219499; Tue, 09 Dec 2014 09:46:59 -0800 (PST) Received: by 10.52.75.66 with HTTP; Tue, 9 Dec 2014 09:46:59 -0800 (PST) In-Reply-To: <5487353D.8030106@gmail.com> References: <5486C48D.8040602@alvestrand.no> <5487331F.8050404@bbs.darktech.org> <5487353D.8030106@gmail.com> Date: Tue, 9 Dec 2014 09:46:59 -0800 Message-ID: From: Gustavo Garcia To: Sergio Garcia Murillo Content-Type: multipart/alternative; boundary=089e0158a8ee41fc300509cc2160 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/w09DfNnFIi2nvr3U0okjUuolwIg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 17:47:02 -0000 --089e0158a8ee41fc300509cc2160 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We are planning on implementing both and we are not writing a browser either. On Tue, Dec 9, 2014 at 9:45 AM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > On 09/12/2014 18:36, cowwoc wrote: > >> On 09/12/2014 12:32 PM, David Singer wrote: >> >>> >>> I would also like to know from those confirming the sense of the room, >>> whether THEY THEMSELVES intend to implement both codecs, or whether the= y >>> conveniently think they don=E2=80=99t need to, and it=E2=80=99s just a = problem for other >>> people to handle. >>> >>> Honestly, a +1 for =E2=80=9Cthose other people should do it=E2=80=9D is= meaningless. >>> >> >> That's a fair point. I'm guessing the vast majority of people answering >> on the mailing list only plan to implement one codec because they are >> non-browser implementors. >> > > No, that's not a fair point. I don't see most of the people making taking > decisions on other topics (SDP, FEC, DTLS, CC, > SVC/Simulcasting/Multicasting, Plan A/PlanB/No plan) implementing them > themselves. So if this going to be the rule about who-can-vote-what we > should redefine the whole IETF process. > > Everyone should be aware of what are they voting and what is the amount o= f > burden/costs it requires to be implemented, and see how that will > contribute to the success/failure of webrtc and vote accordingly. Not jus= t > in this topic, but in any topic. > > Best regards > Sergio > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e0158a8ee41fc300509cc2160 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We are planning on implementing both and we are not writin= g a browser either.

On Tue, Dec 9, 2014 at 9:45 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 09/12/2014 18:36, cowwoc wrote:
On 09/12/2014 12:32 PM, David Singer wrote:

I would also like to know from those confirming the sense of the room, whet= her THEY THEMSELVES intend to implement both codecs, or whether they conven= iently think they don=E2=80=99t need to, and it=E2=80=99s just a problem fo= r other people to handle.

Honestly, a +1 for =E2=80=9Cthose other people should do it=E2=80=9D is mea= ningless.

That's a fair point. I'm guessing the vast majority of people answe= ring on the mailing list only plan to implement one codec because they are = non-browser implementors.

No, that's not a fair point. I don't see most of the people making = taking decisions on other topics (SDP, FEC,=C2=A0 DTLS, CC, SVC/Simulcastin= g/Multicasting, Plan A/PlanB/No plan) implementing them themselves. So if t= his going to be the rule about who-can-vote-what we should redefine the who= le IETF process.

Everyone should be aware of what are they voting and what is the amount of = burden/costs it requires to be implemented, and see how that will contribut= e to the success/failure of webrtc and vote accordingly. Not just in this t= opic, but in any topic.

Best regards
Sergio


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--089e0158a8ee41fc300509cc2160-- From nobody Tue Dec 9 09:52:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BA11A6FB2 for ; Tue, 9 Dec 2014 09:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoKPICZAn4K8 for ; Tue, 9 Dec 2014 09:52:06 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8150D1A6F05 for ; Tue, 9 Dec 2014 09:52:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5055; q=dns/txt; s=iport; t=1418147526; x=1419357126; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=X3AMDOnzpw3PviY6ZGkk3ji9upbGjU4qiYBYjkCTf8M=; b=SdYsx13xaS1AinHiyRy4lAnKtnnUH68sFvyWUU5LWQFfs6FpXEoTPmkv /U0SYOTNIpbAuXynbp7I05cTUqve5FMtTz46+QM4h8nmBxFeygYQhmlN7 yFuC9z+CsKtC80d0IBiDmhGYKT0ICOcJCBfBp75SA2JXX2O7Al8DbW6Ni U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAKI1h1StJA2I/2dsb2JhbABZgmQiUlMFBMYUCoU7TgKBJhYBAQEBAX2EAgEBAQMBAQEBNzQLBQcEAgEIEQMBAQEBHgkHJwsUCQgCBAENBQmIJwgBBwXXLQEBAQEBAQEBAQEBAQEBAQEBAQEBAReQCTMHBoMbgRUFjg2DWYU8gQ0wgi+NfoNub4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208";a="104109503" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP; 09 Dec 2014 17:52:00 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sB9Hpxw6004774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 17:51:59 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 11:51:59 -0600 From: "Cullen Jennings (fluffy)" To: "Ram Mohan R (rmohanr)" , Muthu Arul Mozhi Perumal Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-09.txt Thread-Index: AQHQE9jU0vJXZQkohUyeIW2z3CyTiw== Date: Tue, 9 Dec 2014 17:51:59 +0000 Message-ID: <623E627F-B1DA-4844-B141-D705804A4BEB@cisco.com> References: <20141204174709.26945.65249.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D57C013@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8B28D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B28D5F4@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <4E4AAC3DB771724A9299FB09FD26DE4F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/c9IyKvPerh3ZyWMKJpXJX2zS-so Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-09.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 17:52:09 -0000 Just issue a -10 and the -09 will be left behind.... Cullen (with a chair hat on) > On Dec 5, 2014, at 4:09 AM, DRAGE, Keith (Keith) wrote: >=20 > No - it is issued >=20 > All you can provide is the -10 >=20 > I believe the chairs may be able to place some annotations abot the -09 o= n the datatracker entry=20 >=20 > Keith >=20 >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20 >> Muthu Arul Mozhi Perumal >> Sent: 05 December 2014 11:02 >> To: Ram Mohan R (rmohanr) >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] I-D Action:=20 >> draft-ietf-rtcweb-stun-consent-freshness-09.txt >>=20 >> Does anyone know if there is a way to get -09 version removed=20 >> from the datatracker? >>=20 >> Muthu >>=20 >> On Fri, Dec 5, 2014 at 4:08 PM, Ram Mohan R (rmohanr)=20 >> wrote: >>=20 >>=20 >> Sorry this is a issue w.r.t picking up a wrong version.=20 >> We had removed >> liveness in ver 8. I will check and publish the correct=20 >> revision. >> =09 >> Ram >> =09 >>=20 >> -----Original Message----- >> From: Christer Holmberg >> Date: Friday, 5 December 2014 1:52 pm >> To: Cisco Employee ,=20 >> "rtcweb@ietf.org" >> Subject: RE: [rtcweb] I-D Action: >> draft-ietf-rtcweb-stun-consent-freshness-09.txt >> =09 >> >Hi, >> > >> >I thought the idea was to remove the=20 >> liveness/heartbeat feature, but it >> >is still in the draft. >> > >> >Regards, >> > >> >Christer >> > >> >-----Original Message----- >> >From: rtcweb [mailto:rtcweb-bounces@ietf.org] On=20 >> Behalf Of Ram Mohan R >> >(rmohanr) >> >Sent: 5. joulukuuta 2014 6:19 >> >To: rtcweb@ietf.org >> >Subject: Re: [rtcweb] I-D Action: >> >draft-ietf-rtcweb-stun-consent-freshness-09.txt >> > >> >This version addresses all the WGLC comments received. >> >Please review and let us know if any thing else is missing. >> > >> >Regards, >> >Authors >> > >> >-----Original Message----- >> >From: "internet-drafts@ietf.org" >> >Date: Thursday, 4 December 2014 11:17 pm >> >To: "i-d-announce@ietf.org" >> >Cc: "rtcweb@ietf.org" >> >Subject: [rtcweb] I-D Action: >> >draft-ietf-rtcweb-stun-consent-freshness-09.txt >> > >> >> >> >>A New Internet-Draft is available from the on-line=20 >> Internet-Drafts >> >>directories. >> >> This draft is a work item of the Real-Time Communication in >> >>WEB-browsers Working Group of the IETF. >> >> >> >> Title : STUN Usage for Consent Freshness >> >> Authors : Muthu Arul Mozhi Perumal >> >> Dan Wing >> >> Ram Mohan Ravindranath >> >> Tirumaleswar Reddy >> >> Martin Thomson >> >> Filename :=20 >> draft-ietf-rtcweb-stun-consent-freshness-09.txt >> >> Pages : 9 >> >> Date : 2014-12-04 >> >> >> >>Abstract: >> >> To prevent sending excessive traffic to an=20 >> endpoint, periodic consent >> >> needs to be obtained from that remote endpoint. >> >> >> >> This document describes a consent mechanism using=20 >> a new Session >> >> Traversal Utilities for NAT (STUN) usage. This=20 >> same mechanism can >> >> also determine connection loss ("liveness") with a=20 >> remote peer. >> >> >> >> >> >>The IETF datatracker status page for this draft is: >> =09 >>>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-cons >> ent-freshne >> >>ss/ >> >> >> >>There's also a htmlized version available at: >> =09 >>>> http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-fr >> eshness-09 >> >> >> >>A diff from the previous version is available at: >> =09 >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-cons >> ent-freshne >> >>ss- >> >>09 >> >> >> >> >> >>Please note that it may take a couple of minutes from=20 >> the time of >> >>submission until the htmlized version and diff are=20 >> available at >> >>tools.ietf.org. >> >> >> >>Internet-Drafts are also available by anonymous FTP at: >> >>ftp://ftp.ietf.org/internet-drafts/ >> >> >> >>_______________________________________________ >> >>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 >> =09 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> =09 >>=20 >>=20 >>=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Tue Dec 9 09:52:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D721A6F05 for ; Tue, 9 Dec 2014 09:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSj16pdLapl8 for ; Tue, 9 Dec 2014 09:52:42 -0800 (PST) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B231A8A48 for ; Tue, 9 Dec 2014 09:52:42 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id r2so4971880igi.12 for ; Tue, 09 Dec 2014 09:52:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lbklqz70XXeYW6K/RFLkIoXJJCLyUZx3LgCI4cj3Luk=; b=UpQawIkNe9oubwUtbUJBlsb3QYqc7jY2pkMjoMRifwTTEsDJ7G/0FJdW3irhVJuzzY /SAo88BSxBWpoaEmt+BKnbGoHLkmbh06DHrNC7YJElvnPOrWQ21ORx4KyPTqlHnK2YZO OMvhmVz0eua2Rj1fwCA/8wAtGzvdBuJQXBH86O2k+c1creEHxSrp90U1VQos4h0C7VWv 7NMzzNDIp+t5soZle00HrzjZTnpsF+F/8AyNU5+z0C1tr2NnQFWhvDxH/vtePN6ZFIic scrg3NhpoZyZQ9pXzbVgbS3tifIpsE+LWeRhFdr7lHHIQ5/AXAoQs2YvWP/XEjv+h9Gk 2ORw== X-Gm-Message-State: ALoCoQlE2P4ViSeIFIxbpG0Xe5xGB6DJJxdtyPbz48u7rFl1UP26+DsPquc0IZEbEFe+XiAhv+PM X-Received: by 10.50.30.227 with SMTP id v3mr3612200igh.24.1418147561421; Tue, 09 Dec 2014 09:52:41 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id x10sm1181956igl.18.2014.12.09.09.52.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Dec 2014 09:52:41 -0800 (PST) Message-ID: <548736AC.6000407@bbs.darktech.org> Date: Tue, 09 Dec 2014 12:51:40 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5486C48D.8040602@alvestrand.no> <5487331F.8050404@bbs.darktech.org> <5487353D.8030106@gmail.com> In-Reply-To: <5487353D.8030106@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tOxs284QM9Ihu5MT2ou3Ikz_GA8 Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 17:52:46 -0000 On 09/12/2014 12:45 PM, Sergio Garcia Murillo wrote: > On 09/12/2014 18:36, cowwoc wrote: >> On 09/12/2014 12:32 PM, David Singer wrote: >>> >>> I would also like to know from those confirming the sense of the >>> room, whether THEY THEMSELVES intend to implement both codecs, or >>> whether they conveniently think they don’t need to, and it’s just a >>> problem for other people to handle. >>> >>> Honestly, a +1 for “those other people should do it†is meaningless. >> >> That's a fair point. I'm guessing the vast majority of people >> answering on the mailing list only plan to implement one codec >> because they are non-browser implementors. > > No, that's not a fair point. I don't see most of the people making > taking decisions on other topics (SDP, FEC, DTLS, CC, > SVC/Simulcasting/Multicasting, Plan A/PlanB/No plan) implementing them > themselves. So if this going to be the rule about who-can-vote-what we > should redefine the whole IETF process. > > Everyone should be aware of what are they voting and what is the > amount of burden/costs it requires to be implemented, and see how that > will contribute to the success/failure of webrtc and vote accordingly. > Not just in this topic, but in any topic. Sergio, I think this warrants a discussion. It might not be very politically correct to say so, but I support the idea that only those who are implicated should have a say. The alternative leads to armchair politics and bikeshedding. That said, I echo Simon's point that until Apple and Microsoft officially declare their intent to implement WebRTC they are not "implicated", hence they should not really get to vote. Sorry guys :) Gili From nobody Tue Dec 9 09:55:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0011A8A66 for ; Tue, 9 Dec 2014 09:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVdVQdYp1XIr for ; Tue, 9 Dec 2014 09:55:48 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA5FD1A710C for ; Tue, 9 Dec 2014 09:55:45 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so8723772wiv.17 for ; Tue, 09 Dec 2014 09:55:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=5hLju6aoM6RsGtCWqg+f4y/xnI2hZVDU5P+F3CSTtQA=; b=oEtJ8zB2ZO/CUMK9/ZxXGJ3mZ7e6imIYtAfh2I/BN+dezUIQTlCbKTSeKIQqyGwE2B w95icKt9bMQ1HNech4ymtl4z8yc+FZTe1jAfz+wc9a394KQRRlUxfJ3UsIcd7HXlk4qv lyuHOYa/K+kIE+ZJFKo/May8t8FbO0vcq2XnyGGbv0gHZfFzpBAeSxn6MXHt3jfAnRgS LDpAKr3xJ4c6NpZIF0d3eTQS+wXlrAkuzk0CBzqzX3DZfpXf7zoP/TOM3SHKnOCvFMEo /sBXZOv1UlQGCunkp8XUx37nDOYZ8ECp9VwXBFr0+6xCzd3QGIWJL5QE+rXMzAO6TpZk A4PA== X-Received: by 10.180.77.79 with SMTP id q15mr34038082wiw.8.1418147744582; Tue, 09 Dec 2014 09:55:44 -0800 (PST) Received: from [192.168.1.37] (136.Red-81-39-109.dynamicIP.rima-tde.net. [81.39.109.136]) by mx.google.com with ESMTPSA id wx3sm2669020wjc.19.2014.12.09.09.55.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Dec 2014 09:55:43 -0800 (PST) Message-ID: <5487379E.2090406@gmail.com> Date: Tue, 09 Dec 2014 18:55:42 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5486C48D.8040602@alvestrand.no> <5487331F.8050404@bbs.darktech.org> <5487353D.8030106@gmail.com> <548736AC.6000407@bbs.darktech.org> In-Reply-To: <548736AC.6000407@bbs.darktech.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bQmrweQwVlHnIPgZSMwm-V3o9yo Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 17:55:50 -0000 On 09/12/2014 18:51, cowwoc wrote: > On 09/12/2014 12:45 PM, Sergio Garcia Murillo wrote: >> On 09/12/2014 18:36, cowwoc wrote: >>> On 09/12/2014 12:32 PM, David Singer wrote: >>>> >>>> I would also like to know from those confirming the sense of the >>>> room, whether THEY THEMSELVES intend to implement both codecs, or >>>> whether they conveniently think they don’t need to, and it’s just a >>>> problem for other people to handle. >>>> >>>> Honestly, a +1 for “those other people should do it†is meaningless. >>> >>> That's a fair point. I'm guessing the vast majority of people >>> answering on the mailing list only plan to implement one codec >>> because they are non-browser implementors. >> >> No, that's not a fair point. I don't see most of the people making >> taking decisions on other topics (SDP, FEC, DTLS, CC, >> SVC/Simulcasting/Multicasting, Plan A/PlanB/No plan) implementing >> them themselves. So if this going to be the rule about >> who-can-vote-what we should redefine the whole IETF process. >> >> Everyone should be aware of what are they voting and what is the >> amount of burden/costs it requires to be implemented, and see how >> that will contribute to the success/failure of webrtc and vote >> accordingly. Not just in this topic, but in any topic. > > Sergio, > > I think this warrants a discussion. It might not be very politically > correct to say so, but I support the idea that only those who are > implicated should have a say. The alternative leads to armchair > politics and bikeshedding. Indeed. I could be in favor of that, but not about changing the rules in the middle of the game just because some don't like the result so far. BR Sergio From nobody Tue Dec 9 09:56:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AFB1A8A62 for ; Tue, 9 Dec 2014 09:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6Kr31_lsZl3 for ; Tue, 9 Dec 2014 09:55:58 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA66D1A8A15 for ; Tue, 9 Dec 2014 09:55:49 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id u10so970089lbd.3 for ; Tue, 09 Dec 2014 09:55:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pilPEfcR60+nEFHuaiXhIilnOkBra5+/Clw5JuSth8U=; b=IsUpABKPJlS6mGLAZrDsZ9LVE/swfxyUmfVshF3XgzCEwNHDTZYXuMnoVFWBR9UJ/y 16Qzq/ArK6V+T+bJo+T523q4kPRUomUpsaut671tJ/qQ72WwzRV2zqmVtT8sZoKgJ8+k tdiuWeQm4lcWAcwfwVr/nSEOX8waX/0lduXYIao1QFVMdLBZmTCtDshGUB37VDyBcPRq iIJ+Ejui97qcpYiAqawfszeyqZrS92lHRM4WnZE0eWGhKu1LU0XiBglscmP8JaYwjmMK JuyvF9UgblyeiIC0XN9C8wtgsQyFPaM/ccfRIUaTxCCMrlwtpZXewv9Iovrrj3E9mb/w y4Dg== X-Gm-Message-State: ALoCoQk2s2JXFL8Dy3lBMLpZ8cmlFmcqFcIYnz/kI6hvgiklkwpTwZ2kFEe6AVl1QBMsP6Hdz+Vq MIME-Version: 1.0 X-Received: by 10.112.168.97 with SMTP id zv1mr23417260lbb.6.1418147748047; Tue, 09 Dec 2014 09:55:48 -0800 (PST) Received: by 10.25.84.145 with HTTP; Tue, 9 Dec 2014 09:55:47 -0800 (PST) In-Reply-To: <548736AC.6000407@bbs.darktech.org> References: <5486C48D.8040602@alvestrand.no> <5487331F.8050404@bbs.darktech.org> <5487353D.8030106@gmail.com> <548736AC.6000407@bbs.darktech.org> Date: Tue, 9 Dec 2014 10:55:47 -0700 Message-ID: From: Simon Perreault To: cowwoc Content-Type: multipart/alternative; boundary=001a11c341c8c303c60509cc40c6 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rzF_KtSMXIMmqCYSQdcNu9Mhlh4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 17:56:04 -0000 --001a11c341c8c303c60509cc40c6 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 9, 2014 at 10:51 AM, cowwoc wrote: > That said, I echo Simon's point that until Apple and Microsoft officially > declare their intent to implement WebRTC they are not "implicated", hence > they should not really get to vote. > Just for the record, I did not say that. Simon --001a11c341c8c303c60509cc40c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Dec 9, 2014 at 10:51 AM, cowwoc <cowwoc@bbs.darktech.org= > wrote:
That said, I echo Simon's point that until Apple = and Microsoft officially declare their intent to implement WebRTC they are = not "implicated", hence they should not really get to vote.
=

Just for the record, I did not say that.

Simon
--001a11c341c8c303c60509cc40c6-- From nobody Tue Dec 9 09:57:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE3C1A8A8D for ; Tue, 9 Dec 2014 09:57:31 -0800 (PST) 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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nkHmLzxoY3l for ; Tue, 9 Dec 2014 09:57:26 -0800 (PST) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0E21A8A95 for ; Tue, 9 Dec 2014 09:57:25 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id r2so1385695igi.12 for ; Tue, 09 Dec 2014 09:57:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=DmsFuZqbkZYdTSOH39a/5zEtA4LkgGZLrPsz6Ctx5kc=; b=hv5JiafxECPATJplkqsQuHz3zJ9xVeAZxAvbu8nKIZF2Se6ixRzuh+1vVf1ShrzxdX vPV18R510kIVKttxkX4ezidfTkhJXyE8iWrU+qmfWJwpY4oHgSD+iwmqF6Di9biuKE24 UOHsicExxJMkufVWXbznearHmdlPEPQJD4azYWxtLBOjLhDwrBEN91yMz9RuvP+whxqA BkTEn8RX0MLDjrSprxVREjGPiy7aHzLB1JeEidkxdy5NLALxdpPEyCyHCDPz9VEK3fUA oi00brUbazHJj3geEd5b5fA7Oe9VkMZoh3Vqs+JriI+VyFNBnt+sC4bHju/7bVPKkQ4r aQlw== X-Gm-Message-State: ALoCoQlT61MNKN5KUgdT9g04Uw3ayHd0ehnC+L7/OqgjFAljn2MQb+rMjpNAyZG9haXBuFWsiHVi X-Received: by 10.50.79.229 with SMTP id m5mr3640113igx.10.1418147844875; Tue, 09 Dec 2014 09:57:24 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id i3sm880130iod.19.2014.12.09.09.57.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Dec 2014 09:57:24 -0800 (PST) Message-ID: <548737C7.1010102@bbs.darktech.org> Date: Tue, 09 Dec 2014 12:56:23 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Simon Perreault References: <5486C48D.8040602@alvestrand.no> <5487331F.8050404@bbs.darktech.org> <5487353D.8030106@gmail.com> <548736AC.6000407@bbs.darktech.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060606040508020602040202" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/F3FkNf3dJF5g2-8uMJ0tRRTqlGI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 17:57:31 -0000 This is a multi-part message in MIME format. --------------060606040508020602040202 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 09/12/2014 12:55 PM, Simon Perreault wrote: > > On Tue, Dec 9, 2014 at 10:51 AM, cowwoc > wrote: > > That said, I echo Simon's point that until Apple and Microsoft > officially declare their intent to implement WebRTC they are not > "implicated", hence they should not really get to vote. > > > Just for the record, I did not say that. > > Simon Sorry for misquoting you. I think it was Tim Panton who first hinted in this direction. Gili --------------060606040508020602040202 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 09/12/2014 12:55 PM, Simon Perreault wrote:

On Tue, Dec 9, 2014 at 10:51 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
That said, I echo Simon's point that until Apple and Microsoft officially declare their intent to implement WebRTC they are not "implicated", hence they should not really get to vote.

Just for the record, I did not say that.

Simon

Sorry for misquoting you. I think it was Tim Panton who first hinted in this direction.

Gili
--------------060606040508020602040202-- From nobody Tue Dec 9 10:07:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18661A8AB4 for ; Tue, 9 Dec 2014 10:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7n_MrQdEqU-6 for ; Tue, 9 Dec 2014 10:07:41 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002-out2.apm-internet.net [85.119.248.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 968461A1DFA for ; Tue, 9 Dec 2014 10:07:40 -0800 (PST) Received: (qmail 33687 invoked from network); 9 Dec 2014 18:07:39 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 13166 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 9 Dec 2014 18:07:38 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 907CD18A10CB; Tue, 9 Dec 2014 18:07:33 +0000 (GMT) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 7BC6C18A027C; Tue, 9 Dec 2014 18:07:33 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E4E4480F-ED7F-444A-A433-4D66D705A029" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Tim Panton In-Reply-To: <548737C7.1010102@bbs.darktech.org> Date: Tue, 9 Dec 2014 18:07:32 +0000 Message-Id: <37CBED92-D820-491B-AFB0-0ED9E4FDEA99@phonefromhere.com> References: <5486C48D.8040602@alvestrand.no> <5487331F.8050404@bbs.darktech.org> <5487353D.8030106@gmail.com> <548736AC.6000407@bbs.darktech.org> <548737C7.1010102@bbs.darktech.org> To: cowwoc X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9W6MzUnXZlMOue8nmSYwf9smaAM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 18:07:44 -0000 --Apple-Mail=_E4E4480F-ED7F-444A-A433-4D66D705A029 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 9 Dec 2014, at 17:56, cowwoc > wrote: >=20 > On 09/12/2014 12:55 PM, Simon Perreault wrote: >>=20 >> On Tue, Dec 9, 2014 at 10:51 AM, cowwoc > wrote: >> That said, I echo Simon's point that until Apple and Microsoft = officially declare their intent to implement WebRTC they are not = "implicated", hence they should not really get to vote. >>=20 >> Just for the record, I did not say that. >>=20 >> Simon >=20 > Sorry for misquoting you. I think it was Tim Panton who first hinted = in this direction. I was being flippant.=20 I do think however better standards emerge when people who consume = webAPIs or build services upon ietf protocols=20 are included in the discussion, not just the established browser = vendors. Tim.= --Apple-Mail=_E4E4480F-ED7F-444A-A433-4D66D705A029 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 9 Dec 2014, at 17:56, cowwoc <cowwoc@bbs.darktech.org> wrote:

On 09/12/2014 12:55 PM, Simon Perreault wrote:

On Tue, Dec 9, 2014 at 10:51 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
That said, I echo Simon's point that until Apple and Microsoft officially declare their intent to implement WebRTC they are not "implicated", hence they should not really get to vote.

Just for the record, I did not say that.

Simon

Sorry for misquoting you. I think it was Tim Panton who first hinted in this direction.

I was being flippant. 

I do think however better standards emerge when people who consume webAPIs or build services upon ietf protocols 
are included in the discussion, not just the established browser vendors.

Tim.
--Apple-Mail=_E4E4480F-ED7F-444A-A433-4D66D705A029-- From nobody Tue Dec 9 10:14:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C261A1A11 for ; Tue, 9 Dec 2014 10:14:42 -0800 (PST) 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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZmF8FDkK735 for ; Tue, 9 Dec 2014 10:14:40 -0800 (PST) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B0A1A0161 for ; Tue, 9 Dec 2014 10:14:40 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id rd18so1045672iec.29 for ; Tue, 09 Dec 2014 10:14:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=nPHyspFsbqzELJvUzgZaMsH/X9Y4NjHJedv3yWZec/U=; b=cQNZ8vCmoOMF+exJufRBWUHPC92GXbQgTNikpqupqQ1s/+c7YFFrIRzvOq3hSxws85 GrTYkI17DXmSA8rRyQQ/Q1JuXLe+uli39c9ocKNLswZzvW1bcrfhfisUws+NCzJAdqcS ElgFVzGRpz9YL/zhUjL9dJyzqF1zoiX5suI+1r2qcee5aYnq3iwIk9ewvt+kTLMC5w2V CPylFd/f6K+Zta/BKq1V5yQ66cUCvf0Qv9BbAxgpIiN1ZDhq7ja8k/+xCKdzME+EgJwk 32xHtHkEJbhIsdwLCgWZpS4aBtrKUs7mECumX+tdQ6PxZp/hZlVbSvz+wg2rqfT51Wu5 KqFg== X-Gm-Message-State: ALoCoQm5aIblzR5Pea0zlJ3vqucb77VA6icMoAYe6gEmWKJvCsFSQfyjEB3xP3staJi1F0iOj5H7 X-Received: by 10.107.35.83 with SMTP id j80mr17597564ioj.55.1418148879747; Tue, 09 Dec 2014 10:14:39 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id ck1sm5838235igb.0.2014.12.09.10.14.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Dec 2014 10:14:39 -0800 (PST) Message-ID: <54873BD1.2030704@bbs.darktech.org> Date: Tue, 09 Dec 2014 13:13:37 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Tim Panton References: <5486C48D.8040602@alvestrand.no> <5487331F.8050404@bbs.darktech.org> <5487353D.8030106@gmail.com> <548736AC.6000407@bbs.darktech.org> <548737C7.1010102@bbs.darktech.org> <37CBED92-D820-491B-AFB0-0ED9E4FDEA99@phonefromhere.com> In-Reply-To: <37CBED92-D820-491B-AFB0-0ED9E4FDEA99@phonefromhere.com> Content-Type: multipart/alternative; boundary="------------010300040807060106040606" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XvcHND0sp0mUSV5PlfkUh3GOfwc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 18:14:42 -0000 This is a multi-part message in MIME format. --------------010300040807060106040606 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 09/12/2014 1:07 PM, Tim Panton wrote: > >> On 9 Dec 2014, at 17:56, cowwoc > > wrote: >> >> On 09/12/2014 12:55 PM, Simon Perreault wrote: >>> >>> On Tue, Dec 9, 2014 at 10:51 AM, cowwoc >> > wrote: >>> >>> That said, I echo Simon's point that until Apple and Microsoft >>> officially declare their intent to implement WebRTC they are not >>> "implicated", hence they should not really get to vote. >>> >>> >>> Just for the record, I did not say that. >>> >>> Simon >> >> Sorry for misquoting you. I think it was Tim Panton who first hinted >> in this direction. > > I was being flippant. > > I do think however better standards emerge when people who consume > webAPIs or build services upon ietf protocols > are included in the discussion, not just the established browser vendors. I strongly agree for the general case, but maybe not in the case of MTI codecs. If, for example, you were to argue that interoperability between browser and non-browser systems is of high importance then we should have a single MTI discussion across both systems. Right now we are advocating different MTIs for each system, which leads me to conclude that non-browser implementors are not implicated in the outcome of the browser-specific MTI codec. Gili --------------010300040807060106040606 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 09/12/2014 1:07 PM, Tim Panton wrote:

On 9 Dec 2014, at 17:56, cowwoc <cowwoc@bbs.darktech.org> wrote:

On 09/12/2014 12:55 PM, Simon Perreault wrote:

On Tue, Dec 9, 2014 at 10:51 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
That said, I echo Simon's point that until Apple and Microsoft officially declare their intent to implement WebRTC they are not "implicated", hence they should not really get to vote.

Just for the record, I did not say that.

Simon

Sorry for misquoting you. I think it was Tim Panton who first hinted in this direction.

I was being flippant. 

I do think however better standards emerge when people who consume webAPIs or build services upon ietf protocols 
are included in the discussion, not just the established browser vendors.

I strongly agree for the general case, but maybe not in the case of MTI codecs.

If, for example, you were to argue that interoperability between browser and non-browser systems is of high importance then we should have a single MTI discussion across both systems. Right now we are advocating different MTIs for each system, which leads me to conclude that non-browser implementors are not implicated in the outcome of the browser-specific MTI codec.

Gili
--------------010300040807060106040606-- From nobody Tue Dec 9 10:44:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612351A87E0 for ; Tue, 9 Dec 2014 10:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9R5MpD6kcgL3 for ; Tue, 9 Dec 2014 10:44:39 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0651A87A4 for ; Tue, 9 Dec 2014 10:44:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418150678; x=2282064278; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Y/PCweQoS+2lr26/UwDGGTXrah3YSnwXcFO9NWmbJo8=; b=k9jc2b34UpnZa/FjNramtfU8s7bl9ZDB7HwB2l4eQzVNQyMN1/4LjyFBkz9YSKKg 8u1l/S534rlgHglC8FkDYZj5vZ3RRVIN+XgLdORP7+xC2OyZ3anJ6iDj6MUGvnhz cHU6a1z91lcld3u/iRcR3w8buQwmQ4rTmqwJuyf49/YXUc2DFRdwVdCye8ndrSq+ ikxZAxGI8h5ybMtpvVMvftQzQZzJExisbHz2d3ZjQMJzbW69Sh7PzNYg9UnesJ7B mP5ylsvjXhenap0eLERfaYjJUWu3LOcsJ0FqGlh8ZHMuucXbdxZdQFXsZdlb2oHp 0fhXDYlXcAWcFUJfB6FX8A==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 4C.04.12074.61347845; Tue, 9 Dec 2014 10:44:38 -0800 (PST) X-AuditID: 11973e12-f79f86d000002f2a-d6-548743168fcf Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id E3.76.05998.82347845; Tue, 9 Dec 2014 10:44:56 -0800 (PST) Received: from [17.153.29.83] (unknown [17.153.29.83]) by chive.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGB00DD1W2DFJ70@chive.apple.com> for rtcweb@ietf.org; Tue, 09 Dec 2014 10:44:38 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <54873575.3030804@nostrum.com> Date: Tue, 09 Dec 2014 10:44:39 -0800 Content-transfer-encoding: quoted-printable Message-id: <53ECE529-C011-4666-B044-226613CA263D@apple.com> References: <5486C48D.8040602@alvestrand.no> <54873575.3030804@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUi2FAYrivm3B5i8HSCocXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKeLVvM2tBL19Fy5bLTA2Mm7m7GDk5JARMJBZPvswEYYtJXLi3 nq2LkYtDSGAvo8SVzUvZYIqm32hkh0h0M0n8fz0Hwfm+di5rFyMHB7OAusSUKbkgDbwCehJN Tx6DTRUWMJfY2HWEGcRmE1CVeDDnGCOIzSmgLXH02nGwVhag+P0ZCiBhZoFgiaMPjzBB2NoS T95dACvhFbCRaPihCBIWEqiT+Nw7lRXEFhFQlGg7fJMZ4kxZiX8Xz7BD2G9ZJXZdSJjAKDwL 4bZZSG6bhWTBAkbmVYxCuYmZObqZeSZ6iQUFOal6yfm5mxhBATzdTmgH46lVVocYBTgYlXh4 NSzbQoRYE8uKK3MPMUpzsCiJ8960AQoJpCeWpGanphakFsUXleakFh9iZOLglGpglDl7lU1u pfs1qWsm/G7yf27lCn77oTZ5V3zLa9epCut8a85mc1+ui+lg+yGp+7T46/Og3CsLp69avuxf Lpvdyf+7VvXdus7xu9now9MzE2vmHDuqs+n+pN9P9J2Xb576/AnHra/lZ+u2H7UIie96zXOf dw7TywvcptPN5p0RY3idxDHR+I/NmXVKLMUZiYZazEXFiQCIIxBCQQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUi2FDMr6vh3B5isOITh8Xaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKeLVvM2tBL19Fy5bLTA2Mm7m7GDk5JARMJKbfaGSHsMUkLtxb z9bFyMUhJNDNJPH/9Rx2OOf72rmsXYwcHMwC6hJTpuSCNPAK6Ek0PXnMBGILC5hLbOw6wgxi swmoSjyYc4wRxOYU0JY4eu04WCsLUPz+DAWQMLNAsMTRh0eYIGxtiSfvLoCV8ArYSDT8UAQJ CwnUSXzuncoKYosIKEq0Hb7JDHGmrMS/i2fYJzAKzEK4ZxaSe2YhGbqAkXkVo0BRak5ipYle YkFBTqpecn7uJkZwyBWG72D8t8zqEKMAB6MSD6+GZVuIEGtiWXFl7iFGCQ5mJRHetSztIUK8 KYmVValF+fFFpTmpxYcYpTlYlMR5m981hggJpCeWpGanphakFsFkmTg4pRoY9842j9Ft/ZZ3 VWT2zjtegVZNfPunLs1y68qL+6PZV8OsP3vqQaboFxNYuPqvL6lZduXepq8PGs+1TFg/NaBl umrhQ6VP4sv7yz4uZRXZM0vV+sHeN1ujXkRIzkw9Y5D9ILL3bXjwjou1XcI8T6c3zlebfDft Wc5Txc+nF23qzzzf+zzm1M9XHkosxRmJhlrMRcWJAHGgefU1AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AiVUQMG29u7RKDSOwMIW_wUReUw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 18:44:40 -0000 > On Dec 9, 2014, at 9:46 , Adam Roach wrote: >=20 > On 12/9/14 11:32, David Singer wrote: >> I would also like to know from those confirming the sense of the = room, whether THEY THEMSELVES intend to... >=20 > Wait, you're pressing other companies for future product plans? With = the implication that doing so is a prerequisite to participating in the = discussion? >=20 > That's a mighty sharp blade there. You might check where it's pointed. Yes, I realize that almost no-one can make promises about what they will = ship. And some companies will be in a position where they can=E2=80=99t = say anything. And yes, my company has a strict policy of not promising = what we will or won=E2=80=99t do in the future. But, hypothetically, if = the statement was =E2=80=9Cmust support H.264=E2=80=9D I could clearly = indicate that that I expect it to be unproblematic. But surely those that see the dual mandate as unproblematic for them to = implement can say that, can=E2=80=99t they? Surely we can see at least = a reasonable number of =E2=80=9Cyes, we would hope/expect/intend to ship = both=E2=80=9D, as a non-binding indication? I mean, the draft =E2=80=98must do both=E2=80=99 would require people = who have a principled objection to paying fees, having to pay for H.264. = I am curious, are people willing to let their principles (and money) go, = in order to comply with the =E2=80=98must=E2=80=99? Obviously, I am trying to assess whether this compromise would, in fact, = be effective in practice =E2=80=94 would enough people abide by its = intent that we=E2=80=99d get the interoperability that is the point of = the mandate? I don=E2=80=99t want to be citing RFC 6919 :-). David Singer Manager, Software Standards, Apple Inc. From nobody Tue Dec 9 10:44:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CACB1A1A2F for ; Tue, 9 Dec 2014 10:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXlI0rme62_R for ; Tue, 9 Dec 2014 10:44:53 -0800 (PST) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E95F1A8A78 for ; Tue, 9 Dec 2014 10:44:53 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id rl12so1111935iec.30 for ; Tue, 09 Dec 2014 10:44:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XInpzuTIBMbxgUA7fEVY46elciJa74+cnpO6fccaqV8=; b=I8QFGieejWjdVECj2J8wZ3UYwFaqs1tCNISioUeu4VQYmO9oUqoEuXss2yFenv6DV3 wfkd/BQyJnik4DPMizbm81ETDwXIRIXmolBbFCYplNBoDsobS7sGD7y/NYRfPW7ZiNwP R2Z3ZD2NWIpnTtaZtZ6OneOilHNhYkWAFtjDZK+shZg2V5Ebfsx6hDmML29Jrt5izG1E FvDQgVl1qz8aNykDEjOVq+IuBFxaSWtWelmZ2s6KabzDNNDsBkK0FVcWifA60VMqAAM1 fK1Ooo/U8Id1LaeKHtOavqjeG0CGZdnk831M5hoiiNyWV4UQuQ1dICO2aVQQoQk/V9D+ iytA== X-Gm-Message-State: ALoCoQktOCOV+uGPWs5rJM3w3mq5rhf7O/HmuEAFqkMi+vZsiRE+rLSQcJloPXy3kbgvLflLd2pZ X-Received: by 10.107.15.226 with SMTP id 95mr18083898iop.12.1418150692849; Tue, 09 Dec 2014 10:44:52 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id jg3sm5864862igb.12.2014.12.09.10.44.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Dec 2014 10:44:52 -0800 (PST) Message-ID: <548742E7.40600@bbs.darktech.org> Date: Tue, 09 Dec 2014 13:43:51 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54872804.9090700@bbs.darktech.org> In-Reply-To: <54872804.9090700@bbs.darktech.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xBqf5PbgpXFwg6BkmoqYNOMF78s Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 18:44:55 -0000 It has come to my attention that I misunderstood the chair proposal. I was under the impression that non-browsers were still given the option of only implementing one MTI (this was an older proposal). In light of this, I am withdrawing my support for the compromise as presented by the chair. I plan to abstain on this decision. Thank you, Gili On 09/12/2014 11:49 AM, cowwoc wrote: > Hi Harald, > > I am in favor of the compromise as presented by the chair. > > (I also second Victor Pascual Avila's suggestion to revisit this > decision for browsers as well as non-browsers in the future should > anything of substance change.) > > Gili > > On 09/12/2014 4:44 AM, Harald Alvestrand wrote: >> I note that the "confirming sense of the room" thread has gotten a lot >> of messages that are not declaring a position on the question. >> >> I also note that from the messages on the thread, I can't figure out if >> Keith Drage, Gili, Monty Montgomery or Peter Saint-Andre have taken a >> position (I could guess, but I don't want to - besides, they might not >> want to take a position, which is perfectly OK). >> >> It would be nice for me as a reader if people could: >> >> - state their position on the "confirming sense of the room" thread >> - change the subject line when they want to say anything else >> >> That's my preference - of course, people who have "mute thread" in their >> email readers might want the whole discussion to stay on thread, and >> will hate me for the last suggestion.... >> >> Harald >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Tue Dec 9 11:08:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930571A8FD3 for ; Tue, 9 Dec 2014 11:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRm5JawhWFYA for ; Tue, 9 Dec 2014 11:08:22 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857F11A8F4A for ; Tue, 9 Dec 2014 11:08:22 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id x12so1688610wgg.39 for ; Tue, 09 Dec 2014 11:08:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FBh2xiuqswB0YdXGcFEdX+ViJ7ip2n+iNQyqciopBvk=; b=eLOKL2PiQdAFjlsihbus1M7uqgUhhvpECB6xa5J7b6MY0M1wHQuOA8dTENpaAWjCGb DjJ1mmLxrvYeV8vQZHp0KXHb+EGNcgbp6ac0ETUBRSlmcJoEeQkIW81yh/cimyYDGFsn twDmO+BZW1m4gIyzBmFYXlza1D7osZXJWBE3OYf0m695FSAO/X7OeDDqMH7ZormUzDwE cGjAfVqy+lGKPYICeEpgUps29HTlS2FRuj5r9mvvHv0W0PHSvijk4IZTLje9y3L8FRoj i75wl/Z3JvZ+CHG0kDzzMUyoGuu3ezr2PJpODEX79xVTY5+Rnq/f4fb9knKiMUy3W4D6 +H9Q== X-Received: by 10.194.161.202 with SMTP id xu10mr85799wjb.4.1418152101345; Tue, 09 Dec 2014 11:08:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.211.131 with HTTP; Tue, 9 Dec 2014 11:08:01 -0800 (PST) In-Reply-To: <54873575.3030804@nostrum.com> References: <5486C48D.8040602@alvestrand.no> <54873575.3030804@nostrum.com> From: Bernard Aboba Date: Tue, 9 Dec 2014 11:08:01 -0800 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=089e013d1f9c3d04040509cd44e6 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KihSRWxHn_0PQ4sKrbxSeE5sEVM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 19:08:24 -0000 --089e013d1f9c3d04040509cd44e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > I would also like to know from those confirming the sense of the room, > whether THEY THEMSELVES intend to implement both codecs, or whether they > conveniently think they don=E2=80=99t need to, and it=E2=80=99s just a pr= oblem for other > people to handle. > > Honestly, a +1 for =E2=80=9Cthose other people should do it=E2=80=9D is m= eaningless. > That's a fair point. I'm guessing the vast majority of people answering on the mailing list only plan to implement one codec because they are non-browser implementors. Gili [BA] I agree that the vast majority of people answering probably believe that the requirements don't apply to the non-browser category, but actually the proposal is that dual MTI does apply to non-browsers, right? It's just the WebRTC-compatible endpoints that are exempt. So it's actually worse than "those other people should do it" - it's really "I intend to ignore the requirements myself and pretend that they don't apply to me while holding other people to them". On Tue, Dec 9, 2014 at 9:46 AM, Adam Roach wrote: > On 12/9/14 11:32, David Singer wrote: > >> I would also like to know from those confirming the sense of the room, >> whether THEY THEMSELVES intend to... >> > > Wait, you're pressing other companies for future product plans? With the > implication that doing so is a prerequisite to participating in the > discussion? > > That's a mighty sharp blade there. You might check where it's pointed. > > /a > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e013d1f9c3d04040509cd44e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would also like to know from those confirming the s= ense of the room, whether THEY THEMSELVES intend to implement both codecs, = or whether they conveniently think they don=E2=80=99t need to, and it=E2=80= =99s just a problem for other people to handle.

Honestly, a +1 for = =E2=80=9Cthose other people should do it=E2=80=9D is meaningless.

That's a fair point.= I'm guessing the vast majority of people answering on the mailing list= only plan to implement one codec because they are non-browser implementors= .

Gili=

[BA] I agree that the v= ast majority of people answering probably believe that the requirements don= 't apply to the non-browser category, but actually the proposal is that= dual MTI does apply to non-browsers, right? It's just the WebRTC-compa= tible endpoints that are exempt.=C2=A0 So it's actually worse than &quo= t;those other people should do it" - it's really "I intend to= ignore the requirements myself and pretend that they don't apply to me= while holding other people to =C2=A0them". =C2=A0=C2=A0
<= /div>

On Tue, Dec = 9, 2014 at 9:46 AM, Adam Roach <adam@nostrum.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">On 12/9/14 11:32, David Singer wrote:
I would also like to know from those confirming the sense of the room, whet= her THEY THEMSELVES intend to...

Wait, you're pressing other companies for future product plans? With th= e implication that doing so is a prerequisite to participating in the discu= ssion?

That's a mighty sharp blade there. You might check where it's point= ed.

/a


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--089e013d1f9c3d04040509cd44e6-- From nobody Tue Dec 9 11:11:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7111A1BA9 for ; Tue, 9 Dec 2014 11:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GUARANTEED_100_PERCENT=2.699, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCSW0ztFD23Y for ; Tue, 9 Dec 2014 11:11:35 -0800 (PST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1977D1A0217 for ; Tue, 9 Dec 2014 11:11:35 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 09 Dec 2014 11:11:32 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,546,1413270000"; d="scan'208,217";a="635149713" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by fmsmga001.fm.intel.com with ESMTP; 09 Dec 2014 11:11:32 -0800 Received: from fmsmsx117.amr.corp.intel.com (10.18.116.17) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Dec 2014 11:11:32 -0800 Received: from fmsmsx115.amr.corp.intel.com ([169.254.4.149]) by fmsmsx117.amr.corp.intel.com ([169.254.3.167]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 11:11:31 -0800 From: "Cavigioli, Chris" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Video codecs: Clear positions.... Thread-Index: AQHQE9ZowNIQYgNYl0eTI4IK20km2pyIDo6AgAAQQYD//32nQA== Date: Tue, 9 Dec 2014 19:11:31 +0000 Message-ID: References: <5486C48D.8040602@alvestrand.no> <54873575.3030804@nostrum.com> <53ECE529-C011-4666-B044-226613CA263D@apple.com> In-Reply-To: <53ECE529-C011-4666-B044-226613CA263D@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.106] Content-Type: multipart/alternative; boundary="_000_E36D1A4AE0B6AA4091F1728D584A6AD24012D343fmsmsx115amrcor_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Swk1mm0NlLZVaB7tgpxsxa3WVZ0 Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 19:11:37 -0000 --_000_E36D1A4AE0B6AA4091F1728D584A6AD24012D343fmsmsx115amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGF5aW5nIGZvciBjb2RlY3MgaXMgY29zdCBvZiBkb2luZyBidXNpbmVzcy4NCg0KLSAgICAgICAg ICBUaGUgd2hvbGUgVFYgZWNvc3lzdGVtIHVzZXMgTVBFRy0yLCBILjI2NCwgZXRjIC4uLiBNUEVH IG9yIERvbGJ5IGF1ZGlvIC4uLg0KDQotICAgICAgICAgIFRoZSB3aG9sZSBtb2JpbGUgcGhvbmUg ZWNvc3lzdGVtIHVzZXMgSC4yNjQsIEFNUiwgZXRjIOKApg0KDQotICAgICAgICAgIEFsbCBjYW1l cmFzIGFuZCBkaXNwbGF5cyB1c2Ugc3RhbmRhcmQgY29kZWNzDQoNCi0gICAgICAgICAgQWxtb3N0 IGFsbCBvbmxpbmUgY29udGVudCB0b2RheSBpcyB1c2luZyBzdGFuZGFyZCBjb2RlY3MNCg0KLSAg ICAgICAgICBQYXlpbmcgZm9yIGNvZGVjcyBwYXlzIGZvciByZXNlYXJjaCBsYWJzIHRvIGNvbnRp bnVlIHRoZWlyIHJlc2VhcmNoIHRvIGludmVudCBuZXcgdGhpbmdzDQoNCi0gICAgICAgICAgVGhl cmUgaXMgbm8gcGVyZm9ybWFudCBjb2RlYyB0b2RheSB0aGF0IGlzIDEwMCUgZ3VhcmFudGVlZCBy b3lhbHR5IGZyZWUg4oCTIHRoYXQgaXMgYSBtaXJhZ2UNCg0KDQoNClRoZSBwcm9ibGVtIEkgc2Vl IGlzIHRoYXQgTVBFRy1MQSBvciBvdGhlciBwYXRlbnQgcG9vbGluZyBvcmdhbml6YXRpb25zIGRv buKAmXQgdHlwaWNhbGx5IGhhdmUgYSBwcm92aXNpb24gZm9yIHNtYWxsIGFuZCBtZWRpdW0tc2l6 ZWQgYnVzaW5lc3NlcyBhcyB0aGV5IHByb2JhYmx5IGRvbuKAmXQgaGF2ZSBhIGRlZXAgSVAgcG9y dGZvbGlvIGluIHRoaXMgc3BhY2UuICBUaGF0IGlzIHRoZSBwcm9ibGVtIHRoYXQgc2hvdWxkIGJl IGZpeGVkIGdvaW5nIGZvcndhcmQuDQoNCi1jaHJpcw0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgRGF2aWQgU2luZ2VyDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAwOSwgMjAx NCAxMDo0NSBBTQ0KVG86IEFkYW0gUm9hY2gNCkNjOiBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbcnRjd2ViXSBWaWRlbyBjb2RlY3M6IENsZWFyIHBvc2l0aW9ucy4uLi4NCg0KDQoNCg0K DQo+IE9uIERlYyA5LCAyMDE0LCBhdCA5OjQ2ICwgQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNv bTxtYWlsdG86YWRhbUBub3N0cnVtLmNvbT4+IHdyb3RlOg0KDQo+DQoNCj4gT24gMTIvOS8xNCAx MTozMiwgRGF2aWQgU2luZ2VyIHdyb3RlOg0KDQo+PiBJIHdvdWxkIGFsc28gbGlrZSB0byBrbm93 IGZyb20gdGhvc2UgY29uZmlybWluZyB0aGUgc2Vuc2Ugb2YgdGhlIHJvb20sIHdoZXRoZXIgVEhF WSBUSEVNU0VMVkVTIGludGVuZCB0by4uLg0KDQo+DQoNCj4gV2FpdCwgeW91J3JlIHByZXNzaW5n IG90aGVyIGNvbXBhbmllcyBmb3IgZnV0dXJlIHByb2R1Y3QgcGxhbnM/IFdpdGggdGhlIGltcGxp Y2F0aW9uIHRoYXQgZG9pbmcgc28gaXMgYSBwcmVyZXF1aXNpdGUgdG8gcGFydGljaXBhdGluZyBp biB0aGUgZGlzY3Vzc2lvbj8NCg0KPg0KDQo+IFRoYXQncyBhIG1pZ2h0eSBzaGFycCBibGFkZSB0 aGVyZS4gWW91IG1pZ2h0IGNoZWNrIHdoZXJlIGl0J3MgcG9pbnRlZC4NCg0KDQoNClllcywgSSBy ZWFsaXplIHRoYXQgYWxtb3N0IG5vLW9uZSBjYW4gbWFrZSBwcm9taXNlcyBhYm91dCB3aGF0IHRo ZXkgd2lsbCBzaGlwLiBBbmQgc29tZSBjb21wYW5pZXMgd2lsbCBiZSBpbiBhIHBvc2l0aW9uIHdo ZXJlIHRoZXkgY2Fu4oCZdCBzYXkgYW55dGhpbmcuICBBbmQgeWVzLCBteSBjb21wYW55IGhhcyBh IHN0cmljdCBwb2xpY3kgb2Ygbm90IHByb21pc2luZyB3aGF0IHdlIHdpbGwgb3Igd29u4oCZdCBk byBpbiB0aGUgZnV0dXJlLiAgQnV0LCBoeXBvdGhldGljYWxseSwgaWYgdGhlIHN0YXRlbWVudCB3 YXMg4oCcbXVzdCBzdXBwb3J0IEguMjY04oCdIEkgY291bGQgY2xlYXJseSBpbmRpY2F0ZSB0aGF0 IHRoYXQgSSBleHBlY3QgaXQgdG8gYmUgdW5wcm9ibGVtYXRpYy4NCg0KDQoNCkJ1dCBzdXJlbHkg dGhvc2UgdGhhdCBzZWUgdGhlIGR1YWwgbWFuZGF0ZSBhcyB1bnByb2JsZW1hdGljIGZvciB0aGVt IHRvIGltcGxlbWVudCBjYW4gc2F5IHRoYXQsIGNhbuKAmXQgdGhleT8gIFN1cmVseSB3ZSBjYW4g c2VlIGF0IGxlYXN0IGEgcmVhc29uYWJsZSBudW1iZXIgb2Yg4oCceWVzLCB3ZSB3b3VsZCBob3Bl L2V4cGVjdC9pbnRlbmQgdG8gc2hpcCBib3Ro4oCdLCBhcyBhIG5vbi1iaW5kaW5nIGluZGljYXRp b24/DQoNCg0KDQpJIG1lYW4sIHRoZSBkcmFmdCDigJhtdXN0IGRvIGJvdGjigJkgd291bGQgcmVx dWlyZSBwZW9wbGUgd2hvIGhhdmUgYSBwcmluY2lwbGVkIG9iamVjdGlvbiB0byBwYXlpbmcgZmVl cywgaGF2aW5nIHRvIHBheSBmb3IgSC4yNjQuIEkgYW0gY3VyaW91cywgYXJlIHBlb3BsZSB3aWxs aW5nIHRvIGxldCB0aGVpciBwcmluY2lwbGVzIChhbmQgbW9uZXkpIGdvLCBpbiBvcmRlciB0byBj b21wbHkgd2l0aCB0aGUg4oCYbXVzdOKAmT8NCg0KDQoNCk9idmlvdXNseSwgSSBhbSB0cnlpbmcg dG8gYXNzZXNzIHdoZXRoZXIgdGhpcyBjb21wcm9taXNlIHdvdWxkLCBpbiBmYWN0LCBiZSBlZmZl Y3RpdmUgaW4gcHJhY3RpY2Ug4oCUIHdvdWxkIGVub3VnaCBwZW9wbGUgYWJpZGUgYnkgaXRzIGlu dGVudCB0aGF0IHdl4oCZZCBnZXQgdGhlIGludGVyb3BlcmFiaWxpdHkgdGhhdCBpcyB0aGUgcG9p bnQgb2YgdGhlIG1hbmRhdGU/ICBJIGRvbuKAmXQgd2FudCB0byBiZSBjaXRpbmcgUkZDIDY5MTkg Oi0pLg0KDQoNCg0KRGF2aWQgU2luZ2VyDQoNCk1hbmFnZXIsIFNvZnR3YXJlIFN0YW5kYXJkcywg QXBwbGUgSW5jLg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KcnRjd2ViIG1haWxpbmcgbGlzdA0KDQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWINCg== --_000_E36D1A4AE0B6AA4091F1728D584A6AD24012D343fmsmsx115amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJW ZXJkYW5hIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7 DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uUGxhaW5UZXh0 Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTc1NTY2ODY0 NjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjA3NDg3 NzA2OCAtNTYxMjM3ODg2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28t bGV2ZWwtc3RhcnQtYXQ6MTY7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QYXlpbmcgZm9yIGNvZGVjcyBpcyBjb3N0IG9mIGRvaW5n IGJ1c2luZXNzLiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZSB3aG9sZSBUViBlY29zeXN0ZW0gdXNlcyBN UEVHLTIsIEguMjY0LCBldGMgLi4uIE1QRUcgb3IgRG9sYnkgYXVkaW8gLi4uDQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3Rl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PlRoZSB3aG9sZSBtb2JpbGUgcGhvbmUgZWNvc3lzdGVtIHVzZXMgSC4yNjQsIEFNUiwgZXRjIOKA piA8bzpwPg0KPC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+QWxsIGNhbWVyYXMgYW5kIGRpc3BsYXlzIHVzZSBzdGFuZGFyZCBjb2Rl Y3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPkFsbW9zdCBhbGwgb25saW5lIGNvbnRlbnQgdG9kYXkgaXMgdXNpbmcgc3Rh bmRhcmQgY29kZWNzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5QYXlpbmcgZm9yIGNvZGVjcyBwYXlzIGZvciByZXNlYXJj aCBsYWJzIHRvIGNvbnRpbnVlIHRoZWlyIHJlc2VhcmNoIHRvIGludmVudCBuZXcgdGhpbmdzPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT5UaGVyZSBpcyBubyBwZXJmb3JtYW50IGNvZGVjIHRvZGF5IHRoYXQgaXMgMTAwJSBn dWFyYW50ZWVkIHJveWFsdHkgZnJlZSDigJMgdGhhdCBpcyBhIG1pcmFnZTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5UaGUgcHJvYmxlbSBJIHNlZSBpcyB0aGF0IE1QRUctTEEgb3Igb3Ro ZXIgcGF0ZW50IHBvb2xpbmcgb3JnYW5pemF0aW9ucyBkb27igJl0IHR5cGljYWxseSBoYXZlIGEg cHJvdmlzaW9uIGZvciBzbWFsbCBhbmQgbWVkaXVtLXNpemVkIGJ1c2luZXNzZXMgYXMgdGhleSBw cm9iYWJseSBkb27igJl0IGhhdmUgYSBkZWVwIElQIHBvcnRmb2xpbyBpbiB0aGlzIHNwYWNlLiZu YnNwOyBUaGF0IGlzIHRoZSBwcm9ibGVtIHRoYXQgc2hvdWxkDQogYmUgZml4ZWQgZ29pbmcgZm9y d2FyZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi1jaHJpczxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgRGF2aWQgU2luZ2VyPGJyPg0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDksIDIwMTQgMTA6 NDUgQU08YnI+DQpUbzogQWRhbSBSb2FjaDxicj4NCkNjOiBydGN3ZWJAaWV0Zi5vcmc8YnI+DQpT dWJqZWN0OiBSZTogW3J0Y3dlYl0gVmlkZW8gY29kZWNzOiBDbGVhciBwb3NpdGlvbnMuLi4uPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgT24gRGVjIDksIDIwMTQsIGF0IDk6NDYgLCBBZGFtIFJvYWNoICZsdDs8YSBo cmVmPSJtYWlsdG86YWRhbUBub3N0cnVtLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmFkYW1Abm9zdHJ1bS5jb208L3NwYW4+PC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBPbiAxMi85LzE0IDExOjMy LCBEYXZpZCBTaW5nZXIgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7Jmd0OyBJIHdvdWxkIGFsc28gbGlrZSB0byBrbm93IGZyb20gdGhvc2UgY29uZmly bWluZyB0aGUgc2Vuc2Ugb2YgdGhlIHJvb20sIHdoZXRoZXIgVEhFWSBUSEVNU0VMVkVTIGludGVu ZCB0by4uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgV2FpdCwgeW91J3JlIHBy ZXNzaW5nIG90aGVyIGNvbXBhbmllcyBmb3IgZnV0dXJlIHByb2R1Y3QgcGxhbnM/IFdpdGggdGhl IGltcGxpY2F0aW9uIHRoYXQgZG9pbmcgc28gaXMgYSBwcmVyZXF1aXNpdGUgdG8gcGFydGljaXBh dGluZyBpbiB0aGUgZGlzY3Vzc2lvbj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IFRoYXQncyBhIG1pZ2h0eSBzaGFycCBibGFkZSB0aGVyZS4gWW91IG1pZ2h0IGNoZWNrIHdoZXJl IGl0J3MgcG9pbnRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+WWVzLCBJIHJlYWxp emUgdGhhdCBhbG1vc3Qgbm8tb25lIGNhbiBtYWtlIHByb21pc2VzIGFib3V0IHdoYXQgdGhleSB3 aWxsIHNoaXAuIEFuZCBzb21lIGNvbXBhbmllcyB3aWxsIGJlIGluIGEgcG9zaXRpb24gd2hlcmUg dGhleSBjYW7igJl0IHNheSBhbnl0aGluZy4mbmJzcDsgQW5kIHllcywgbXkgY29tcGFueSBoYXMg YSBzdHJpY3QgcG9saWN5IG9mIG5vdCBwcm9taXNpbmcgd2hhdCB3ZSB3aWxsIG9yIHdvbuKAmXQg ZG8NCiBpbiB0aGUgZnV0dXJlLiZuYnNwOyBCdXQsIGh5cG90aGV0aWNhbGx5LCBpZiB0aGUgc3Rh dGVtZW50IHdhcyDigJxtdXN0IHN1cHBvcnQgSC4yNjTigJ0gSSBjb3VsZCBjbGVhcmx5IGluZGlj YXRlIHRoYXQgdGhhdCBJIGV4cGVjdCBpdCB0byBiZSB1bnByb2JsZW1hdGljLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5CdXQgc3VyZWx5IHRob3NlIHRoYXQgc2VlIHRoZSBkdWFsIG1h bmRhdGUgYXMgdW5wcm9ibGVtYXRpYyBmb3IgdGhlbSB0byBpbXBsZW1lbnQgY2FuIHNheSB0aGF0 LCBjYW7igJl0IHRoZXk/Jm5ic3A7IFN1cmVseSB3ZSBjYW4gc2VlIGF0IGxlYXN0IGEgcmVhc29u YWJsZSBudW1iZXIgb2Yg4oCceWVzLCB3ZSB3b3VsZCBob3BlL2V4cGVjdC9pbnRlbmQgdG8gc2hp cCBib3Ro4oCdLCBhcyBhIG5vbi1iaW5kaW5nIGluZGljYXRpb24/PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkkgbWVhbiwgdGhlIGRyYWZ0IOKAmG11c3QgZG8gYm90aOKAmSB3b3VsZCBy ZXF1aXJlIHBlb3BsZSB3aG8gaGF2ZSBhIHByaW5jaXBsZWQgb2JqZWN0aW9uIHRvIHBheWluZyBm ZWVzLCBoYXZpbmcgdG8gcGF5IGZvciBILjI2NC4gSSBhbSBjdXJpb3VzLCBhcmUgcGVvcGxlIHdp bGxpbmcgdG8gbGV0IHRoZWlyIHByaW5jaXBsZXMgKGFuZCBtb25leSkgZ28sIGluIG9yZGVyIHRv IGNvbXBseSB3aXRoIHRoZSDigJhtdXN04oCZPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5PYnZpb3VzbHksIEkgYW0gdHJ5aW5nIHRvIGFzc2VzcyB3aGV0aGVyIHRoaXMgY29tcHJvbWlz ZSB3b3VsZCwgaW4gZmFjdCwgYmUgZWZmZWN0aXZlIGluIHByYWN0aWNlIOKAlCB3b3VsZCBlbm91 Z2ggcGVvcGxlIGFiaWRlIGJ5IGl0cyBpbnRlbnQgdGhhdCB3ZeKAmWQgZ2V0IHRoZSBpbnRlcm9w ZXJhYmlsaXR5IHRoYXQgaXMgdGhlIHBvaW50IG9mIHRoZSBtYW5kYXRlPyZuYnNwOyBJIGRvbuKA mXQgd2FudCB0byBiZSBjaXRpbmcNCiBSRkMgNjkxOSA6LSkuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkRhdmlkIFNpbmdlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+TWFuYWdlciwgU29mdHdhcmUgU3RhbmRhcmRzLCBBcHBsZSBJbmMuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5ydGN3ZWIg bWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBo cmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+cnRjd2ViQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ydGN3ZWI8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_E36D1A4AE0B6AA4091F1728D584A6AD24012D343fmsmsx115amrcor_-- From nobody Tue Dec 9 11:13:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595081A6FE0 for ; Tue, 9 Dec 2014 11:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GUARANTEED_100_PERCENT=2.699, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SY5htFGbtko for ; Tue, 9 Dec 2014 11:13:22 -0800 (PST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 938841A1A6B for ; Tue, 9 Dec 2014 11:13:22 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 09 Dec 2014 11:13:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,546,1413270000"; d="scan'208,217";a="635150879" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by fmsmga001.fm.intel.com with ESMTP; 09 Dec 2014 11:13:22 -0800 Received: from orsmsx152.amr.corp.intel.com (10.22.226.39) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Dec 2014 11:13:22 -0800 Received: from fmsmsx153.amr.corp.intel.com (10.18.125.6) by ORSMSX152.amr.corp.intel.com (10.22.226.39) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 9 Dec 2014 11:13:21 -0800 Received: from fmsmsx115.amr.corp.intel.com ([169.254.4.149]) by FMSMSX153.amr.corp.intel.com ([169.254.9.209]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 11:13:21 -0800 From: "Cavigioli, Chris" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Video codecs: Clear positions.... Thread-Index: AQHQE9ZowNIQYgNYl0eTI4IK20km2pyIDo6AgAAQQYD//32nQIAABAtA Date: Tue, 9 Dec 2014 19:13:20 +0000 Message-ID: References: <5486C48D.8040602@alvestrand.no> <54873575.3030804@nostrum.com> <53ECE529-C011-4666-B044-226613CA263D@apple.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.106] Content-Type: multipart/alternative; boundary="_000_E36D1A4AE0B6AA4091F1728D584A6AD24012D3C2fmsmsx115amrcor_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Qxk_8TQF75PFS5PqdDfTf6Jm7Xc Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 19:13:25 -0000 --_000_E36D1A4AE0B6AA4091F1728D584A6AD24012D3C2fmsmsx115amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG8gYmUgY2xlYXIsIHRoZSBzdGF0ZW1lbnQgYmVsb3cgaXMgYSBDaHJpcyBDYXZpZ2lvbGkgc3Rh dGVtZW50LCBub3QgYW4gb2ZmaWNpYWwgc3RhdGVtZW50IGZyb20gbXkgZW1wbG95ZXIuICAgLWNo cmlzDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQ2F2aWdpb2xpLCBDaHJpcw0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDksIDIw MTQgMTE6MTIgQU0NClRvOiBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBW aWRlbyBjb2RlY3M6IENsZWFyIHBvc2l0aW9ucy4uLi4NCg0KDQpQYXlpbmcgZm9yIGNvZGVjcyBp cyBjb3N0IG9mIGRvaW5nIGJ1c2luZXNzLg0KDQotICAgICAgICAgIFRoZSB3aG9sZSBUViBlY29z eXN0ZW0gdXNlcyBNUEVHLTIsIEguMjY0LCBldGMgLi4uIE1QRUcgb3IgRG9sYnkgYXVkaW8gLi4u DQoNCi0gICAgICAgICAgVGhlIHdob2xlIG1vYmlsZSBwaG9uZSBlY29zeXN0ZW0gdXNlcyBILjI2 NCwgQU1SLCBldGMg4oCmDQoNCi0gICAgICAgICAgQWxsIGNhbWVyYXMgYW5kIGRpc3BsYXlzIHVz ZSBzdGFuZGFyZCBjb2RlY3MNCg0KLSAgICAgICAgICBBbG1vc3QgYWxsIG9ubGluZSBjb250ZW50 IHRvZGF5IGlzIHVzaW5nIHN0YW5kYXJkIGNvZGVjcw0KDQotICAgICAgICAgIFBheWluZyBmb3Ig Y29kZWNzIHBheXMgZm9yIHJlc2VhcmNoIGxhYnMgdG8gY29udGludWUgdGhlaXIgcmVzZWFyY2gg dG8gaW52ZW50IG5ldyB0aGluZ3MNCg0KLSAgICAgICAgICBUaGVyZSBpcyBubyBwZXJmb3JtYW50 IGNvZGVjIHRvZGF5IHRoYXQgaXMgMTAwJSBndWFyYW50ZWVkIHJveWFsdHkgZnJlZSDigJMgdGhh dCBpcyBhIG1pcmFnZQ0KDQoNCg0KVGhlIHByb2JsZW0gSSBzZWUgaXMgdGhhdCBNUEVHLUxBIG9y IG90aGVyIHBhdGVudCBwb29saW5nIG9yZ2FuaXphdGlvbnMgZG9u4oCZdCB0eXBpY2FsbHkgaGF2 ZSBhIHByb3Zpc2lvbiBmb3Igc21hbGwgYW5kIG1lZGl1bS1zaXplZCBidXNpbmVzc2VzIGFzIHRo ZXkgcHJvYmFibHkgZG9u4oCZdCBoYXZlIGEgZGVlcCBJUCBwb3J0Zm9saW8gaW4gdGhpcyBzcGFj ZS4gIFRoYXQgaXMgdGhlIHByb2JsZW0gdGhhdCBzaG91bGQgYmUgZml4ZWQgZ29pbmcgZm9yd2Fy ZC4NCg0KLWNocmlzDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcnRj d2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZpZCBT aW5nZXINClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDA5LCAyMDE0IDEwOjQ1IEFNDQpUbzogQWRh bSBSb2FjaA0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtydGN3ZWJdIFZpZGVvIGNvZGVjczogQ2xlYXIgcG9zaXRpb25zLi4uLg0KDQoN Cg0KDQoNCj4gT24gRGVjIDksIDIwMTQsIGF0IDk6NDYgLCBBZGFtIFJvYWNoIDxhZGFtQG5vc3Ry dW0uY29tPG1haWx0bzphZGFtQG5vc3RydW0uY29tPj4gd3JvdGU6DQoNCj4NCg0KPiBPbiAxMi85 LzE0IDExOjMyLCBEYXZpZCBTaW5nZXIgd3JvdGU6DQoNCj4+IEkgd291bGQgYWxzbyBsaWtlIHRv IGtub3cgZnJvbSB0aG9zZSBjb25maXJtaW5nIHRoZSBzZW5zZSBvZiB0aGUgcm9vbSwgd2hldGhl ciBUSEVZIFRIRU1TRUxWRVMgaW50ZW5kIHRvLi4uDQoNCj4NCg0KPiBXYWl0LCB5b3UncmUgcHJl c3Npbmcgb3RoZXIgY29tcGFuaWVzIGZvciBmdXR1cmUgcHJvZHVjdCBwbGFucz8gV2l0aCB0aGUg aW1wbGljYXRpb24gdGhhdCBkb2luZyBzbyBpcyBhIHByZXJlcXVpc2l0ZSB0byBwYXJ0aWNpcGF0 aW5nIGluIHRoZSBkaXNjdXNzaW9uPw0KDQo+DQoNCj4gVGhhdCdzIGEgbWlnaHR5IHNoYXJwIGJs YWRlIHRoZXJlLiBZb3UgbWlnaHQgY2hlY2sgd2hlcmUgaXQncyBwb2ludGVkLg0KDQoNCg0KWWVz LCBJIHJlYWxpemUgdGhhdCBhbG1vc3Qgbm8tb25lIGNhbiBtYWtlIHByb21pc2VzIGFib3V0IHdo YXQgdGhleSB3aWxsIHNoaXAuIEFuZCBzb21lIGNvbXBhbmllcyB3aWxsIGJlIGluIGEgcG9zaXRp b24gd2hlcmUgdGhleSBjYW7igJl0IHNheSBhbnl0aGluZy4gIEFuZCB5ZXMsIG15IGNvbXBhbnkg aGFzIGEgc3RyaWN0IHBvbGljeSBvZiBub3QgcHJvbWlzaW5nIHdoYXQgd2Ugd2lsbCBvciB3b27i gJl0IGRvIGluIHRoZSBmdXR1cmUuICBCdXQsIGh5cG90aGV0aWNhbGx5LCBpZiB0aGUgc3RhdGVt ZW50IHdhcyDigJxtdXN0IHN1cHBvcnQgSC4yNjTigJ0gSSBjb3VsZCBjbGVhcmx5IGluZGljYXRl IHRoYXQgdGhhdCBJIGV4cGVjdCBpdCB0byBiZSB1bnByb2JsZW1hdGljLg0KDQoNCg0KQnV0IHN1 cmVseSB0aG9zZSB0aGF0IHNlZSB0aGUgZHVhbCBtYW5kYXRlIGFzIHVucHJvYmxlbWF0aWMgZm9y IHRoZW0gdG8gaW1wbGVtZW50IGNhbiBzYXkgdGhhdCwgY2Fu4oCZdCB0aGV5PyAgU3VyZWx5IHdl IGNhbiBzZWUgYXQgbGVhc3QgYSByZWFzb25hYmxlIG51bWJlciBvZiDigJx5ZXMsIHdlIHdvdWxk IGhvcGUvZXhwZWN0L2ludGVuZCB0byBzaGlwIGJvdGjigJ0sIGFzIGEgbm9uLWJpbmRpbmcgaW5k aWNhdGlvbj8NCg0KDQoNCkkgbWVhbiwgdGhlIGRyYWZ0IOKAmG11c3QgZG8gYm90aOKAmSB3b3Vs ZCByZXF1aXJlIHBlb3BsZSB3aG8gaGF2ZSBhIHByaW5jaXBsZWQgb2JqZWN0aW9uIHRvIHBheWlu ZyBmZWVzLCBoYXZpbmcgdG8gcGF5IGZvciBILjI2NC4gSSBhbSBjdXJpb3VzLCBhcmUgcGVvcGxl IHdpbGxpbmcgdG8gbGV0IHRoZWlyIHByaW5jaXBsZXMgKGFuZCBtb25leSkgZ28sIGluIG9yZGVy IHRvIGNvbXBseSB3aXRoIHRoZSDigJhtdXN04oCZPw0KDQoNCg0KT2J2aW91c2x5LCBJIGFtIHRy eWluZyB0byBhc3Nlc3Mgd2hldGhlciB0aGlzIGNvbXByb21pc2Ugd291bGQsIGluIGZhY3QsIGJl IGVmZmVjdGl2ZSBpbiBwcmFjdGljZSDigJQgd291bGQgZW5vdWdoIHBlb3BsZSBhYmlkZSBieSBp dHMgaW50ZW50IHRoYXQgd2XigJlkIGdldCB0aGUgaW50ZXJvcGVyYWJpbGl0eSB0aGF0IGlzIHRo ZSBwb2ludCBvZiB0aGUgbWFuZGF0ZT8gIEkgZG9u4oCZdCB3YW50IHRvIGJlIGNpdGluZyBSRkMg NjkxOSA6LSkuDQoNCg0KDQpEYXZpZCBTaW5nZXINCg0KTWFuYWdlciwgU29mdHdhcmUgU3RhbmRh cmRzLCBBcHBsZSBJbmMuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KDQpydGN3ZWIgbWFpbGluZyBsaXN0DQoNCnJ0Y3dlYkBpZXRmLm9yZzxt YWlsdG86cnRjd2ViQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Y3dlYg0K --_000_E36D1A4AE0B6AA4091F1728D584A6AD24012D3C2fmsmsx115amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9z ZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFo b21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRl eHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QbGFpblRl eHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDoxNzU1NjY4NjQ2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczoyMDc0ODc3MDY4IC01NjEyMzc4ODYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoxNjsNCgltc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q29u c29sYXM7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VG8gYmUgY2xlYXIsIHRoZSBzdGF0ZW1lbnQgYmVsb3cg aXMgYSBDaHJpcyBDYXZpZ2lvbGkgc3RhdGVtZW50LCBub3QgYW4gb2ZmaWNpYWwgc3RhdGVtZW50 IGZyb20gbXkgZW1wbG95ZXIuJm5ic3A7Jm5ic3A7IC1jaHJpczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBy dGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+Q2F2aWdpb2xpLCBDaHJpczxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBEZWNlbWJlciAw OSwgMjAxNCAxMToxMiBBTTxicj4NCjxiPlRvOjwvYj4gcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBWaWRlbyBjb2RlY3M6IENsZWFyIHBvc2l0aW9ucy4u Li48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QYXlp bmcgZm9yIGNvZGVjcyBpcyBjb3N0IG9mIGRvaW5nIGJ1c2luZXNzLiZuYnNwOyA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3Rl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PlRoZSB3aG9sZSBUViBlY29zeXN0ZW0gdXNlcyBNUEVHLTIsIEguMjY0LCBldGMgLi4uIE1QRUcg b3IgRG9sYnkgYXVkaW8gLi4uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps MCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZSB3aG9sZSBtb2JpbGUgcGhvbmUgZWNv c3lzdGVtIHVzZXMgSC4yNjQsIEFNUiwgZXRjIOKApiA8bzpwPg0KPC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4y NWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QWxsIGNhbWVyYXMg YW5kIGRpc3BsYXlzIHVzZSBzdGFuZGFyZCBjb2RlY3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkFsbW9zdCBhbGwgb25s aW5lIGNvbnRlbnQgdG9kYXkgaXMgdXNpbmcgc3RhbmRhcmQgY29kZWNzPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5QYXlp bmcgZm9yIGNvZGVjcyBwYXlzIGZvciByZXNlYXJjaCBsYWJzIHRvIGNvbnRpbnVlIHRoZWlyIHJl c2VhcmNoIHRvIGludmVudCBuZXcgdGhpbmdzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGVyZSBpcyBubyBwZXJmb3Jt YW50IGNvZGVjIHRvZGF5IHRoYXQgaXMgMTAwJSBndWFyYW50ZWVkIHJveWFsdHkgZnJlZSDigJMg dGhhdCBpcyBhIG1pcmFnZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgcHJvYmxl bSBJIHNlZSBpcyB0aGF0IE1QRUctTEEgb3Igb3RoZXIgcGF0ZW50IHBvb2xpbmcgb3JnYW5pemF0 aW9ucyBkb27igJl0IHR5cGljYWxseSBoYXZlIGEgcHJvdmlzaW9uIGZvciBzbWFsbCBhbmQgbWVk aXVtLXNpemVkIGJ1c2luZXNzZXMgYXMgdGhleSBwcm9iYWJseSBkb27igJl0IGhhdmUgYSBkZWVw IElQIHBvcnRmb2xpbyBpbiB0aGlzIHNwYWNlLiZuYnNwOyBUaGF0IGlzIHRoZSBwcm9ibGVtIHRo YXQgc2hvdWxkDQogYmUgZml4ZWQgZ29pbmcgZm9yd2FyZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPi1jaHJpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IHJ0Y3dlYiBbPGEgaHJlZj0ibWFp bHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XSBPbiBCZWhhbGYgT2YgRGF2aWQgU2luZ2VyPGJyPg0KU2VudDogVHVlc2RheSwgRGVj ZW1iZXIgMDksIDIwMTQgMTA6NDUgQU08YnI+DQpUbzogQWRhbSBSb2FjaDxicj4NCkNjOiA8YSBo cmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KU3Vi amVjdDogUmU6IFtydGN3ZWJdIFZpZGVvIGNvZGVjczogQ2xlYXIgcG9zaXRpb25zLi4uLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgT24gRGVjIDksIDIwMTQsIGF0IDk6NDYgLCBBZGFtIFJvYWNo ICZsdDs8YSBocmVmPSJtYWlsdG86YWRhbUBub3N0cnVtLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmFkYW1Abm9zdHJ1bS5jb208L3NwYW4+ PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBPbiAxMi85 LzE0IDExOjMyLCBEYXZpZCBTaW5nZXIgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7Jmd0OyBJIHdvdWxkIGFsc28gbGlrZSB0byBrbm93IGZyb20gdGhv c2UgY29uZmlybWluZyB0aGUgc2Vuc2Ugb2YgdGhlIHJvb20sIHdoZXRoZXIgVEhFWSBUSEVNU0VM VkVTIGludGVuZCB0by4uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgV2FpdCwg eW91J3JlIHByZXNzaW5nIG90aGVyIGNvbXBhbmllcyBmb3IgZnV0dXJlIHByb2R1Y3QgcGxhbnM/ IFdpdGggdGhlIGltcGxpY2F0aW9uIHRoYXQgZG9pbmcgc28gaXMgYSBwcmVyZXF1aXNpdGUgdG8g cGFydGljaXBhdGluZyBpbiB0aGUgZGlzY3Vzc2lvbj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mZ3Q7IFRoYXQncyBhIG1pZ2h0eSBzaGFycCBibGFkZSB0aGVyZS4gWW91IG1pZ2h0IGNo ZWNrIHdoZXJlIGl0J3MgcG9pbnRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+WWVz LCBJIHJlYWxpemUgdGhhdCBhbG1vc3Qgbm8tb25lIGNhbiBtYWtlIHByb21pc2VzIGFib3V0IHdo YXQgdGhleSB3aWxsIHNoaXAuIEFuZCBzb21lIGNvbXBhbmllcyB3aWxsIGJlIGluIGEgcG9zaXRp b24gd2hlcmUgdGhleSBjYW7igJl0IHNheSBhbnl0aGluZy4mbmJzcDsgQW5kIHllcywgbXkgY29t cGFueSBoYXMgYSBzdHJpY3QgcG9saWN5IG9mIG5vdCBwcm9taXNpbmcgd2hhdCB3ZSB3aWxsIG9y IHdvbuKAmXQgZG8NCiBpbiB0aGUgZnV0dXJlLiZuYnNwOyBCdXQsIGh5cG90aGV0aWNhbGx5LCBp ZiB0aGUgc3RhdGVtZW50IHdhcyDigJxtdXN0IHN1cHBvcnQgSC4yNjTigJ0gSSBjb3VsZCBjbGVh cmx5IGluZGljYXRlIHRoYXQgdGhhdCBJIGV4cGVjdCBpdCB0byBiZSB1bnByb2JsZW1hdGljLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5CdXQgc3VyZWx5IHRob3NlIHRoYXQgc2VlIHRo ZSBkdWFsIG1hbmRhdGUgYXMgdW5wcm9ibGVtYXRpYyBmb3IgdGhlbSB0byBpbXBsZW1lbnQgY2Fu IHNheSB0aGF0LCBjYW7igJl0IHRoZXk/Jm5ic3A7IFN1cmVseSB3ZSBjYW4gc2VlIGF0IGxlYXN0 IGEgcmVhc29uYWJsZSBudW1iZXIgb2Yg4oCceWVzLCB3ZSB3b3VsZCBob3BlL2V4cGVjdC9pbnRl bmQgdG8gc2hpcCBib3Ro4oCdLCBhcyBhIG5vbi1iaW5kaW5nIGluZGljYXRpb24/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPkkgbWVhbiwgdGhlIGRyYWZ0IOKAmG11c3QgZG8gYm90aOKA mSB3b3VsZCByZXF1aXJlIHBlb3BsZSB3aG8gaGF2ZSBhIHByaW5jaXBsZWQgb2JqZWN0aW9uIHRv IHBheWluZyBmZWVzLCBoYXZpbmcgdG8gcGF5IGZvciBILjI2NC4gSSBhbSBjdXJpb3VzLCBhcmUg cGVvcGxlIHdpbGxpbmcgdG8gbGV0IHRoZWlyIHByaW5jaXBsZXMgKGFuZCBtb25leSkgZ28sIGlu IG9yZGVyIHRvIGNvbXBseSB3aXRoIHRoZSDigJhtdXN04oCZPzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5PYnZpb3VzbHksIEkgYW0gdHJ5aW5nIHRvIGFzc2VzcyB3aGV0aGVyIHRoaXMg Y29tcHJvbWlzZSB3b3VsZCwgaW4gZmFjdCwgYmUgZWZmZWN0aXZlIGluIHByYWN0aWNlIOKAlCB3 b3VsZCBlbm91Z2ggcGVvcGxlIGFiaWRlIGJ5IGl0cyBpbnRlbnQgdGhhdCB3ZeKAmWQgZ2V0IHRo ZSBpbnRlcm9wZXJhYmlsaXR5IHRoYXQgaXMgdGhlIHBvaW50IG9mIHRoZSBtYW5kYXRlPyZuYnNw OyBJIGRvbuKAmXQgd2FudCB0byBiZSBjaXRpbmcNCiBSRkMgNjkxOSA6LSkuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkRhdmlkIFNpbmdlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+TWFuYWdlciwgU29mdHdhcmUgU3RhbmRhcmRzLCBBcHBsZSBJbmMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5ydGN3ZWIgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+cnRjd2ViQGlldGYub3JnPC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIj48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E36D1A4AE0B6AA4091F1728D584A6AD24012D3C2fmsmsx115amrcor_-- From nobody Tue Dec 9 11:20:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3126E1A1A2F for ; Tue, 9 Dec 2014 11:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhzKR2t5iAO5 for ; Tue, 9 Dec 2014 11:20:15 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6ED1A1A0B for ; Tue, 9 Dec 2014 11:20:15 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB9JK678094398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2014 13:20:07 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54874B66.5050700@nostrum.com> Date: Tue, 09 Dec 2014 13:20:06 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Bernard Aboba References: <5486C48D.8040602@alvestrand.no> <54873575.3030804@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010004030201060002040409" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sxbJ2_vknSmZ1b4hSTVVW7zMbXc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 19:20:20 -0000 This is a multi-part message in MIME format. --------------010004030201060002040409 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/9/14 13:08, Bernard Aboba wrote: > [BA] I agree that the vast majority of people answering probably > believe that the requirements don't apply to the non-browser category, > but actually the proposal is that dual MTI does apply to non-browsers, > right? It's just the WebRTC-compatible endpoints that are exempt. So > it's actually worse than "those other people should do it" - it's > really "I intend to ignore the requirements myself and pretend that > they don't apply to me while holding other people to them". So, even though no one has stood up and said as much, you're hypothesizing that some vast majority of people who disagree with you must be doing so only because they're bad actors? I think you need more evidence than what amounts to a conspiracy theory if you're going to level that kind of accusation. /a --------------010004030201060002040409 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/9/14 13:08, Bernard Aboba wrote:
[BA] I agree that the vast majority of people answering probably believe that the requirements don't apply to the non-browser category, but actually the proposal is that dual MTI does apply to non-browsers, right? It's just the WebRTC-compatible endpoints that are exempt.  So it's actually worse than "those other people should do it" - it's really "I intend to ignore the requirements myself and pretend that they don't apply to me while holding other people to  them".

So, even though no one has stood up and said as much, you're hypothesizing that some vast majority of people who disagree with you must be doing so only because they're bad actors? I think you need more evidence than what amounts to a conspiracy theory if you're going to level that kind of accusation.

/a
--------------010004030201060002040409-- From nobody Tue Dec 9 11:31:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415E71A6EDE for ; Tue, 9 Dec 2014 11:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsy0YhHq5LWw for ; Tue, 9 Dec 2014 11:31:23 -0800 (PST) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE241A1AAA for ; Tue, 9 Dec 2014 11:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418153483; x=2282067083; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0pAaWOkyt8g6+J4OjtbMBUBi6afsr5E5QEMWbvjS51I=; b=zQ2oQUimupyt75uQCMduEQf/TCNS37Gz1UwqYMKBmknElDPtFj6CF02HCe7sQGiq fhAggrO2enzOPRR2pgjLUk15DWfZNfpMAysGh1snypZy7RY0G9gL8SQJOV/JGfZi uQXmo0wgUSW765WjhncFv8tS4RQdg5tuC24LElOsflx76aI9eo+uXW2c4mAorJgL 5UxGE9DruAIYGpdOz7OFKa3ox3HCTtDsECpS1dQ6rEmMtPMh5zqCSTpgZv2gbSeA JdLFp8Rfi7SZV/53yiqWrQ3EbL85E/C9TAKxj95YVMxG4wlTDl8HE2SZxNwJSbTh YtUnsX5K4qrN7XIuv/a6vg==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id AA.B5.26546.B0E47845; Tue, 9 Dec 2014 11:31:23 -0800 (PST) X-AuditID: 11973e11-f79af6d0000067b2-73-54874e0b5498 Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 16.C0.06091.BED47845; Tue, 9 Dec 2014 11:30:51 -0800 (PST) Received: from [17.153.29.83] (unknown [17.153.29.83]) by chive.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGB00DMIY89FJ90@chive.apple.com> for rtcweb@ietf.org; Tue, 09 Dec 2014 11:31:23 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <54874B66.5050700@nostrum.com> Date: Tue, 09 Dec 2014 11:31:23 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <5486C48D.8040602@alvestrand.no> <54873575.3030804@nostrum.com> <54874B66.5050700@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUi2FCYqsvt1x5icOGnjMXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuHTTvOA9f8WWZpUGxhs8XYycHBICJhJ9jxYwQdhiEhfurWfr YuTiEBLYxyjx5foaNpiii9+uskIkupkk5sxpZ4Jzvr6bxtLFyMHBLKAuMWVKLkgDr4CeRNOT x2BThQXMJTZ2HWEGsdkEVCUezDnGCGJzCmhL9M1oB1vAAhSf9fsImM0sUCMxt/MmK4StLfHk 3QVWiJk2Eo82HACzhQReMEp0PuEEsUUEFCXaDt9khjhUVuLfxTPsILdJCLxklZh/cQbrBEbh WQjnzUJy3iwkKxYwMq9iFMpNzMzRzcwz0kssKMhJ1UvOz93ECArh6XaCOxiPr7I6xCjAwajE w6th2RYixJpYVlyZe4hRmoNFSZz3hg1QSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+Pn+Sax am+XPRP7ErdrXZLI3ZiJE7fqLPizKVn48rZ/R7cp9qmd1tpqfV5H+sCNbd7hPK8tJj05NbFe 83/yEY/LD943Oh+LnP/7iuL9VdJ9n31Mu+3dDx21OJ/mrrL8RwhLv8He15qv/k/4dsM2gG/v x0f36nyKrh1s2rJk/+ZrDesuvTkjP8vqhxJLcUaioRZzUXEiADj4+cJCAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUi2FDMr/vatz3E4OwdFYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcemmecF7/ootzSoNjDd4uhg5OSQETCQufrvKCmGLSVy4t56t i5GLQ0igm0lizpx2Jjjn67tpLF2MHBzMAuoSU6bkgjTwCuhJND15zARiCwuYS2zsOsIMYrMJ qEo8mHOMEcTmFNCW6JvRzgZiswDFZ/0+AmYzC9RIzO28yQpha0s8eXeBFWKmjcSjDQfAbCGB F4wSnU84QWwRAUWJtsM3mSEOlZX4d/EM+wRGgVkIF81CctEsJFMXMDKvYhQoSs1JrDTXSywo yEnVS87P3cQIDrnC1B2MjcutDjEKcDAq8fBqWLaFCLEmlhVX5h5ilOBgVhLhXcvSHiLEm5JY WZValB9fVJqTWnyIUZqDRUmcN+RdY4iQQHpiSWp2ampBahFMlomDU6qB8bzIE93f27rnvdnt sCiR2VZOU1DztnbIz5p095s+jvX3j3VfumP8fa+wyRZjji3z53M+n/5jWqTJP0f2EokZP1a8 +bDc/otBctPV7dk7MqZ+6tM8eDKbL+PljaniEatilBMnOrBOKe14vTTyv4TIx0TPYr5CTaFi s1U34qbqOiYd/Fz5yJzfUYmlOCPRUIu5qDgRAN7D6L01AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3hdMcsrlCUe8H8QRcPgCxLrVZYA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 19:31:25 -0000 > On Dec 9, 2014, at 11:20 , Adam Roach wrote: >=20 > On 12/9/14 13:08, Bernard Aboba wrote: >> [BA] I agree that the vast majority of people answering probably = believe that the requirements don't apply to the non-browser category, = but actually the proposal is that dual MTI does apply to non-browsers, = right? It's just the WebRTC-compatible endpoints that are exempt. So = it's actually worse than "those other people should do it" - it's really = "I intend to ignore the requirements myself and pretend that they don't = apply to me while holding other people to them". >=20 > So, even though no one has stood up and said as much, you're = hypothesizing that some vast majority of people who disagree with you = must be doing so only because they're bad actors? I think you need more = evidence than what amounts to a conspiracy theory if you're going to = level that kind of accusation. Jeepers, guys, do we have to resort to this kind of language? =20 I honestly DO NOT KNOW how many endpoints, of any kind, would expect to = support both codecs. Getting a rough sense of that would be really = useful. Happily I don=E2=80=99t need to care about why people land where = they do, how conspiratorial, deceitful, or anything they may be. In = fact, I expect most people are trying to do their best, balancing = everything. But I don=E2=80=99t know what that means. That=E2=80=99s why I said that saying that a WebRTC implementation, in a = browser, is not a WebRTC Browser but a WebRTC-Compatible Endpoint, = though formally possible, is questionable =E2=80=94 it would appear to = be skirting the intent of the spec. For example, I *think* that Firefox would if H.264 is either available = on the platform, or available via the Cisco download for that platform. = So if I am right, they get pretty close. Beyond that, who knows? So, please, can we assume people are trying to do the best they can? David Singer Manager, Software Standards, Apple Inc. From nobody Tue Dec 9 11:31:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE1E1A6EDE for ; Tue, 9 Dec 2014 11:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xI4eyDevk8hR for ; Tue, 9 Dec 2014 11:31:37 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E61F41A87BC for ; Tue, 9 Dec 2014 11:31:35 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so2863776wiv.13 for ; Tue, 09 Dec 2014 11:31:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zPJbHaMatrqFtaPOjNAMPdoNVPCXUPQ8fWP7mI6cNTY=; b=MSuLhjTyum4vvyC/iWFNBmY2LNouwvnigW2sl7ZttRy/ZrrvxgKFPWgc0NlMoCOKCS FVfKTW0W5x+3e6NhCEMHmbE3qx1UBk0nnQB/62QPqi+cR8TROhQjy9ItyoyrjEP47sbq eHSos6z+lPVzv7T4xmyhVDhjv8aZXPlDYTGNZPOrxrpfzFuecONpSmFYxaNuIdw5ViqS JopJAOihxapaB2VTeXCWLLrdW0apoXfU/CkXo8UTjZZD0yGsggMSlncW0PbWb1+ZcDGI p4quLQG/1g/K11FRX/qjMONU8VheILnuw8L7JiuG1TniGWFvIBMDd9fcvVf7NwbAPFpx qtbQ== X-Gm-Message-State: ALoCoQmNx5cURzMNHUFFCgPAWRPBd3kKWcbmNSbK0hII8WvBJ+cZvgPGeFBgxd5sfoYQD5VcMmo8 MIME-Version: 1.0 X-Received: by 10.195.11.6 with SMTP id ee6mr7670178wjd.95.1418153494641; Tue, 09 Dec 2014 11:31:34 -0800 (PST) Received: by 10.194.6.39 with HTTP; Tue, 9 Dec 2014 11:31:34 -0800 (PST) Received: by 10.194.6.39 with HTTP; Tue, 9 Dec 2014 11:31:34 -0800 (PST) In-Reply-To: References: <5486C48D.8040602@alvestrand.no> Date: Tue, 9 Dec 2014 21:31:34 +0200 Message-ID: From: Mohammed Raad To: David Singer Content-Type: multipart/alternative; boundary=047d7bae4666491cd70509cd978a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/A4Gxb4irWaZAWAoPrLCnEb9BmHs Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 19:31:42 -0000 --047d7bae4666491cd70509cd978a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You know, that's a very strange path to take. I mean it really does sound like attempting to come to an agreement regarding what features future products should have by limiting participation in this technical decision process to those committed to deploy specific technologies. I think you ought to read the definition of anti competitive practice again. Mohammed On 9 Dec 2014 19:32, "David Singer" wrote: > > > On Dec 9, 2014, at 1:44 , Harald Alvestrand > wrote: > > > > I note that the "confirming sense of the room" thread has gotten a lot > > of messages that are not declaring a position on the question. > > > > I also note that from the messages on the thread, I can't figure out if > > Keith Drage, Gili, Monty Montgomery or Peter Saint-Andre have taken a > > position (I could guess, but I don't want to - besides, they might not > > want to take a position, which is perfectly OK). > > > > It would be nice for me as a reader if people could: > > > > - state their position on the "confirming sense of the room" thread > > - change the subject line when they want to say anything else > > > > That's my preference - of course, people who have "mute thread" in thei= r > > email readers might want the whole discussion to stay on thread, and > > will hate me for the last suggestion.... > > > > Harald > > Thanks, Harald, that would help. > > I would also like to know from those confirming the sense of the room, > whether THEY THEMSELVES intend to implement both codecs, or whether they > conveniently think they don=E2=80=99t need to, and it=E2=80=99s just a pr= oblem for other > people to handle. > > Honestly, a +1 for =E2=80=9Cthose other people should do it=E2=80=9D is m= eaningless. > > David Singer > Manager, Software Standards, Apple Inc. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7bae4666491cd70509cd978a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

You know, that's a very strange path to take. I mean it = really does sound like attempting to come to an agreement regarding what fe= atures future products should have by limiting participation in this techni= cal decision process to those committed to deploy specific technologies. I = think you ought to read the definition of anti competitive practice again.<= /p>

Mohammed

On 9 Dec 2014 19:32, "David Singer" &l= t;singer@apple.com> wrote:

> On Dec 9, 2014, at 1:44 , Harald Alvestrand <harald@alvestrand.no> wrote:
>
> I note that the "confirming sense of the room" thread has go= tten a lot
> of messages that are not declaring a position on the question.
>
> I also note that from the messages on the thread, I can't figure o= ut if
> Keith Drage, Gili, Monty Montgomery or Peter Saint-Andre have taken a<= br> > position (I could guess, but I don't want to - besides, they might= not
> want to take a position, which is perfectly OK).
>
> It would be nice for me as a reader if people could:
>
> - state their position on the "confirming sense of the room"= thread
> - change the subject line when they want to say anything else
>
> That's my preference - of course, people who have "mute threa= d" in their
> email readers might want the whole discussion to stay on thread, and > will hate me for the last suggestion....
>
> Harald

Thanks, Harald, that would help.

I would also like to know from those confirming the sense of the room, whet= her THEY THEMSELVES intend to implement both codecs, or whether they conven= iently think they don=E2=80=99t need to, and it=E2=80=99s just a problem fo= r other people to handle.

Honestly, a +1 for =E2=80=9Cthose other people should do it=E2=80=9D is mea= ningless.

David Singer
Manager, Software Standards, Apple Inc.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--047d7bae4666491cd70509cd978a-- From nobody Tue Dec 9 11:35:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A691A87C3 for ; Tue, 9 Dec 2014 11:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEoxWuT_e-lP for ; Tue, 9 Dec 2014 11:35:07 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 351FB1A0075 for ; Tue, 9 Dec 2014 11:35:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418153706; x=2282067306; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BTM9IFRBbH3iyEvhhldAEkEvlsEOsEd6CRitgrEMSVo=; b=C/4WaO4ALY4MHHD9pjQXjImGaUMzPVqEZshj002GANxWwecBDjZjErpDhsG/2WtF 3A68a9q/0xMNST325Mz5BngtzrxYaTuhHYitwrzXlibZMjGOoOdpZPofClNRNHLd 8c00vjbj29mgnMCzqKAFQ12H+/vrwq8HzHqxIj9Cv2OSgo7yDrEKj86ieJFdfeV0 +CNhmJNqgPsWxVmDpu5JZQ6sUB5Bt208bQl/3xspQCvZ35UFITTJwLCZJEQdpKXj Bj1BPhAkLxah2biIKap2dwqzC4rWRubvzbSNy4fh6jVbO00ZXqDClO5Ozlhjevz0 0m5XUarI/EMT94CdcwXRPA==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id FD.DF.12074.AEE47845; Tue, 9 Dec 2014 11:35:06 -0800 (PST) X-AuditID: 11973e12-f79f86d000002f2a-17-54874eea4758 Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 07.61.05858.4EE47845; Tue, 9 Dec 2014 11:35:00 -0800 (PST) Received: from [17.153.29.83] (unknown [17.153.29.83]) by chive.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGB00K00YEF2970@chive.apple.com> for rtcweb@ietf.org; Tue, 09 Dec 2014 11:35:05 -0800 (PST) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: Date: Tue, 09 Dec 2014 11:35:05 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <5486C48D.8040602@alvestrand.no> To: Mohammed Raad X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUi2FDorPvKrz3E4PIjM4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcbWtm6lgLXvFtQ+LGRsYX7B2MXJySAiYSPQdPsAOYYtJXLi3 nq2LkYtDSGAvo8S/9XfYYIp6Nk1ggkh0M0lsXrwZwbn4eitYFbOAlsT6nceZQGxeAT2JpieP wWxhAXOJjV1HmEFsNgFViQdzjjGC2JwCwRLHt14Es1mA4g0HHrBAzLGV2HPrK9RMbYkn7y6w Qsy0kdj28C+YLSSwjFHi95Q8EFsEaNfVt9uhLpWV+HfxDDvIcRICT1klJvRcYJnAKDwLyX2z kNw3C8mOBYzMqxiFchMzc3Qz80z0EgsKclL1kvNzNzGCQnm6ndAOxlOrrA4xCnAwKvHwali2 hQixJpYVV+YeYpTmYFES571pAxQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAOKHs6I2wn74H D3s77p/AU6jsK8K9TjL+/5WyoJ0CW068XKE0362mXXTrNZM5h31/+n07tElu64ZyMSPRbK+p 9e3T5wsG1G8qPyfGsdE0QHwqh1kxQ0+3+isjp+Swkg2bH7M9WP9fou/h/TJm0Wcnmx7kM6Wl BvP+tfzSGquXpSlx6+3y4+u8lFiKMxINtZiLihMBgmHyDEYCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUi2FDMr/vErz3EYMdGeYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcbWtm6lgLXvFtQ+LGRsYX7B2MXJySAiYSPRsmsAEYYtJXLi3 nq2LkYtDSKCbSWLz4s1McM7F11vZQKqYBbQk1u88DtbBK6An0fTkMZgtLGAusbHrCDOIzSag KvFgzjFGEJtTIFji+NaLYDYLULzhwAMWiDm2EntufYWaqS3x5N0FVoiZNhLbHv4Fs4UEljFK /J6SB2KLAO26+nY7G8SlshL/Lp5hn8AoMAvJSbOQnDQLydgFjMyrGAWKUnMSK430EgsKclL1 kvNzNzGCQ6/QeQfjsWVWhxgFOBiVeHg1LNtChFgTy4orcw8xSnAwK4nwrmVpDxHiTUmsrEot yo8vKs1JLT7EKM3BoiTOm/OuMURIID2xJDU7NbUgtQgmy8TBKdXAaPhQfd8W4/Jvi/+fr5y5 Vf4ff8VFt2bef2k6LzpY5i/648QR9/joDl4/k4v5NyOUwi+9k8vmFlt0e3ntPi4FtbTnBp/a qngYK5LYbd13Wl3dNf/ggqcKxd0h2yd58V+bF7bcI/dSmsUdifmqWhdEJsl754hL+tfFHdl2 OnmFNmtSP1ez/eI/SizFGYmGWsxFxYkAUFzqazkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eiVh81P3nRneegPZohK6njoJpWA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 19:35:08 -0000 > On Dec 9, 2014, at 11:31 , Mohammed Raad = wrote: >=20 > You know, that's a very strange path to take. I mean it really does = sound like attempting to come to an agreement regarding what features = future products should have by limiting participation in this technical = decision process to those committed to deploy specific technologies. I = think you ought to read the definition of anti competitive practice = again. Please be respectful of your language. I am trying to find out a simple answer: how many endpoints would, in = fact, expect to support both codecs? I am not trying to limit participation. I am trying to find out whether = we would actually get the purported effect. If all the people humming yes make webrtc-compatible endpoints, we do = not get the effect we want. Is it that hard to see that? David Singer Manager, Software Standards, Apple Inc. From nobody Tue Dec 9 11:50:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B171A036B for ; Tue, 9 Dec 2014 11:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuJUpIPTaQhc for ; Tue, 9 Dec 2014 11:50:34 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002-out2.apm-internet.net [85.119.248.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8E91A0248 for ; Tue, 9 Dec 2014 11:50:34 -0800 (PST) Received: (qmail 70296 invoked from network); 9 Dec 2014 19:50:32 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 13846 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 9 Dec 2014 19:50:32 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id CCFCE18A150B; Tue, 9 Dec 2014 19:50:26 +0000 (GMT) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id AF24A18A0AC9; Tue, 9 Dec 2014 19:50:26 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0B8A542D-D3E9-46B1-9991-EED40BBAE134" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Tim Panton In-Reply-To: Date: Tue, 9 Dec 2014 19:50:25 +0000 Message-Id: <9BDCD7D8-B274-4970-A01B-D31069AEA935@phonefromhere.com> References: <5486C48D.8040602@alvestrand.no> <54873575.3030804@nostrum.com> <54874B66.5050700@nostrum.com> To: David Singer X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/SIWfk6AI2TbHm1it7Kt8Wmh8rYI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 19:50:36 -0000 --Apple-Mail=_0B8A542D-D3E9-46B1-9991-EED40BBAE134 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 9 Dec 2014, at 19:31, David Singer > wrote: >=20 > That=E2=80=99s why I said that saying that a WebRTC implementation, in = a browser, is not a WebRTC Browser but a WebRTC-Compatible Endpoint, = though formally possible, is questionable =E2=80=94 it would appear to = be skirting the intent of the spec. I=E2=80=99m deeply confused by that remark. To answer the question I = think you are asking, (i.e. =E2=80=99can you show me a non-browser = webrtc compliant endpoint?'). The best example I can think of that is = public is E/// =E2=80=99s openwebRTC - which implements both codecs, but = doesn=E2=80=99t implement a browser or the w3C javascript API. - Note = that they leave the issue of h264 licence fees to the app developer to = sort out (although they plan to let it use native os exposed codecs and = ride that license I think) Or did I misunderstand? Tim. --Apple-Mail=_0B8A542D-D3E9-46B1-9991-EED40BBAE134 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 9 Dec 2014, at 19:31, David Singer <singer@apple.com> = wrote:


That=E2=80=99s = why I said that saying that a WebRTC implementation, in a browser, is = not a WebRTC Browser but a WebRTC-Compatible Endpoint, though formally = possible, is questionable =E2=80=94 it would appear to be skirting the = intent of the spec.

I=E2=80=99m deeply confused by that = remark. To answer the question I think you are asking, (i.e. =E2=80=99can = you show me a non-browser webrtc compliant endpoint?'). The best example = I can think of that is public is E/// =E2=80=99s openwebRTC - which = implements both codecs, but doesn=E2=80=99t implement a browser or the = w3C javascript API. - Note that they leave the issue of h264 licence = fees to the app developer to sort out (although they plan to let it use = native os exposed codecs and ride that license I think)

Or did I = misunderstand?

Tim.



= --Apple-Mail=_0B8A542D-D3E9-46B1-9991-EED40BBAE134-- From nobody Tue Dec 9 11:51:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809D11A038D for ; Tue, 9 Dec 2014 11:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Gan062xg03c for ; Tue, 9 Dec 2014 11:51:07 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA36D1A00B1 for ; Tue, 9 Dec 2014 11:51:06 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so2912870wid.11 for ; Tue, 09 Dec 2014 11:51:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/SjwbeExHyqJz14ZoM+f1Kjwz6qXh7ZE+bFwYsBa2PU=; b=gJ+/s2QHI25vlDV1ft+tv70Z5SgLwiI44LNEHf807ZJcAh9tcFktUPG0aYHa2ihfMw MK6syF3uhOK3N9b7MdArInnOhXyYk2mkjCu+YKvFonDqcK/VfLjbJ1m2C0FAzANCdlZy E+X1BQfjIrvzmo3uVHVh13aHwcjHOqpgk6azcsNvINVDOCTpUl8Tm6++sraoJ0G928KP zuvUUWLFyXqFf0VzCXtO8fnNOlFYdnCGLx7E5ePGqmy2oq37lDotDlcS70FEInCf6Xqn SNo3fQVWDVlZrYjPHLh3RX1ChLLzvbaSdqCUbI2V0E+4zOuemQ2llxq884ul6DRiJDDL 0wIw== X-Gm-Message-State: ALoCoQlw2zMllQRAqotowGC1BpvZfdOjC/sXFPyTTTpmxNOmwCI0jU75NA1m2EOXHrAxt163yCmb MIME-Version: 1.0 X-Received: by 10.180.76.211 with SMTP id m19mr7076652wiw.73.1418154665552; Tue, 09 Dec 2014 11:51:05 -0800 (PST) Received: by 10.194.6.39 with HTTP; Tue, 9 Dec 2014 11:51:05 -0800 (PST) Received: by 10.194.6.39 with HTTP; Tue, 9 Dec 2014 11:51:05 -0800 (PST) In-Reply-To: References: <5486C48D.8040602@alvestrand.no> Date: Tue, 9 Dec 2014 21:51:05 +0200 Message-ID: From: Mohammed Raad To: David Singer Content-Type: multipart/alternative; boundary=f46d043c7ab213c6460509cdddbf Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gOJfDPDnse7jfpWf0CA6vwZPOiw Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 19:51:08 -0000 --f46d043c7ab213c6460509cdddbf Content-Type: text/plain; charset=UTF-8 Well, that's a much clearer question without implications. However, I think it is impossible to answer at this point regardless how many people indicate that they will implement both codecs or not at this point. Mohammed On Dec 10, 2014 6:35 AM, "David Singer" wrote: > > > On Dec 9, 2014, at 11:31 , Mohammed Raad > wrote: > > > > You know, that's a very strange path to take. I mean it really does > sound like attempting to come to an agreement regarding what features > future products should have by limiting participation in this technical > decision process to those committed to deploy specific technologies. I > think you ought to read the definition of anti competitive practice again. > > Please be respectful of your language. > > I am trying to find out a simple answer: how many endpoints would, in > fact, expect to support both codecs? > > > I am not trying to limit participation. I am trying to find out whether > we would actually get the purported effect. > > If all the people humming yes make webrtc-compatible endpoints, we do not > get the effect we want. Is it that hard to see that? > > > > David Singer > Manager, Software Standards, Apple Inc. > > --f46d043c7ab213c6460509cdddbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Well, that's a much clearer question without=C2=A0 impli= cations. However, I think it is impossible to answer at this point regardle= ss how many people indicate that they will implement both codecs or not at = this point.

Mohammed

On Dec 10, 2014 6:35 AM, "David Singer"= ; <singer@apple.com> wrote:

> On Dec 9, 2014, at 11:31 , Mohammed Raad <mohammedsraad@raadtech.com> wrote:
>
> You know, that's a very strange path to take. I mean it really doe= s sound like attempting to come to an agreement regarding what features fut= ure products should have by limiting participation in this technical decisi= on process to those committed to deploy specific technologies. I think you = ought to read the definition of anti competitive practice again.

Please be respectful of your language.

I am trying to find out a simple answer:=C2=A0 how many endpoints would, in= fact, expect to support both codecs?


I am not trying to limit participation.=C2=A0 I am trying to find out wheth= er we would actually get the purported effect.

If all the people humming yes make webrtc-compatible endpoints, we do not g= et the effect we want.=C2=A0 Is it that hard to see that?



David Singer
Manager, Software Standards, Apple Inc.

--f46d043c7ab213c6460509cdddbf-- From nobody Tue Dec 9 12:03:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242861A879C for ; Tue, 9 Dec 2014 12:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG2QgdutYphw for ; Tue, 9 Dec 2014 12:02:59 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA911A6FE2 for ; Tue, 9 Dec 2014 12:02:59 -0800 (PST) Received: (qmail 35053 invoked from network); 9 Dec 2014 20:02:58 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 13952 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 9 Dec 2014 20:02:58 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 9BDD518A0E14; Tue, 9 Dec 2014 20:02:52 +0000 (GMT) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 83E4B18A0BB8; Tue, 9 Dec 2014 20:02:52 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9DB05FC9-7451-44D6-AB6B-5600D86F54E7" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Tim Panton In-Reply-To: Date: Tue, 9 Dec 2014 20:02:51 +0000 Message-Id: <516A06C6-7965-4D2B-A78F-F65064FDDCB7@phonefromhere.com> References: <5486C48D.8040602@alvestrand.no> To: David Singer X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cNWQNhT2IFOU5iv0uOA3r73DI8c Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 20:03:01 -0000 --Apple-Mail=_9DB05FC9-7451-44D6-AB6B-5600D86F54E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 9 Dec 2014, at 19:35, David Singer > wrote: >=20 > I am trying to find out a simple answer: how many endpoints would, in = fact, expect to support both codecs? I=E2=80=99ve said before - my view is that most toolkits for building = webRTC compliant native apps will ship with support for both codecs, = but with levers to allow the developer to disable the use of a specific codec where it is = in appropriate to their use-case for one reason or another. It is unknowable what choices individual app developers will make. - But remember webRTC is unlike most web technologies, it takes 2 peers = to tango, so most app developers will probably enable both codecs if they can. Especially if they intend to allow web = based users to communicate with native app users. They will do so=20 because hopefully O/A can make a better codec choice at runtime than = they can at compile time, given the huge variety in=20 possible endpoint hardware. Tim Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk --Apple-Mail=_9DB05FC9-7451-44D6-AB6B-5600D86F54E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 9 Dec 2014, at 19:35, David Singer <singer@apple.com> = wrote:

I am trying to find out a simple = answer:  how many endpoints would, in fact, expect to support both = codecs?

I=E2=80= =99ve said before - my view is that most toolkits for building webRTC = compliant native apps  will ship with support for both codecs, but = with levers to
allow the developer to disable the = use of a specific codec where it is in appropriate to their use-case for = one reason or another.

It is unknowable what choices individual app developers will = make.

- But = remember webRTC is unlike most web technologies, it takes 2 peers to = tango, so most app developers will probably
enable = both codecs if they can. Especially if they intend to allow web based = users to communicate with native app users. They will do = so 
because hopefully O/A can make a better = codec choice at runtime than they can at compile time, given the huge = variety in 
possible endpoint = hardware.

Tim

Tim Panton - = Web/VoIP consultant and implementor
www.westhawk.co.uk



= --Apple-Mail=_9DB05FC9-7451-44D6-AB6B-5600D86F54E7-- From nobody Tue Dec 9 12:11:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54E41A036A for ; Tue, 9 Dec 2014 12:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WB1Xn4UW_OKY for ; Tue, 9 Dec 2014 12:11:13 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491231A0101 for ; Tue, 9 Dec 2014 12:11:13 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id l18so1814997wgh.40 for ; Tue, 09 Dec 2014 12:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yXJx5csF5gJhlwt5OaOkq9grgFnQ9p/zRbfSdPO+ZVg=; b=nJJ8lhnVSX7231g68GeZ0EwPjKftYSq69aR4rDSuzYD0HjosMzRCq2SP6HRXrtm6uu XaYQVYz0tyNjx1aP+4hyyR+sZpkClSDKJ0HPB5ar/jX+mNNtM+aVcLHNS9kA4U8I4V93 cCGhQJPC6HwLt7RMokQkw0dz9jf4iKjHr9cPIYRndPG2TBRHkI+M6MofE/EoQVFilZ6N D4LRtQb4ynZvifgY4K52w++3jX6xhwa6DDAYRu38wP3dEcywU5l+6pymWkuJE32N1lbD Tnckilx9gNoiKmI0h9w82ddKTHLUg56n984TUVpF8J0TZVKB8yIn9HijNW0NFzvgywIY 2wSg== X-Received: by 10.180.208.112 with SMTP id md16mr6956636wic.37.1418155872001; Tue, 09 Dec 2014 12:11:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.211.131 with HTTP; Tue, 9 Dec 2014 12:10:51 -0800 (PST) In-Reply-To: References: <5486C48D.8040602@alvestrand.no> From: Bernard Aboba Date: Tue, 9 Dec 2014 12:10:51 -0800 Message-ID: To: David Singer Content-Type: multipart/alternative; boundary=001a11c3380efca4ac0509ce2445 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mjgDX35SfSSGE8qXog6PfNxi_Kk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 20:11:16 -0000 --001a11c3380efca4ac0509ce2445 Content-Type: text/plain; charset=UTF-8 David Singer said: "I am trying to find out a simple answer: how many endpoints would, in fact, expect to support both codecs?" [BA] The proposal has built-in incentives for implementers in each category to either ignore the recommendations or ignore interoperability (or both). As it stands, the proposal doesn't require that "WebRTC-compatible endpoints" support either H.264 or VP8. I understand why an endpoint not supporting video shouldn't have to, but if the WebRTC-compatible endpoint does support video, why shouldn't it support at least one of the MTI codecs? The way it is written a WebRTC-compatible endpoint that supported only H.261 would be compliant while being able to communicate with either browsers or non-browsers, which seems silly. The "non-browser" is required to support both codecs, but only until a clause is triggered to choose a single MTI. For a "non-browser" such as a mobile application, there is no real need to support both VP8 and H.264, assuming that browsers support both. So I would expect most folks in this category to ignore the recommendation or wait for the "trigger" (then ignore that too if the selected codec isn't the one they've already chosen). It would make more sense for this category to mandate implementation of either VP8 or H.264 (implementer's choice) and dump the trigger clause. The "browser" subset is supposed to support both codecs. However, the "trigger" clause for the "non-browser" case muddies the waters, particularly in situations where implementing a previously non-supported codec could take a while. Who wants to spend a lot of effort implementing a codec that might not even be required by the time the implementation is complete (and that will probably be guaranteed to be obsolete by then anyway)? On Tue, Dec 9, 2014 at 11:35 AM, David Singer wrote: > > > On Dec 9, 2014, at 11:31 , Mohammed Raad > wrote: > > > > You know, that's a very strange path to take. I mean it really does > sound like attempting to come to an agreement regarding what features > future products should have by limiting participation in this technical > decision process to those committed to deploy specific technologies. I > think you ought to read the definition of anti competitive practice again. > > Please be respectful of your language. > > I am trying to find out a simple answer: how many endpoints would, in > fact, expect to support both codecs? > > > I am not trying to limit participation. I am trying to find out whether > we would actually get the purported effect. > > If all the people humming yes make webrtc-compatible endpoints, we do not > get the effect we want. Is it that hard to see that? > > > > David Singer > Manager, Software Standards, Apple Inc. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c3380efca4ac0509ce2445 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
David Singer said:=C2=A0

"I am trying to find out a simple answe= r:=C2=A0 how many endpoints would, in fact, expect to support both codecs?&= quot;

[BA] =C2=A0The= proposal has built-in incentives for implementers in each category to eith= er ignore the recommendations or ignore interoperability (or both). =C2=A0= =C2=A0

As it stands, the proposal doesn't require th= at "WebRTC-compatible endpoints" support either H.264 or VP8.=C2= =A0 I understand why an endpoint not supporting video shouldn't have to= , but if the WebRTC-compatible endpoint does support video, why shouldn'= ;t it support at least one of the MTI codecs? =C2=A0 The way it is written = a WebRTC-compatible endpoint that supported only H.261 would be compliant w= hile being able to communicate with either browsers or non-browsers, which = seems silly.=C2=A0

The "non-browser" is r= equired to support both codecs, but only until a clause is triggered to cho= ose a single MTI.=C2=A0 For a =C2=A0"non-browser" such as a mobil= e application, there is no real need to support both VP8 and H.264, assumin= g that browsers support both.=C2=A0 So I would expect most folks in this ca= tegory to ignore the recommendation or wait for the "trigger" (th= en ignore that too if the selected codec isn't the one they've alre= ady chosen). =C2=A0 It would make more sense for this category to mandate i= mplementation of either VP8 or H.264 (implementer's choice) and dump th= e trigger clause.=C2=A0

The "browser" su= bset is supposed to support both codecs.=C2=A0 However, the "trigger&q= uot; clause for the "non-browser" case muddies the waters, partic= ularly in situations where implementing a previously non-supported codec co= uld take a while.=C2=A0 Who wants to spend a lot of effort implementing a c= odec that =C2=A0might not even be required by the time the implementation i= s complete (and that will probably be guaranteed to be obsolete by then any= way)? =C2=A0





On Tue, Dec 9, 2014 at 11:35 AM, David Singer <singer@apple.com>= wrote:

> On Dec 9, 2014, at 11:31 , Mohammed Raad <mohammedsraad@raadtech.com> wrote:
>
> You know, that's a very strange path to take. I mean it really doe= s sound like attempting to come to an agreement regarding what features fut= ure products should have by limiting participation in this technical decisi= on process to those committed to deploy specific technologies. I think you = ought to read the definition of anti competitive practice again.

Please be respectful of your language.

I am trying to find out a simple answer:=C2=A0 how many endpoints would, in= fact, expect to support both codecs?


I am not trying to limit participation.=C2=A0 I am trying to find out wheth= er we would actually get the purported effect.

If all the people humming yes make webrtc-compatible endpoints, we do not g= et the effect we want.=C2=A0 Is it that hard to see that?



David Singer
Manager, Software Standards, Apple Inc.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--001a11c3380efca4ac0509ce2445-- From nobody Tue Dec 9 12:16:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9D81A00B5 for ; Tue, 9 Dec 2014 12:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTQLWbKzRmL2 for ; Tue, 9 Dec 2014 12:16:09 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97361A0097 for ; Tue, 9 Dec 2014 12:16:08 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hl2so6522004igb.0 for ; Tue, 09 Dec 2014 12:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=W/b02JXbh1mZiOyg9Gp9pcMVKOC2+GgfHmHb5Ht1EI8=; b=CL4zgYYFDn9hYcg7E0Jn6SXqNS9AqHUO6WdHI4XjP4eqlmvdl0qbozVtgnAvjFjyXn 78SyrccNF95B94VHhR5tau0RMVxSCLwpqwq3j0pa1QK7vPh4tncns6q0zQwENPUZqcQL pmJ0oP+or9ajxvBrkU7pC0HcRGCQ9hGuMkrzPPOEbdGJUVN5vq1SjtBTcKH6zhmS6V8C 2VXCfkcX1XmlC1dPucAslDm2zQzzJ1/bmZHSWs+2/pVmjN9qTaUMRx2x3vUKlwPjie7g +3TKgWp5tEILjrUoPn5eqAtFP/bU5NvPWn+b7EWIs9O06+r8bSyrtyIA3oZm6iLEAgmj ixwA== MIME-Version: 1.0 X-Received: by 10.50.153.109 with SMTP id vf13mr2404751igb.41.1418156167734; Tue, 09 Dec 2014 12:16:07 -0800 (PST) Sender: elagerway@gmail.com Received: by 10.107.38.137 with HTTP; Tue, 9 Dec 2014 12:16:07 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Dec 2014 12:16:07 -0800 X-Google-Sender-Auth: iZQBMkQDJuApc3Ug2e3fQRu-wcI Message-ID: From: Erik Lagerway To: Sean Turner Content-Type: multipart/alternative; boundary=089e015366729d2d2d0509ce36d1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tNunG6c2SN_CsT1IAqr3nzK83SU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 20:16:12 -0000 --089e015366729d2d2d0509ce36d1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Sean, We can not support this draft at this time. As RTC SDK vendors we very likely will support both codecs, but we can not stand by a decision that will "impose" dual MTI on our developer community. According to this, every dev must use both codecs for every app that is built using our tools. Codec selection should be their choice and not be forced upon them. This seems to be a rather unreasonable expectation. *Erik Lagerway | *Hookflash * | 1 (855) Hookflash ext. 2 | Twitter | WebRTC.is Blog * On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner wrote: > All, > > At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about > codecs, which I dubbed "the great codec compromise." The compromise text > that was discussed appears in slides 12-14 at [4] (which is a slight > editorial variation of the text proposed at [2]). > > This message serves to confirm the sense of the room. > > In the room, I heard the following objections and responses (and I=E2=80= =99m > paraphrasing here), which I=E2=80=99ll take the liberty of categorizing a= s IPR, > Time, and Trigger: > > 1) IPR: > > Objections: There are still IPR concerns which may restrict what a > particular organization feels comfortable with including in their browser > implementations. > > Response: IPR concerns on this topic are well known. There is even a > draft summarizing the current IPR status for VP8: > draft-benham-rtcweb-vp8litigation. The sense of the room was still that > adopting the compromise text was appropriate. > > 2) Time: > > 2.1) Time to consider decision: > > Objection: The decision to consider the compromise proposal at this > meeting was provided on short notice and did not provide some the > opportunity to attend in person. > > Response: Six months ago the chairs made it clear discussion would be > revisited @ IETF 91 [0]. The first agenda proposal for the WG included th= is > topic [1], and the topic was never removed by the chairs. More > importantly, all decisions are confirmed on list; in person attendance is > not required to be part of the process. > > 2.2) Time to consider text: > > Objection: The proposed text [2] is too new to be considered. > > Response: The requirement for browsers to support both VP8 and H.264 was > among the options in the straw poll conducted more than six months ago. > All decisions are confirmed on list so there will be ample time to discus= s > the proposal. > > 3) Trigger: > > Objection: The =E2=80=9Ctrigger=E2=80=9D sentence [3] is all kinds of wro= ng because it=E2=80=99s > promising that the future IETF will update this specification. > > Response: Like any IETF proposal, an RFC that documents the current > proposal can be changed through the consensus process at any other time. > > > After the discussion, some clarifying questions about the hums, and typin= g > the hum questions on the screen, there was rough consensus in the room to > add (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draft-ietf-rtcwe= b-video. In > keeping with IETF process, I am confirming this consensus call on the lis= t. > > If anyone has any other issues that they would like to raise please do by > December 19th. > > Cheers, > spt (as chair) > > [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html > [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html > [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html > [3] The one that begins with "If compelling evidence ..." > [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e015366729d2d2d0509ce36d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Sean,

We can not support t= his draft at this time.

As RTC SDK vendors we very likel= y will support both codecs, but we can not stand by a decision that will &q= uot;impose" dual MTI on our developer community.

<= div>According to this, every dev must use both codecs for every app that is= built using our tools. Codec selection should be their choice and not be f= orced upon them. This seems to be a rather unreasonable expectation.
<= div>

Erik Lagerway=C2=A0|= =C2=A0Hookflash=C2=A0| 1 (855)=C2=A0Hookflash ext.= 2 |=C2=A0Twitter=C2=A0|=C2=A0WebRTC.is Blog=C2= =A0

On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner = <turners@ieca.com> wrote:
A= ll,

At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about co= decs, which I dubbed "the great codec compromise."=C2=A0 The comp= romise text that was discussed appears in slides 12-14 at [4] (which is a s= light editorial variation of the text proposed at [2]).

This message serves to confirm the sense of the room.

In the room, I heard the following objections and responses (and I=E2=80=99= m paraphrasing here), which I=E2=80=99ll take the liberty of categorizing a= s IPR, Time, and Trigger:

1) IPR:

Objections: There are still IPR concerns which may restrict what a particul= ar organization feels comfortable with including in their browser implement= ations.

Response:=C2=A0 IPR concerns on this topic are well known.=C2=A0 There is e= ven a draft summarizing the current IPR status for VP8: draft-benham-rtcweb= -vp8litigation.=C2=A0 The sense of the room was still that adopting the com= promise text was appropriate.

2) Time:

2.1) Time to consider decision:

Objection: The decision to consider the compromise proposal at this meeting= was provided on short notice and did not provide some the opportunity to a= ttend in person.

Response:=C2=A0 Six months ago the chairs made it clear discussion would be= revisited @ IETF 91 [0]. The first agenda proposal for the WG included thi= s topic [1], and the topic was never removed by the chairs.=C2=A0 =C2=A0 Mo= re importantly, all decisions are confirmed on list; in person attendance i= s not required to be part of the process.

2.2) Time to consider text:

Objection: The proposed text [2] is too new to be considered.

Response: The requirement for browsers to support both VP8 and H.264 was am= ong the options in the straw poll conducted more than six months ago.=C2=A0= All decisions are confirmed on list so there will be ample time to discuss= the proposal.

3) Trigger:

Objection: The =E2=80=9Ctrigger=E2=80=9D sentence [3] is all kinds of wrong= because it=E2=80=99s promising that the future IETF will update this speci= fication.

Response: Like any IETF proposal, an RFC that documents the current proposa= l can be changed through the consensus process at any other time.


After the discussion, some clarifying questions about the hums, and typing = the hum questions on the screen, there was rough consensus in the room to a= dd (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draft-ietf-rtcweb-v= ideo.=C2=A0 In keeping with IETF process, I am confirming this consensus ca= ll on the list.

If anyone has any other issues that they would like to raise please do by D= ecember 19th.

Cheers,
spt (as chair)

[0] http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg11194.html
[1] http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg13150.html
[2] http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg13432.html
[3] The one that begins with "If compelling evidence ..."
[4] http://www.ietf.org/proceedings/91/slides/slides-91= -rtcweb-7.pdf
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--089e015366729d2d2d0509ce36d1-- From nobody Tue Dec 9 12:19:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318A51A00EF for ; Tue, 9 Dec 2014 12:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYa971BeK8a0 for ; Tue, 9 Dec 2014 12:19:17 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A091A00B5 for ; Tue, 9 Dec 2014 12:19:17 -0800 (PST) Received: by mail-yk0-f173.google.com with SMTP id 19so604622ykq.32 for ; Tue, 09 Dec 2014 12:19:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KaHjD4PySmbuNAOhmdhn8f1QK/MABajqavMlGVYS99E=; b=ZnXAETDctGCxuKDSEA8gVg8gQYie32PtXdOcripPFSs8im6HLrJS6UfEHNO+HeQhY4 xmIGMw67sJpBH5Z+VQFkxeyfkctExg0WQmVRuo+PVnGhjwvXjSv5k6+cwk8FohuSmrCh IY291HEn8doKg5d75lyoDJ5QnTwEWmvzEltUR8E+xjKPQ4x0DDldQ74LzrXTzqluijaJ 6q3eIVyyel/xvwj+TYv0UKSR3mbsh7PCQ/tcY/hgzbF0mwo7gXARGrZjcHhsg4ROcMXa jZH4+6p1w25yWv3UV/mr6UbzN1OksUQw5PdIgfTbM2ajCsXsvSloHPRS7lzqDbaLvC7v EMfg== MIME-Version: 1.0 X-Received: by 10.236.230.104 with SMTP id i98mr4671348yhq.169.1418156356503; Tue, 09 Dec 2014 12:19:16 -0800 (PST) Received: by 10.170.135.193 with HTTP; Tue, 9 Dec 2014 12:19:16 -0800 (PST) Received: by 10.170.135.193 with HTTP; Tue, 9 Dec 2014 12:19:16 -0800 (PST) In-Reply-To: References: <5486C48D.8040602@alvestrand.no> Date: Wed, 10 Dec 2014 07:19:16 +1100 Message-ID: From: Silvia Pfeiffer To: David Singer Content-Type: multipart/alternative; boundary=089e01634d6cdd8fc20509ce41ef Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6hFQnJdHWskanmq5EIKZJnOc6pc Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 20:19:19 -0000 --089e01634d6cdd8fc20509ce41ef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nice question, seeing Apple makes so many statements about what they intend to implement. :-) Fwiw, we have an iOS webrtc stack and have vp8 support in it. If Apple opens access to the h264 hardware support on iOS, we would likely hand that through, too. Best Regards, Silvia. On 10 Dec 2014 04:32, "David Singer" wrote: > > > On Dec 9, 2014, at 1:44 , Harald Alvestrand > wrote: > > > > I note that the "confirming sense of the room" thread has gotten a lot > > of messages that are not declaring a position on the question. > > > > I also note that from the messages on the thread, I can't figure out if > > Keith Drage, Gili, Monty Montgomery or Peter Saint-Andre have taken a > > position (I could guess, but I don't want to - besides, they might not > > want to take a position, which is perfectly OK). > > > > It would be nice for me as a reader if people could: > > > > - state their position on the "confirming sense of the room" thread > > - change the subject line when they want to say anything else > > > > That's my preference - of course, people who have "mute thread" in thei= r > > email readers might want the whole discussion to stay on thread, and > > will hate me for the last suggestion.... > > > > Harald > > Thanks, Harald, that would help. > > I would also like to know from those confirming the sense of the room, > whether THEY THEMSELVES intend to implement both codecs, or whether they > conveniently think they don=E2=80=99t need to, and it=E2=80=99s just a pr= oblem for other > people to handle. > > Honestly, a +1 for =E2=80=9Cthose other people should do it=E2=80=9D is m= eaningless. > > David Singer > Manager, Software Standards, Apple Inc. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e01634d6cdd8fc20509ce41ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Nice question, seeing Apple makes so many statements about w= hat they intend to implement. :-)
Fwiw, we have an iOS webrtc stack and have vp8 support in it. If Apple open= s access to the h264 hardware support on iOS, we would likely hand that thr= ough, too.

Best Regards,
Silvia.

On 10 Dec 2014 04:32, "David Singer" &= lt;singer@apple.com> wrote:

> On Dec 9, 2014, at 1:44 , Harald Alvestrand <harald@alvestrand.no> wrote:
>
> I note that the "confirming sense of the room" thread has go= tten a lot
> of messages that are not declaring a position on the question.
>
> I also note that from the messages on the thread, I can't figure o= ut if
> Keith Drage, Gili, Monty Montgomery or Peter Saint-Andre have taken a<= br> > position (I could guess, but I don't want to - besides, they might= not
> want to take a position, which is perfectly OK).
>
> It would be nice for me as a reader if people could:
>
> - state their position on the "confirming sense of the room"= thread
> - change the subject line when they want to say anything else
>
> That's my preference - of course, people who have "mute threa= d" in their
> email readers might want the whole discussion to stay on thread, and > will hate me for the last suggestion....
>
> Harald

Thanks, Harald, that would help.

I would also like to know from those confirming the sense of the room, whet= her THEY THEMSELVES intend to implement both codecs, or whether they conven= iently think they don=E2=80=99t need to, and it=E2=80=99s just a problem fo= r other people to handle.

Honestly, a +1 for =E2=80=9Cthose other people should do it=E2=80=9D is mea= ningless.

David Singer
Manager, Software Standards, Apple Inc.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--089e01634d6cdd8fc20509ce41ef-- From nobody Tue Dec 9 12:29:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF891A00BF for ; Tue, 9 Dec 2014 12:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0VkYdSAkR9s for ; Tue, 9 Dec 2014 12:29:48 -0800 (PST) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DD51A0011 for ; Tue, 9 Dec 2014 12:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418156988; x=2282070588; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bFyY9vecEEazvezJ+v2oOtdoJbdBm5JycFtl+dvXIr4=; b=tuW+Vyhoh+V05cMu9/oyAjQAvYdt++gBWZYu7qkKkbJpRrv/MP2DKJDZ0ZYTQl96 6DFfWY3GPwzYqSwdaevq5khTwx9yjwb6i9LJMK66zVOVRZylEbzIAUnxOVBRBjZB d1mW5gXgtYr0UjKtzfEiZiKwFXsb4PGQWCH2GgCIwc66gTBWPiCOwIs9moSQ9oAR J1ZYxwZclg08a6f/5QnF13rMh9DEgVooHaxpCA1xPdEvtalPycx7RUfuQHNV+e/S 6Bx8nJMytIuLQR6i7ir/RoS23dx0uDcJ1F/TkeLfg2vgTEluCYWUWLDIF0wFKRHZ uE6fvmUvs+WOXgXzzEnNtg==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 76.14.26546.CBB57845; Tue, 9 Dec 2014 12:29:48 -0800 (PST) X-AuditID: 11973e11-f79af6d0000067b2-38-54875bbc60f1 Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id EE.84.05452.FBB57845; Tue, 9 Dec 2014 12:29:51 -0800 (PST) Received: from [17.153.29.83] (unknown [17.153.29.83]) by chive.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGC00KAT0XN2990@chive.apple.com> for rtcweb@ietf.org; Tue, 09 Dec 2014 12:29:47 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <9BDCD7D8-B274-4970-A01B-D31069AEA935@phonefromhere.com> Date: Tue, 09 Dec 2014 12:29:46 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <5486C48D.8040602@alvestrand.no> <54873575.3030804@nostrum.com> <54874B66.5050700@nostrum.com> <9BDCD7D8-B274-4970-A01B-D31069AEA935@phonefromhere.com> To: Tim Panton X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUi2FCYprsnuj3E4GwDi8Xaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKaJu6nq2gmadi+dojLA2MFzi7GDk5JARMJHbcXM8IYYtJXLi3 nq2LkYtDSGAfo0TDihVMMEXT925mhEh0M0n837qSHc5ZefkscxcjBwezgLrElCm5IA28AnoS TU8egzULC5hLbOw6wgxiswmoSjyYcwxsG6eAq8SnKRfBbBag+Ib7J9khxrhJfN3HDxJmFtCW ePLuAivESBuJG9t2sUKsvcYk0XX+FAtIQkRATeLcj8PMEIfKSvy7eIYdwn7LKvFpjecERuFZ CNfNQnLdLCQrFjAyr2IUyk3MzNHNzDPSSywoyEnVS87P3cQICuLpdoI7GI+vsjrEKMDBqMTD q2HZFiLEmlhWXJl7iFGag0VJnPeGDVBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD4xZHt6ct aanOq3qLOiebiFvFv4pkMQu9vjMoM+JjJ69K4KVoHkMGUc7ly9f+NxKTipyzLOfR2m+zU09M VzXZesnWKE+xb6WiGeePa/e7HqvsmP/hFK/B8Q1vrH5f+/LuVHmjvSCTpHa33i4b9syX0wJO Bfyu4Xu54N/0F7oLOkzTMh3uiS0JVWIpzkg01GIuKk4EAJOr4MVDAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FDMr7s/uj3E4Ps3Xou1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0TZ1PVtBM0/F8rVHWBoYL3B2MXJySAiYSEzfu5kRwhaTuHBv PVsXIxeHkEA3k8T/rSvZ4ZyVl88ydzFycDALqEtMmZIL0sAroCfR9OQxE4gtLGAusbHrCDOI zSagKvFgzjGwoZwCrhKfplwEs1mA4hvun2SHGOMm8XUfP0iYWUBb4sm7C6wQI20kbmzbxQqx 9hqTRNf5UywgCREBNYlzPw4zQxwqK/Hv4hn2CYwCsxAumoXkollIxi5gZF7FKFCUmpNYaaGX WFCQk6qXnJ+7iREcdoVpOxibllsdYhTgYFTi4dWwbAsRYk0sK67MPcQowcGsJMK7lqU9RIg3 JbGyKrUoP76oNCe1+BCjNAeLkjhv2bvGECGB9MSS1OzU1ILUIpgsEwenFDCAV/DKfGJYMun5 xmA2ww0eZX4/C/wXhO9nfD7DuHzqmQ0r26b27Gas6FVa5r2GQf/Iikq73THVClnOfnrz8lkX u1tP96h1ON8wMUH91pTC45O/r05h7durx78x4unsRf2vHZp2x1zUDrR6ZDDXlEc2uun5wied 2+bOi9iV8McgxHLZrbwNx0OVWIozEg21mIuKEwEEOvdHNwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/K1OUz9ITItk_Fpp_FCwl_dfxsiU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 20:29:50 -0000 > On Dec 9, 2014, at 11:50 , Tim Panton wrote: >=20 >=20 >> On 9 Dec 2014, at 19:31, David Singer wrote: >=20 >>=20 >> That=E2=80=99s why I said that saying that a WebRTC implementation, = in a browser, is not a WebRTC Browser but a WebRTC-Compatible Endpoint, = though formally possible, is questionable =E2=80=94 it would appear to = be skirting the intent of the spec. >=20 > I=E2=80=99m deeply confused by that remark. To answer the question I = think you are asking, (i.e. =E2=80=99can you show me a non-browser = webrtc compliant endpoint?'). The best example I can think of that is = public is E/// =E2=80=99s openwebRTC - which implements both codecs, but = doesn=E2=80=99t implement a browser or the w3C javascript API. - Note = that they leave the issue of h264 licence fees to the app developer to = sort out (although they plan to let it use native os exposed codecs and = ride that license I think) >=20 > Or did I misunderstand?=E2=80=99 Only slightly. An earlier suggestion on this thread was that one could = be conformant with the WebRTC specs if one simply claimed that one was = building a webrtc-compatible endpoint; even if the implementation was = of webrtc, in a browser, it would not be labeled as =E2=80=9CWebRTC = Browser=E2=80=9D. That, to me, is sleight of hand; a neat trick, but not quite what we = want to have happen. I=E2=80=99d rather not suggest it to anyone. David Singer Manager, Software Standards, Apple Inc. From nobody Tue Dec 9 12:31:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80411A00BF for ; Tue, 9 Dec 2014 12:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6TeUv5oE49t for ; Tue, 9 Dec 2014 12:31:33 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 015091A0011 for ; Tue, 9 Dec 2014 12:31:33 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id h11so3037761wiw.3 for ; Tue, 09 Dec 2014 12:31:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ALFQRg5spAVG3oIQPrQD+5z7sMOfLICOijmPC2sIVs8=; b=fJ+04uFN4/1hwdNf5SxAu/h9mVqTdRossti/k5W2IKCJtvVNmoxc7r0mdOgBwOrbo8 UB7hA8+C41LEfJGmlJ4zdLUv2gSRxi1NdHDR08FBea1Y8fGJdyRCmpsAGu3edYQ6GeSu lVVK8ZMNtABn62tZX+Zq0fE2ecGOzkrEk1ONtjjWWqinErStMwrlVzvNIWPArs1CLPqZ E5s7RzsU3PNB6zpzEfBWOPgU8xV8+nQXJzkZJclBhZRUAOphS5d4z3Etnddvh4W8eFMh F98gLvvDoxIIpOk5y3Ot5WjarKFeDbsTRyibnIHsHq7wZY7o3OREYzjqHmhYcZrobV/m 0iNw== X-Received: by 10.194.161.202 with SMTP id xu10mr638540wjb.4.1418157091808; Tue, 09 Dec 2014 12:31:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.211.131 with HTTP; Tue, 9 Dec 2014 12:31:08 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Tue, 9 Dec 2014 12:31:08 -0800 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=089e013d1f9cb16e030509ce6dbf Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Z9jcw2yl14ae7VsFE682gBg80nM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 20:31:36 -0000 --089e013d1f9cb16e030509ce6dbf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Setting aside my reservations about the dual-MTI requirement for browsers, I also oppose the other elements of the proposal. Mandating that applications support both codecs makes no sense - they should only be required to support one of them (their choice). If this change were made the trigger clause would serve no purpose, other than to keep this discussion going ad-infinitum. So I oppose that as well. Allowing an endpoint that implements video to call itself "WebRTC compliant" without implementing either of the MTI codecs is so wrong-headed that I am at a loss for words. On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway wrote: > Thanks Sean, > > We can not support this draft at this time. > > As RTC SDK vendors we very likely will support both codecs, but we can no= t > stand by a decision that will "impose" dual MTI on our developer communit= y. > > According to this, every dev must use both codecs for every app that is > built using our tools. Codec selection should be their choice and not be > forced upon them. This seems to be a rather unreasonable expectation. > > > *Erik Lagerway | *Hookflash > * | 1 (855) Hookflash ext. 2 | Twitter > | WebRTC.is Blog * > > On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner wrote: > >> All, >> >> At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about >> codecs, which I dubbed "the great codec compromise." The compromise tex= t >> that was discussed appears in slides 12-14 at [4] (which is a slight >> editorial variation of the text proposed at [2]). >> >> This message serves to confirm the sense of the room. >> >> In the room, I heard the following objections and responses (and I=E2=80= =99m >> paraphrasing here), which I=E2=80=99ll take the liberty of categorizing = as IPR, >> Time, and Trigger: >> >> 1) IPR: >> >> Objections: There are still IPR concerns which may restrict what a >> particular organization feels comfortable with including in their browse= r >> implementations. >> >> Response: IPR concerns on this topic are well known. There is even a >> draft summarizing the current IPR status for VP8: >> draft-benham-rtcweb-vp8litigation. The sense of the room was still that >> adopting the compromise text was appropriate. >> >> 2) Time: >> >> 2.1) Time to consider decision: >> >> Objection: The decision to consider the compromise proposal at this >> meeting was provided on short notice and did not provide some the >> opportunity to attend in person. >> >> Response: Six months ago the chairs made it clear discussion would be >> revisited @ IETF 91 [0]. The first agenda proposal for the WG included t= his >> topic [1], and the topic was never removed by the chairs. More >> importantly, all decisions are confirmed on list; in person attendance i= s >> not required to be part of the process. >> >> 2.2) Time to consider text: >> >> Objection: The proposed text [2] is too new to be considered. >> >> Response: The requirement for browsers to support both VP8 and H.264 was >> among the options in the straw poll conducted more than six months ago. >> All decisions are confirmed on list so there will be ample time to discu= ss >> the proposal. >> >> 3) Trigger: >> >> Objection: The =E2=80=9Ctrigger=E2=80=9D sentence [3] is all kinds of wr= ong because it=E2=80=99s >> promising that the future IETF will update this specification. >> >> Response: Like any IETF proposal, an RFC that documents the current >> proposal can be changed through the consensus process at any other time. >> >> >> After the discussion, some clarifying questions about the hums, and >> typing the hum questions on the screen, there was rough consensus in the >> room to add (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draft-i= etf-rtcweb-video. >> In keeping with IETF process, I am confirming this consensus call on the >> list. >> >> If anyone has any other issues that they would like to raise please do b= y >> December 19th. >> >> Cheers, >> spt (as chair) >> >> [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html >> [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html >> [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html >> [3] The one that begins with "If compelling evidence ..." >> [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf >> _______________________________________________ >> 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 > > --089e013d1f9cb16e030509ce6dbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Setting aside=C2=A0my reservations about the=C2=A0dua= l-MTI requirement for browsers, I also oppose the other elements of the pro= posal.=C2=A0

Mandating that applications support = both codecs makes no sense - they should only be required to support one of= them (their choice).=C2=A0=C2=A0 If this change were made the trigger clau= se would serve no purpose, other than to keep this discussion going ad-infi= nitum.=C2=A0 So I oppose that as well.=C2=A0

Allo= wing an endpoint that implements video to call itself "WebRTC complian= t" without implementing either of the MTI codecs is so wrong-headed th= at I am at a loss for words.



On Tue, Dec 9, 2014 a= t 12:16 PM, Erik Lagerway <erik@hookflash.com> wrote:
Thanks Sean,
<= br>
We can not support this draft at this time.

As = RTC SDK vendors we very likely will support both codecs, but we can not sta= nd by a decision that will "impose" dual MTI on our developer com= munity.

According to this, every dev must use both= codecs for every app that is built using our tools. Codec selection should= be their choice and not be forced upon them. This seems to be a rather unr= easonable expectation.
=


Erik Lagerway=C2=A0|=C2=A0<= /span>Hookflash=C2=A0| 1 (855)=C2=A0Hookflash ext. 2 |=C2=A0Twitter= =C2=A0|=C2=A0WebRTC.is Blog=C2=A0
<= span style=3D"color:rgb(0,0,0);line-height:normal;font-family:arial;border-= collapse:separate"><= span style=3D"color:rgb(0,0,0);line-height:normal;font-family:arial;border-= collapse:separate">

On Fri, Dec 5, 2014 at 5= :36 AM, Sean Turner <turners@ieca.com> wrote:
=
All,

At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about co= decs, which I dubbed "the great codec compromise."=C2=A0 The comp= romise text that was discussed appears in slides 12-14 at [4] (which is a s= light editorial variation of the text proposed at [2]).

This message serves to confirm the sense of the room.

In the room, I heard the following objections and responses (and I=E2=80=99= m paraphrasing here), which I=E2=80=99ll take the liberty of categorizing a= s IPR, Time, and Trigger:

1) IPR:

Objections: There are still IPR concerns which may restrict what a particul= ar organization feels comfortable with including in their browser implement= ations.

Response:=C2=A0 IPR concerns on this topic are well known.=C2=A0 There is e= ven a draft summarizing the current IPR status for VP8: draft-benham-rtcweb= -vp8litigation.=C2=A0 The sense of the room was still that adopting the com= promise text was appropriate.

2) Time:

2.1) Time to consider decision:

Objection: The decision to consider the compromise proposal at this meeting= was provided on short notice and did not provide some the opportunity to a= ttend in person.

Response:=C2=A0 Six months ago the chairs made it clear discussion would be= revisited @ IETF 91 [0]. The first agenda proposal for the WG included thi= s topic [1], and the topic was never removed by the chairs.=C2=A0 =C2=A0 Mo= re importantly, all decisions are confirmed on list; in person attendance i= s not required to be part of the process.

2.2) Time to consider text:

Objection: The proposed text [2] is too new to be considered.

Response: The requirement for browsers to support both VP8 and H.264 was am= ong the options in the straw poll conducted more than six months ago.=C2=A0= All decisions are confirmed on list so there will be ample time to discuss= the proposal.

3) Trigger:

Objection: The =E2=80=9Ctrigger=E2=80=9D sentence [3] is all kinds of wrong= because it=E2=80=99s promising that the future IETF will update this speci= fication.

Response: Like any IETF proposal, an RFC that documents the current proposa= l can be changed through the consensus process at any other time.


After the discussion, some clarifying questions about the hums, and typing = the hum questions on the screen, there was rough consensus in the room to a= dd (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draft-ietf-rtcweb-v= ideo.=C2=A0 In keeping with IETF process, I am confirming this consensus ca= ll on the list.

If anyone has any other issues that they would like to raise please do by D= ecember 19th.

Cheers,
spt (as chair)

[0] http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg11194.html
[1] http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg13150.html
[2] http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg13432.html
[3] The one that begins with "If compelling evidence ..."
[4] http://www.ietf.org/proceedings/91/slides/slides-91= -rtcweb-7.pdf
_______________________________________________
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


--089e013d1f9cb16e030509ce6dbf-- From nobody Tue Dec 9 12:53:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568851A8836 for ; Tue, 9 Dec 2014 12:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMi6t-oEOJJ7 for ; Tue, 9 Dec 2014 12:53:26 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27A81A87F2 for ; Tue, 9 Dec 2014 12:53:25 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB9KrJKE003937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2014 14:53:19 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <5487613E.10306@nostrum.com> Date: Tue, 09 Dec 2014 14:53:18 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: David Singer References: <5486C48D.8040602@alvestrand.no> <54873575.3030804@nostrum.com> <53ECE529-C011-4666-B044-226613CA263D@apple.com> In-Reply-To: <53ECE529-C011-4666-B044-226613CA263D@apple.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/huJKZheVirIiZPwJdrxdmEmr_Jw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 20:53:27 -0000 On 12/9/14 12:44, David Singer wrote: > I mean, the draft ‘must do both’ would require people who have a > principled objection to paying fees, having to pay for H.264. I am > curious, are people willing to let their principles (and money) go, in > order to comply with the ‘must’? I'd like to point out that Ron (@debian.com -- I actually don't know his last name) has consistently and admirably made the most principled objections in the MTI codec conversation, over the course of several years. And Ron has posted many times in support of this plan. To be clear, I'm arguing from what I think is a principled place as well, and I'm the one who brought this plan to the WG (even though it's not what I would have preferred) -- but Ron seems to really be the torchbearer for a clearly principled stand here. /a From nobody Tue Dec 9 14:01:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E531F1A00E2 for ; Tue, 9 Dec 2014 14:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhrAIImmbd7p for ; Tue, 9 Dec 2014 14:01:46 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9F501A002B for ; Tue, 9 Dec 2014 14:01:45 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so2072051wgg.5 for ; Tue, 09 Dec 2014 14:01:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RCs1/bcVevozLtcrMVGatYVb489PoIDv8AI1KnsIDTI=; b=hVqGwgwxIvi15FvPXdDFF+O//Jr/Yxn4LO5eHCb7PRAD5ILsQXz77Vb1N/Apg6DTAr 8vdGRqT8cnD56IwvozLyWiNX+t/trrHZ8ieL1vMwHg+14LR1GMvnHNmC7Ns1SYidoqP7 /6h0RdBLcdiIZ1AeTcJgx1AKVwHt9Y8/Cy53aizs0jc/zfq7Xe5rzYeKX9yy8/Vy8TwQ 7m0S/YFdnUKqQOhuLSUz44SCi6wz0y7vCNwMlQbEwq3QL/zt770fB7Qvk3oQUu/YQcwf n2vs8PxHt1PdunNZy8EEvzwlGVE08PFTjUvbM5xx+nHbNdRioSKMDBO9qukBAxD362t4 Sh+A== X-Gm-Message-State: ALoCoQlRoP5N7EQ+J8HrrVzWd1aaMOENWx3pLxm4FMI5Jnx6IOTvIJQC39dsamaXZGaox95M1Pnk X-Received: by 10.194.19.38 with SMTP id b6mr1093424wje.44.1418162504613; Tue, 09 Dec 2014 14:01:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Tue, 9 Dec 2014 14:01:04 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 9 Dec 2014 23:01:04 +0100 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=047d7b472a945255b40509cfb0b4 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/yADk440sWGyNIiu5gLmK-PMrP5o Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 22:01:50 -0000 --047d7b472a945255b40509cfb0b4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 9, 2014 at 9:31 PM, Bernard Aboba wrote: > > Allowing an endpoint that implements video to call itself "WebRTC > compliant" without implementing either of the MTI codecs is so wrong-head= ed > that I am at a loss for words. > I believe you have misread the proposal. The term "WebRTC compliant" never appears anywhere in https://tools.ietf.org/html/draft-ietf-rtcweb-video-03. Indeed, the word "compliant" does not appear. Rather, endpoints which implement neither codec qualify as "WebRTC Compatible". -Ekr > On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway wrote= : > >> Thanks Sean, >> >> We can not support this draft at this time. >> >> As RTC SDK vendors we very likely will support both codecs, but we can >> not stand by a decision that will "impose" dual MTI on our developer >> community. >> >> According to this, every dev must use both codecs for every app that is >> built using our tools. Codec selection should be their choice and not be >> forced upon them. This seems to be a rather unreasonable expectation. >> >> >> *Erik Lagerway | *Hookflash >> * | 1 (855) Hookflash ext. 2 | Twitter >> | WebRTC.is Blog * >> >> On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner wrote: >> >>> All, >>> >>> At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion abou= t >>> codecs, which I dubbed "the great codec compromise." The compromise te= xt >>> that was discussed appears in slides 12-14 at [4] (which is a slight >>> editorial variation of the text proposed at [2]). >>> >>> This message serves to confirm the sense of the room. >>> >>> In the room, I heard the following objections and responses (and I=E2= =80=99m >>> paraphrasing here), which I=E2=80=99ll take the liberty of categorizing= as IPR, >>> Time, and Trigger: >>> >>> 1) IPR: >>> >>> Objections: There are still IPR concerns which may restrict what a >>> particular organization feels comfortable with including in their brows= er >>> implementations. >>> >>> Response: IPR concerns on this topic are well known. There is even a >>> draft summarizing the current IPR status for VP8: >>> draft-benham-rtcweb-vp8litigation. The sense of the room was still tha= t >>> adopting the compromise text was appropriate. >>> >>> 2) Time: >>> >>> 2.1) Time to consider decision: >>> >>> Objection: The decision to consider the compromise proposal at this >>> meeting was provided on short notice and did not provide some the >>> opportunity to attend in person. >>> >>> Response: Six months ago the chairs made it clear discussion would be >>> revisited @ IETF 91 [0]. The first agenda proposal for the WG included = this >>> topic [1], and the topic was never removed by the chairs. More >>> importantly, all decisions are confirmed on list; in person attendance = is >>> not required to be part of the process. >>> >>> 2.2) Time to consider text: >>> >>> Objection: The proposed text [2] is too new to be considered. >>> >>> Response: The requirement for browsers to support both VP8 and H.264 wa= s >>> among the options in the straw poll conducted more than six months ago. >>> All decisions are confirmed on list so there will be ample time to disc= uss >>> the proposal. >>> >>> 3) Trigger: >>> >>> Objection: The =E2=80=9Ctrigger=E2=80=9D sentence [3] is all kinds of w= rong because it=E2=80=99s >>> promising that the future IETF will update this specification. >>> >>> Response: Like any IETF proposal, an RFC that documents the current >>> proposal can be changed through the consensus process at any other time= . >>> >>> >>> After the discussion, some clarifying questions about the hums, and >>> typing the hum questions on the screen, there was rough consensus in th= e >>> room to add (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draft-= ietf-rtcweb-video. >>> In keeping with IETF process, I am confirming this consensus call on th= e >>> list. >>> >>> If anyone has any other issues that they would like to raise please do >>> by December 19th. >>> >>> Cheers, >>> spt (as chair) >>> >>> [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html >>> [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html >>> [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html >>> [3] The one that begins with "If compelling evidence ..." >>> [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b472a945255b40509cfb0b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Dec 9, 2014 at 9:31 PM, Bernard Aboba <bernard.aboba@gmail.c= om> wrote:
Allowing an = endpoint that implements video to call itself "WebRTC compliant" = without implementing either of the MTI codecs is so wrong-headed that I am = at a loss for words.

I believe = you have misread the proposal. The term "WebRTC compliant" never = appears
"compliant" does not appea= r.

Rather, endpoints which implement neither codec= qualify as "WebRTC Compatible".

-Ekr


On Tue, Dec 9, 2014 at = 12:16 PM, Erik Lagerway <erik@hookflash.com> wrote:
Thanks Sean,

We can = not support this draft at this time.

As RTC SDK vendors = we very likely will support both codecs, but we can not stand by a decision= that will "impose" dual MTI on our developer community.

According to this, every dev must use both codecs for ever= y app that is built using our tools. Codec selection should be their choice= and not be forced upon them. This seems to be a rather unreasonable expect= ation.


Erik Lagerway=C2=A0|=C2=A0<= span style=3D"color:rgb(0,0,0);font-size:13px">Hookflash=C2=A0| 1 (855)= =C2=A0Hookflash ext. 2 |=C2=A0Twitter=C2=A0|=C2=A0WebRTC.is Blog=C2=A0<= /b>
= <= /span>

On Fri, Dec 5, 2014 at 5= :36 AM, Sean Turner <turners@ieca.com> wrote:
=
All,

At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about co= decs, which I dubbed "the great codec compromise."=C2=A0 The comp= romise text that was discussed appears in slides 12-14 at [4] (which is a s= light editorial variation of the text proposed at [2]).

This message serves to confirm the sense of the room.

In the room, I heard the following objections and responses (and I=E2=80=99= m paraphrasing here), which I=E2=80=99ll take the liberty of categorizing a= s IPR, Time, and Trigger:

1) IPR:

Objections: There are still IPR concerns which may restrict what a particul= ar organization feels comfortable with including in their browser implement= ations.

Response:=C2=A0 IPR concerns on this topic are well known.=C2=A0 There is e= ven a draft summarizing the current IPR status for VP8: draft-benham-rtcweb= -vp8litigation.=C2=A0 The sense of the room was still that adopting the com= promise text was appropriate.

2) Time:

2.1) Time to consider decision:

Objection: The decision to consider the compromise proposal at this meeting= was provided on short notice and did not provide some the opportunity to a= ttend in person.

Response:=C2=A0 Six months ago the chairs made it clear discussion would be= revisited @ IETF 91 [0]. The first agenda proposal for the WG included thi= s topic [1], and the topic was never removed by the chairs.=C2=A0 =C2=A0 Mo= re importantly, all decisions are confirmed on list; in person attendance i= s not required to be part of the process.

2.2) Time to consider text:

Objection: The proposed text [2] is too new to be considered.

Response: The requirement for browsers to support both VP8 and H.264 was am= ong the options in the straw poll conducted more than six months ago.=C2=A0= All decisions are confirmed on list so there will be ample time to discuss= the proposal.

3) Trigger:

Objection: The =E2=80=9Ctrigger=E2=80=9D sentence [3] is all kinds of wrong= because it=E2=80=99s promising that the future IETF will update this speci= fication.

Response: Like any IETF proposal, an RFC that documents the current proposa= l can be changed through the consensus process at any other time.


After the discussion, some clarifying questions about the hums, and typing = the hum questions on the screen, there was rough consensus in the room to a= dd (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draft-ietf-rtcweb-v= ideo.=C2=A0 In keeping with IETF process, I am confirming this consensus ca= ll on the list.

If anyone has any other issues that they would like to raise please do by D= ecember 19th.

Cheers,
spt (as chair)

[0] http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg11194.html
[1] http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg13150.html
[2] http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg13432.html
[3] The one that begins with "If compelling evidence ..."
[4] http://www.ietf.org/proceedings/91/slides/slides-91= -rtcweb-7.pdf
_______________________________________________
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



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--047d7b472a945255b40509cfb0b4-- From nobody Tue Dec 9 14:44:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAD31A6EE7 for ; Tue, 9 Dec 2014 14:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrhLljSifIot for ; Tue, 9 Dec 2014 14:44:08 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id AAC011A3BA1 for ; Tue, 9 Dec 2014 14:44:07 -0800 (PST) Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail05.adl6.internode.on.net with ESMTP; 10 Dec 2014 09:13:47 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 1CB89FFCAD for ; Wed, 10 Dec 2014 09:13:46 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fcTuWexhPn1e for ; Wed, 10 Dec 2014 09:13:45 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 7B020FF892 for ; Wed, 10 Dec 2014 09:13:45 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 7013F80470; Wed, 10 Dec 2014 09:13:45 +1030 (ACDT) Date: Wed, 10 Dec 2014 09:13:45 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141209224345.GJ19538@hex.shelbyville.oz> References: <5486C48D.8040602@alvestrand.no> <54873575.3030804@nostrum.com> <54874B66.5050700@nostrum.com> <9BDCD7D8-B274-4970-A01B-D31069AEA935@phonefromhere.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Kfc0x8rZ5H3nfUNAFTAr9gYD198 Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2014 22:44:10 -0000 On Tue, Dec 09, 2014 at 12:29:46PM -0800, David Singer wrote: > > An earlier suggestion on this thread was that one could be conformant > with the WebRTC specs if one simply claimed that one was building a > webrtc-compatible endpoint; even if the implementation was of webrtc, > in a browser, it would not be labeled as “WebRTC Browserâ€. > > That, to me, is sleight of hand; a neat trick, but not quite what we > want to have happen. I’d rather not suggest it to anyone. Those definitions aren't badges you get to sew onto your scout uniform to claim as some level of achievement or entitlement. They are descriptive jargon that lets us refer to those things in other areas of the spec without having to be repetitively verbose. If what you build is a compatible endpoint, then what you have is a compatible endpoint. If what you build is a half-assed browser, then what you have is a half-assed browser. What your marketing dept. chooses to call it is none of our business. There are people who like to call Theora a "proprietary codec" and call H.264 an "open standard", but nobody actually buys that bullshit either. Nothing about this proposal is about weasel words or smoke and mirrors, it's about establishing the benchmarks we think are needed to have the best chance of interoperability. Some people will have extenuating circumstances that mean they simply can't fulfill every requirement. This compromise acknowledged that from the outset. Some of us *are* going to have difficulties complying with the onerous requirements of the selectively enforced H.264 licencing, and in some cases may not be able to distribute it at all in any general way, even if the code does ostensibly have support for it. Or even if we distribute it, the end user may not be permitted to use it in the way they wish to, or at all. Don't forget that you aren't licenced to shoot and freely distribute videos in H.264 using the professional video camera you bought which came with a licence to H.264 ... if that's not the pinnacle of braindead restrictive practices, founded on a sense of unrestrained entitlement to a stranglehold on the work of others, then I can't wait to see the full glorious irony of what is. Some of us have code that is freely distributed in unrestrictedly international markets. That includes countries that would laugh at any attempt to enforce IPR on software -- and possibly even countries where the H.264 patent holders are embargoed from being able to legally enter into business agreements with users and companies there (I've not actually looked to see if that is currently the case, but even if it is not at present, it seems like a not impossible future circumstance). There are a long list of principles and problems beyond "objecting to paying fees" (which afaics is a complete strawman that nobody has ever claimed to object to). If everybody who actually can makes a best effort, I think we'll manage a high level of interop, despite these known problems, until the video codec WG gives us a real solution (where we can reprise the fun of having the same group of people try to obstruct it in the same tiring ways again too!). We have commitments from enough of the major players to put that on a fairly solid foundation right from the start. If people who could comply to this simply don't want to, and would prefer to make up some meretricious pretense about that instead of doing so, then we can't stop them from doing that. But as people opposing this have been so fond of pointing out - the market will in all probability decide on their fate, right? It's never easy to get a dead whale off your beach. But if some of us don't pull together and try, it's going to stink the place up for a whole lot longer and ruin it for everyone. I'm willing to hold my nose for a little while to help with that, though I don't speak for anyone but myself. Vomeronasally, Ron From nobody Tue Dec 9 17:04:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD06A1A0366 for ; Tue, 9 Dec 2014 17:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TH01hXwS9ByF for ; Tue, 9 Dec 2014 17:03:56 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76CB1A0162 for ; Tue, 9 Dec 2014 17:03:55 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id a1so2370934wgh.9 for ; Tue, 09 Dec 2014 17:03:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kQ9WPPViFuW58tvupJMLJzH4IPHQGuCtBMdWhlFcZ2U=; b=Y6n5G1or0mgyvbcjnoxv/gm6XQhtVW031kqMK25SIizwMqBAEtslTJ99JceS/XCB5+ fhmVTgXP9kxgu8gnI+8hUcCGWXxvvfc6yXdX92t19iJ5YRlYpWQZUayb+v1XdboOn0hK hmpRrcQAeVhG0xsaxsRb1vyK5rdKqADfpfpAsoSOaq8CDTE9wr4Xamc25HQ6w8JuW2TV J2K3aEmwBF6D8BYeVsnVZeeqHdyJtpkfM2Wrfpg2Knikv6OqWW7hS5g5zKtFE++/MPu7 8tUrqOBniGVgZG/ijzladQINHGToHqjgCTxhjBcvqWh9+fhK0eDuk3TVueNHQ4F9t5yf MwxA== X-Received: by 10.180.104.65 with SMTP id gc1mr1847134wib.46.1418173434593; Tue, 09 Dec 2014 17:03:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.211.131 with HTTP; Tue, 9 Dec 2014 17:03:34 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Tue, 9 Dec 2014 17:03:34 -0800 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=f46d043bdb76cc87120509d23b73 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/acICq6ak_W4CWOV5ko7CCyln9dw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 01:04:01 -0000 --f46d043bdb76cc87120509d23b73 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My bad. New question: How can an endpoint that implements video but none of the MTI codecs be construed as "WebRTC Compatible"? On Tue, Dec 9, 2014 at 2:01 PM, Eric Rescorla wrote: > > On Tue, Dec 9, 2014 at 9:31 PM, Bernard Aboba > wrote: >> >> Allowing an endpoint that implements video to call itself "WebRTC >> compliant" without implementing either of the MTI codecs is so wrong-hea= ded >> that I am at a loss for words. >> > > I believe you have misread the proposal. The term "WebRTC compliant" neve= r > appears > anywhere in https://tools.ietf.org/html/draft-ietf-rtcweb-video-03. > Indeed, the word > "compliant" does not appear. > > Rather, endpoints which implement neither codec qualify as "WebRTC > Compatible". > > -Ekr > > >> On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway >> wrote: >> >>> Thanks Sean, >>> >>> We can not support this draft at this time. >>> >>> As RTC SDK vendors we very likely will support both codecs, but we can >>> not stand by a decision that will "impose" dual MTI on our developer >>> community. >>> >>> According to this, every dev must use both codecs for every app that is >>> built using our tools. Codec selection should be their choice and not b= e >>> forced upon them. This seems to be a rather unreasonable expectation. >>> >>> >>> *Erik Lagerway | *Hookflash >>> * | 1 (855) Hookflash ext. 2 | Twitter >>> | WebRTC.is Blog * >>> >>> On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner wrote: >>> >>>> All, >>>> >>>> At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion >>>> about codecs, which I dubbed "the great codec compromise." The compro= mise >>>> text that was discussed appears in slides 12-14 at [4] (which is a sli= ght >>>> editorial variation of the text proposed at [2]). >>>> >>>> This message serves to confirm the sense of the room. >>>> >>>> In the room, I heard the following objections and responses (and I=E2= =80=99m >>>> paraphrasing here), which I=E2=80=99ll take the liberty of categorizin= g as IPR, >>>> Time, and Trigger: >>>> >>>> 1) IPR: >>>> >>>> Objections: There are still IPR concerns which may restrict what a >>>> particular organization feels comfortable with including in their brow= ser >>>> implementations. >>>> >>>> Response: IPR concerns on this topic are well known. There is even a >>>> draft summarizing the current IPR status for VP8: >>>> draft-benham-rtcweb-vp8litigation. The sense of the room was still th= at >>>> adopting the compromise text was appropriate. >>>> >>>> 2) Time: >>>> >>>> 2.1) Time to consider decision: >>>> >>>> Objection: The decision to consider the compromise proposal at this >>>> meeting was provided on short notice and did not provide some the >>>> opportunity to attend in person. >>>> >>>> Response: Six months ago the chairs made it clear discussion would be >>>> revisited @ IETF 91 [0]. The first agenda proposal for the WG included= this >>>> topic [1], and the topic was never removed by the chairs. More >>>> importantly, all decisions are confirmed on list; in person attendance= is >>>> not required to be part of the process. >>>> >>>> 2.2) Time to consider text: >>>> >>>> Objection: The proposed text [2] is too new to be considered. >>>> >>>> Response: The requirement for browsers to support both VP8 and H.264 >>>> was among the options in the straw poll conducted more than six months >>>> ago. All decisions are confirmed on list so there will be ample time = to >>>> discuss the proposal. >>>> >>>> 3) Trigger: >>>> >>>> Objection: The =E2=80=9Ctrigger=E2=80=9D sentence [3] is all kinds of = wrong because >>>> it=E2=80=99s promising that the future IETF will update this specifica= tion. >>>> >>>> Response: Like any IETF proposal, an RFC that documents the current >>>> proposal can be changed through the consensus process at any other tim= e. >>>> >>>> >>>> After the discussion, some clarifying questions about the hums, and >>>> typing the hum questions on the screen, there was rough consensus in t= he >>>> room to add (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draft= -ietf-rtcweb-video. >>>> In keeping with IETF process, I am confirming this consensus call on t= he >>>> list. >>>> >>>> If anyone has any other issues that they would like to raise please do >>>> by December 19th. >>>> >>>> Cheers, >>>> spt (as chair) >>>> >>>> [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html >>>> [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html >>>> [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html >>>> [3] The one that begins with "If compelling evidence ..." >>>> [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf >>>> _______________________________________________ >>>> 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 >>> >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --f46d043bdb76cc87120509d23b73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My bad.=C2=A0

New question:= =C2=A0 How can an endpoint that implements video but=C2=A0none of the MTI c= odecs be construed as "WebRTC Compatible"?=C2=A0

On Tue, Dec 9, 2014 a= t 2:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:

On Tue, Dec 9, 2014 at 9:31 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
Allowing an endpoint that implements video to call itself "= WebRTC compliant" without implementing either of the MTI codecs is so = wrong-headed that I am at a loss for words.
I believe you have misread the proposal. The term "= ;WebRTC compliant" never appears
"compliant" does not appear.

Rather, endpoints which implement neither codec qualify as "WebRTC Co= mpatible".

-Ekr
<= div>

On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway <e= rik@hookflash.com> wrote:
Thanks Sean,

We can not support this draft at th= is time.

As RTC SDK vendors we very likely will support = both codecs, but we can not stand by a decision that will "impose"= ; dual MTI on our developer community.

According t= o this, every dev must use both codecs for every app that is built using ou= r tools. Codec selection should be their choice and not be forced upon them= . This seems to be a rather unreasonable expectation.


= Erik Lagerway=C2=A0|=C2=A0= Hookflash<= font color=3D"#943634">=C2=A0| 1 (855)= =C2=A0Hookflash ext. 2 |=C2=A0Twitter=C2=A0|= =C2=A0WebRTC.is Blog=C2=A0=
=

On Fri, Dec 5, 2014 at 5= :36 AM, Sean Turner <turners@ieca.com> wrote:
=
All,

At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about co= decs, which I dubbed "the great codec compromise."=C2=A0 The comp= romise text that was discussed appears in slides 12-14 at [4] (which is a s= light editorial variation of the text proposed at [2]).

This message serves to confirm the sense of the room.

In the room, I heard the following objections and responses (and I=E2=80=99= m paraphrasing here), which I=E2=80=99ll take the liberty of categorizing a= s IPR, Time, and Trigger:

1) IPR:

Objections: There are still IPR concerns which may restrict what a particul= ar organization feels comfortable with including in their browser implement= ations.

Response:=C2=A0 IPR concerns on this topic are well known.=C2=A0 There is e= ven a draft summarizing the current IPR status for VP8: draft-benham-rtcweb= -vp8litigation.=C2=A0 The sense of the room was still that adopting the com= promise text was appropriate.

2) Time:

2.1) Time to consider decision:

Objection: The decision to consider the compromise proposal at this meeting= was provided on short notice and did not provide some the opportunity to a= ttend in person.

Response:=C2=A0 Six months ago the chairs made it clear discussion would be= revisited @ IETF 91 [0]. The first agenda proposal for the WG included thi= s topic [1], and the topic was never removed by the chairs.=C2=A0 =C2=A0 Mo= re importantly, all decisions are confirmed on list; in person attendance i= s not required to be part of the process.

2.2) Time to consider text:

Objection: The proposed text [2] is too new to be considered.

Response: The requirement for browsers to support both VP8 and H.264 was am= ong the options in the straw poll conducted more than six months ago.=C2=A0= All decisions are confirmed on list so there will be ample time to discuss= the proposal.

3) Trigger:

Objection: The =E2=80=9Ctrigger=E2=80=9D sentence [3] is all kinds of wrong= because it=E2=80=99s promising that the future IETF will update this speci= fication.

Response: Like any IETF proposal, an RFC that documents the current proposa= l can be changed through the consensus process at any other time.


After the discussion, some clarifying questions about the hums, and typing = the hum questions on the screen, there was rough consensus in the room to a= dd (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draft-ietf-rtcweb-v= ideo.=C2=A0 In keeping with IETF process, I am confirming this consensus ca= ll on the list.

If anyone has any other issues that they would like to raise please do by D= ecember 19th.

Cheers,
spt (as chair)

[0] http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg11194.html
[1] http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg13150.html
[2] http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg13432.html
[3] The one that begins with "If compelling evidence ..."
[4] http://www.ietf.org/proceedings/91/slides/slides-91= -rtcweb-7.pdf
_______________________________________________
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



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb



--f46d043bdb76cc87120509d23b73-- From nobody Tue Dec 9 17:22:14 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2CC1A1B3E for ; Tue, 9 Dec 2014 17:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzSUiZ33nV6x for ; Tue, 9 Dec 2014 17:22:12 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4921A1A62 for ; Tue, 9 Dec 2014 17:22:11 -0800 (PST) Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail05.adl6.internode.on.net with ESMTP; 10 Dec 2014 11:52:11 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 14F41FFCAD for ; Wed, 10 Dec 2014 11:52:09 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bGME8QLtESta for ; Wed, 10 Dec 2014 11:52:08 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 7C5F6FFB5D for ; Wed, 10 Dec 2014 11:52:08 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 6B81980470; Wed, 10 Dec 2014 11:52:08 +1030 (ACDT) Date: Wed, 10 Dec 2014 11:52:08 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141210012208.GK19538@hex.shelbyville.oz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/58RX-QY7Evbi2M4UQQqXPHMt3zo Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 01:22:13 -0000 On Tue, Dec 09, 2014 at 05:03:34PM -0800, Bernard Aboba wrote: > My bad. > > New question: How can an endpoint that implements video but none of the > MTI codecs be construed as "WebRTC Compatible"? And what about an endpoint that implements coffee making, but not audio? Do you see something in the document that doesn't explain this, or in Adam's repeated explanations that *this* proposal in no way changes anything about that? From nobody Tue Dec 9 20:49:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC2F1A1AA4 for ; Tue, 9 Dec 2014 20:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPQcqmax-nJe for ; Tue, 9 Dec 2014 20:48:57 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 93AE61A024E for ; Tue, 9 Dec 2014 20:48:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E1D697C36BE for ; Wed, 10 Dec 2014 05:48:52 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waB1MVKLwo2g for ; Wed, 10 Dec 2014 05:48:51 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:6004:c89f:bb68:a447] (unknown [IPv6:2001:470:de0a:27:6004:c89f:bb68:a447]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4D55C7C36AE for ; Wed, 10 Dec 2014 05:48:51 +0100 (CET) Message-ID: <5487D0B2.9070804@alvestrand.no> Date: Wed, 10 Dec 2014 05:48:50 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5486C48D.8040602@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060207030308030408060608" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/A0467tnH7AZzfqnFrmu4I1GnyHU Subject: [rtcweb] Incentives (Re: Video codecs: Clear positions....) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 04:49:00 -0000 This is a multi-part message in MIME format. --------------060207030308030408060608 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It's perhaps not surprising that I disagree with Bernard on every point he makes below, but since I respect Bernard quite a lot, I'll try to make it clear why. On 12/09/2014 09:10 PM, Bernard Aboba wrote: > David Singer said:=20 > > "I am trying to find out a simple answer: how many endpoints would, > in fact, expect to support both codecs?" > > [BA] The proposal has built-in incentives for implementers in each > category to either ignore the recommendations or ignore > interoperability (or both). =20 > > As it stands, the proposal doesn't require that "WebRTC-compatible > endpoints" support either H.264 or VP8. I understand why an endpoint > not supporting video shouldn't have to, but if the WebRTC-compatible > endpoint does support video, why shouldn't it support at least one of > the MTI codecs? The way it is written a WebRTC-compatible endpoint > that supported only H.261 would be compliant while being able to > communicate with either browsers or non-browsers, which seems silly. This is irrelevant to the proposal made. The term "WebRTC-compatible" is introduced solely to point out that there are things that will talk (successfully!) to WebRTC endpoints that aren't WebRTC - and there's nothing whatsoever we or anyone else can do to prevent that. > > The "non-browser" is required to support both codecs, but only until a > clause is triggered to choose a single MTI. For a "non-browser" such > as a mobile application, there is no real need to support both VP8 and > H.264, assuming that browsers support both. So I would expect most > folks in this category to ignore the recommendation or wait for the > "trigger" (then ignore that too if the selected codec isn't the one > they've already chosen). It would make more sense for this category > to mandate implementation of either VP8 or H.264 (implementer's > choice) and dump the trigger clause.=20 > > The "browser" subset is supposed to support both codecs. However, the > "trigger" clause for the "non-browser" case muddies the waters, > particularly in situations where implementing a previously > non-supported codec could take a while. Who wants to spend a lot of > effort implementing a codec that might not even be required by the > time the implementation is complete (and that will probably be > guaranteed to be obsolete by then anyway)?=20 I think the incentives here make sense. First off, let's assume that codec agility is a Good Thing. Most implementors I've talked to about codecs say that they intend to support codecs that aren't in the MTI, and won't be in the MTI any time soon. (this includes AVC-High profile as well as the next generation codecs HEVC and VP9). So the extra cost of implementing two MTI codecs is strictly limited to the cost of supporting the codec; the rest of the machinery for picking a codec is already present. People have sharply differing opinions on the quality they expect to get out of the two codecs. So we can assume from the get-go that there will be different preferences stated during negotiation. However, among those who don't prefer one codec for special reasons, one would expect market forces to work here; they will, over time, tend to prefer what works best (for whatever value of "best" makes sense for them). Implementing both gives flexibility here, which is a Good Thing. With regard to the stability of MTI (the "trigger clause"), I heard two concerns voiced: - The people for whom H.264 interoperability without transcoding is of paramount importance want assurance that their investment in browser-based systems is not lost due to a later MTI change. - The people for whom cost, silicon area or license freedom is of paramount importance want to make sure that if we're in a situation where a single codec clearly makes sense, they can go there. Given the size of a modern browser, the last group are *not* the browser vendors - supporting another middle-aged codec in software is just another piece of code. (modulo the Firefox "download dance", which *is* a complicating factor.) Having the "trigger clause", formulated the way it is, gives something to both these groups: The first group gets assurance that its browser-targeted investment is protected - the second group gets assurance that if a clearly sane (from their viewpoint) outcome is later possible, they can go for it. And the "trigger cause" serves as an additional incitement for *current* implementors to actually do both, in order to be future-proof; there's no telling which, if any, of the MTI codecs will actually reach the trigger condition first - and those implementors who have implemented both know that in the event of an MTI change, and a rollout of a large number of devices with only one codec, they will be able to interoperate without an upgrade - no matter which codec gets dropped. Summary: I think a lot of people have incentive to follow the recommendation. We should stick to our recommendation and move on. Harald --------------060207030308030408060608 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
It's perhaps not surprising that I disagree with Bernard on every point he makes below, but since I respect Bernard quite a lot, I'll try to make it clear why.

On 12/09/2014 09:10 PM, Bernard Aboba wrote:
David Singer said: 

"I am trying to find out a simple answer:  how many endpoints would, in fact, expect to support both codecs?"

[BA]  The proposal has built-in incentives for implementers in each category to either ignore the recommendations or ignore interoperability (or both).   

As it stands, the proposal doesn't require that "WebRTC-compatible endpoints" support either H.264 or VP8.  I understand why an endpoint not supporting video shouldn't have to, but if the WebRTC-compatible endpoint does support video, why shouldn't it support at least one of the MTI codecs?   The way it is written a WebRTC-compatible endpoint that supported only H.261 would be compliant while being able to communicate with either browsers or non-browsers, which seems silly.

This is irrelevant to the proposal made.
The term "WebRTC-compatible" is introduced solely to point out that there are things that will talk (successfully!) to WebRTC endpoints that aren't WebRTC - and there's nothing whatsoever we or anyone else can do to prevent that.


The "non-browser" is required to support both codecs, but only until a clause is triggered to choose a single MTI.  For a  "non-browser" such as a mobile application, there is no real need to support both VP8 and H.264, assuming that browsers support both.  So I would expect most folks in this category to ignore the recommendation or wait for the "trigger" (then ignore that too if the selected codec isn't the one they've already chosen).   It would make more sense for this category to mandate implementation of either VP8 or H.264 (implementer's choice) and dump the trigger clause. 

The "browser" subset is supposed to support both codecs.  However, the "trigger" clause for the "non-browser" case muddies the waters, particularly in situations where implementing a previously non-supported codec could take a while.  Who wants to spend a lot of effort implementing a codec that  might not even be required by the time the implementation is complete (and that will probably be guaranteed to be obsolete by then anyway)? 

I think the incentives here make sense.

First off, let's assume that codec agility is a Good Thing.
Most implementors I've talked to about codecs say that they intend to support codecs that aren't in the MTI, and won't be in the MTI any time soon. (this includes AVC-High profile as well as the next generation codecs HEVC and VP9).

So the extra cost of implementing two MTI codecs is strictly limited to the cost of supporting the codec; the rest of the machinery for picking a codec is already present.

People have sharply differing opinions on the quality they expect to get out of the two codecs. So we can assume from the get-go that there will be different preferences stated during negotiation.
However, among those who don't prefer one codec for special reasons, one would expect market forces to work here; they will, over time, tend to prefer what works best (for whatever value of "best" makes sense for them). Implementing both gives flexibility here, which is a Good Thing.

With regard to the stability of MTI (the "trigger clause"), I heard two concerns voiced:

- The people for whom H.264 interoperability without transcoding is of paramount importance want assurance that their investment in browser-based systems is not lost due to a later MTI change.

- The people for whom cost, silicon area or license freedom is of paramount importance want to make sure that if we're in a situation where a single codec clearly makes sense, they can go there.

Given the size of a modern browser, the last group are *not* the browser vendors - supporting another middle-aged codec in software is just another piece of code. (modulo the Firefox "download dance", which *is* a complicating factor.)

Having the "trigger clause", formulated the way it is, gives something to both these groups: The first group gets assurance that its browser-targeted investment is protected - the second group gets assurance that if a clearly sane (from their viewpoint) outcome is later possible, they can go for it.

And the "trigger cause" serves as an additional incitement for *current* implementors to actually do both, in order to be future-proof; there's no telling which, if any, of the MTI codecs will actually reach the trigger condition first - and those implementors who have implemented both know that in the event of an MTI change, and a rollout of a large number of devices with only one codec, they will be able to interoperate without an upgrade - no matter which codec gets dropped.

Summary: I think a lot of people have incentive to follow the recommendation.
We should stick to our recommendation and move on.

Harald


--------------060207030308030408060608-- From nobody Wed Dec 10 00:16:12 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806ED1A1B23 for ; Wed, 10 Dec 2014 00:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKyd2nUkEWP3 for ; Wed, 10 Dec 2014 00:16:05 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3FDE1A1F20 for ; Wed, 10 Dec 2014 00:16:03 -0800 (PST) Received: (qmail 11382 invoked from network); 10 Dec 2014 08:16:02 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 877 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 10 Dec 2014 08:16:02 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 5267B18A1047; Wed, 10 Dec 2014 08:16:02 +0000 (GMT) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 3E79F18A0B8E; Wed, 10 Dec 2014 08:16:02 +0000 (GMT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Tim Panton In-Reply-To: Date: Wed, 10 Dec 2014 08:16:01 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Bernard Aboba X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-ITwIw7K4PrAxbIUvn1HL9Jl1wU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 08:16:10 -0000 > On 10 Dec 2014, at 01:03, Bernard Aboba = wrote: >=20 > My bad.=20 >=20 > New question: How can an endpoint that implements video but none of = the MTI codecs be construed as "WebRTC Compatible=E2=80=9D?=20 At the risk of falling down the semantic trap you set, it could be = pushing an experimental webGL based codec over the data channel. or an art installation. It might implement encode only of one of the = MTIs - one way survelliance - or even encode on VP8 and decode on h264 because of some whacky licensing shenanigans. It is very easy to see these standards in terms of classic video calls, = while forgetting that the web is a wild and exciting place full of=20 strange and unexpected surprises. Tim. From nobody Wed Dec 10 00:33:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BFE1A01A5 for ; Wed, 10 Dec 2014 00:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKGMg-XCwmpo for ; Wed, 10 Dec 2014 00:33:25 -0800 (PST) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F15C1A0069 for ; Wed, 10 Dec 2014 00:33:25 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id m20so1766564qcx.40 for ; Wed, 10 Dec 2014 00:33:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=c8qr5LyRAIqQMyCKgvhqBcgHUhQZ1hx8v3uYdca2T0Q=; b=iBAn/ezldPLlm8unarcyblp4W4QxuLZ73xgTOvNkk+yI2fKzKrjoWctxXfRMLI7JBE GL1nPDWCksmM0Uf/uwO0ux1wSc8ErJKebpXNsbJQEiNk9Hzq4NilkISYiMaiHU4c4A9m M6YkpDsR8WFP0SejK/cGjVHvA7ArQcpBwLWGAJux2/nPtsYOr2jJC17daM8tBx+q/wnM lTxr4ucCQr8X48aZOL0Reqmn8Nm+Xq8XF1y3mHmDgtv+TpmSPxqvCZRfE2hIbZKu4Jdy O30xQ7FxAmluAXVb4JpxFe6oE9aOjD2q7VflEJbxkomjHwJC+N6xFtLqYfGhfLk+veTe bgdw== X-Gm-Message-State: ALoCoQkktSCfmdl0cX91IB8iblfbVPhfdxZMa5IvvZ3ZXLpuoTswvo+/v+u46mjrt0hKSY0qlcEO MIME-Version: 1.0 X-Received: by 10.224.51.11 with SMTP id b11mr5834198qag.43.1418200404423; Wed, 10 Dec 2014 00:33:24 -0800 (PST) Received: by 10.96.26.135 with HTTP; Wed, 10 Dec 2014 00:33:24 -0800 (PST) Received: by 10.96.26.135 with HTTP; Wed, 10 Dec 2014 00:33:24 -0800 (PST) In-Reply-To: References: Date: Wed, 10 Dec 2014 09:33:24 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tim Panton Content-Type: multipart/alternative; boundary=047d7bdcad4e538f3b0509d88388 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kZkQTtzcvMriSgicvSm1lQrgNN0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 08:33:27 -0000 --047d7bdcad4e538f3b0509d88388 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > New question: How can an endpoint that implements video but none of the MTI codecs be construed as "WebRTC Compatible=E2=80=9D? Even taking this subject into the telephony world: how can thousands of SIP phones that do not even support video be labeled as "RFC 3261 Compliant"? > At the risk of falling down the semantic trap you set, it could be pushing an experimental webGL based codec over the data channel. > or an art installation. It might implement encode only of one of the MTIs - one way survelliance - or even encode on VP8 and decode on h264 > because of some whacky licensing shenanigans. I see many use cases for bidirectional audio and just video decoding. > It is very easy to see these standards in terms of classic video calls, while forgetting that the web is a wild and exciting place full of > strange and unexpected surprises. +1 --047d7bdcad4e538f3b0509d88388 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


> > New question:=C2=A0 How can an endpoint that implements video but= none of the MTI codecs be construed as "WebRTC Compatible=E2=80=9D?

Even taking this subject into the telephony world: how can t= housands of SIP phones that do not even support video be labeled as "R= FC 3261 Compliant"?

> At the risk of falling down the semantic trap you set, = it could be pushing an experimental webGL based codec over the data channel= .
> or an art installation. It might implement encode only of one of the M= TIs - one way survelliance - or even encode on VP8 and decode on h264
> because of some whacky licensing shenanigans.

I see many use cases for bidirectional audio and just video = decoding.

> It is very easy to see these standards in terms of clas= sic video calls, while forgetting that the web is a wild and exciting place= full of
> strange and unexpected surprises.

+1

--047d7bdcad4e538f3b0509d88388-- From nobody Wed Dec 10 00:47:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076E61A88EB for ; Wed, 10 Dec 2014 00:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bduzzqz080F8 for ; Wed, 10 Dec 2014 00:47:27 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0901A88A8 for ; Wed, 10 Dec 2014 00:47:27 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so10428254wiv.5 for ; Wed, 10 Dec 2014 00:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=98O/F4TB4qaLh+YYpy6UOSgePQCysDXf4vDcJfDV4vw=; b=sN/t0kzpvh6QXZQ8CY8JYDSPq+g95MgtLIhjhGs3cib79BLUiay37Bo0HXtHM7yP7W vUwz14sStdc028kjZvrBJiod0N1vp82QmDcJi2vdDxgSmd2lrerMI9nOYjx2d4UQXIZg 1wFh/BeHKmYE8tBvrbAPVk/MccuqRWBkutx+7Hm8prCRy97i9VJ6oKiat4FCVmt6LpIV w4oAGxxoBDYNAGsT6LPUiN0GSUP4RvOl0ehUZenb+FMy1DZ1/c9DEx7u3x4YOBqBYLhb gtkl8pUD73+J4wskpMv4J3QnH/b9kd04Dsh5jIqMA5f9SD8xyggdtRZAfrxrUTQ/h3O1 lwwg== X-Received: by 10.194.62.163 with SMTP id z3mr4667191wjr.74.1418201246184; Wed, 10 Dec 2014 00:47:26 -0800 (PST) Received: from [192.168.0.194] ([95.61.111.78]) by mx.google.com with ESMTPSA id dm10sm17002781wib.18.2014.12.10.00.47.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 00:47:25 -0800 (PST) Message-ID: <5488089B.5020303@gmail.com> Date: Wed, 10 Dec 2014 09:47:23 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gbMc6R8-Lx_7-n97RDO-sLUcdfw Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 08:47:38 -0000 On 10/12/2014 9:16, Tim Panton wrote: > >> On 10 Dec 2014, at 01:03, Bernard Aboba wrote: >> >> My bad. >> >> New question: How can an endpoint that implements video but none of the MTI codecs be construed as "WebRTC Compatible� > At the risk of falling down the semantic trap you set, it could be pushing an experimental webGL based codec over the data channel. > or an art installation. It might implement encode only of one of the MTIs - one way survelliance - or even encode on VP8 and decode on h264 > because of some whacky licensing shenanigans. > > It is very easy to see these standards in terms of classic video calls, while forgetting that the web is a wild and exciting place full of > strange and unexpected surprises. Or you could implement a video chat application for multiple users and use only VP9. Check Google hangouts in a couple of months for that.. Best regards Sergio From nobody Wed Dec 10 03:18:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686FF1A1A19 for ; Wed, 10 Dec 2014 03:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qLRFettuJSp for ; Wed, 10 Dec 2014 03:18:19 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A091A19EC for ; Wed, 10 Dec 2014 03:18:18 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so4766996wiv.8 for ; Wed, 10 Dec 2014 03:18:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OvHITuQbh7R5tQ6IzLHNYq2nwIfqRyfqszN7x7hDuTI=; b=JO4R5B2+AB85/oUsVpp5IcwMOsbaDmIiqO6Rkm+5TSOcx4BPT3NuqvIIQgvrpUTp79 yzMOOBoM3DNfaz8tPrVUle+ESvVXZ2QE6S/wa3j2fjQ7ZibOqk7CljRiYDZyZJos7jkg wb47aA4G5kWuq/u1vtg1k/7BFAAdrbEDVjK16ZJzx2menmyU75Lq/53EyCedpFja1KIy yXg26DRV2p/TBqExD1VIUFIGUfI3up4RrVpAdEtM3AhkPZOTmR/0QkC2AhrNllWqaKIE cUCxUdm5cInOzh7EFYTVk2dX2QWlLmduF/dG+SvdaKkuiWpA8OAb2RdPVqITTiq93lNv YWZg== X-Gm-Message-State: ALoCoQlFlcd4BlPbhimWcStGW5mMjMe+41i92BXOGYO5QE3IN/oWnqmv03mM8MxWTTtYyPwhENY0 X-Received: by 10.180.98.138 with SMTP id ei10mr5556300wib.32.1418210297279; Wed, 10 Dec 2014 03:18:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Wed, 10 Dec 2014 03:17:36 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 10 Dec 2014 12:17:36 +0100 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=f46d044267fefc905d0509dad09d Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Gag_j5Cnx87t0hAoFwUoxJ8zxC8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 11:18:22 -0000 --f46d044267fefc905d0509dad09d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 10, 2014 at 2:03 AM, Bernard Aboba wrote: > My bad. > > New question: How can an endpoint that implements video but none of the > MTI codecs be construed as "WebRTC Compatible"? > Well, this seems like a generic complaint about the term "compatible", since such endpoints are explicitly not required to meet any requirements: A WebRTC-compatible endpoint is an endpoint that is able to successfully communicate with a WebRTC endpoint, but may fail to meet some requirements of a WebRTC endpoint. This may limit where in the network such an endpoint can be attached, or may limit the security guarantees that it offers to others. It is not constrained by this specification; when it is mentioned at all, it is to note the implications on WebRTC-compatible endpoints of the requirements placed on WebRTC endpoints. So, perhaps we need a new term, but this doesn't seem like an issue limited= to video codecs -Ekr On Tue, Dec 9, 2014 at 2:01 PM, Eric Rescorla wrote: > >> >> On Tue, Dec 9, 2014 at 9:31 PM, Bernard Aboba >> wrote: >>> >>> Allowing an endpoint that implements video to call itself "WebRTC >>> compliant" without implementing either of the MTI codecs is so wrong-he= aded >>> that I am at a loss for words. >>> >> >> I believe you have misread the proposal. The term "WebRTC compliant" >> never appears >> anywhere in https://tools.ietf.org/html/draft-ietf-rtcweb-video-03. >> Indeed, the word >> "compliant" does not appear. >> >> Rather, endpoints which implement neither codec qualify as "WebRTC >> Compatible". >> >> -Ekr >> >> >>> On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway >>> wrote: >>> >>>> Thanks Sean, >>>> >>>> We can not support this draft at this time. >>>> >>>> As RTC SDK vendors we very likely will support both codecs, but we can >>>> not stand by a decision that will "impose" dual MTI on our developer >>>> community. >>>> >>>> According to this, every dev must use both codecs for every app that i= s >>>> built using our tools. Codec selection should be their choice and not = be >>>> forced upon them. This seems to be a rather unreasonable expectation. >>>> >>>> >>>> *Erik Lagerway | *Hookflash >>>> * | 1 (855) Hookflash ext. 2 | Twitter >>>> | WebRTC.is Blog * >>>> >>>> On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner wrote: >>>> >>>>> All, >>>>> >>>>> At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion >>>>> about codecs, which I dubbed "the great codec compromise." The compr= omise >>>>> text that was discussed appears in slides 12-14 at [4] (which is a sl= ight >>>>> editorial variation of the text proposed at [2]). >>>>> >>>>> This message serves to confirm the sense of the room. >>>>> >>>>> In the room, I heard the following objections and responses (and I=E2= =80=99m >>>>> paraphrasing here), which I=E2=80=99ll take the liberty of categorizi= ng as IPR, >>>>> Time, and Trigger: >>>>> >>>>> 1) IPR: >>>>> >>>>> Objections: There are still IPR concerns which may restrict what a >>>>> particular organization feels comfortable with including in their bro= wser >>>>> implementations. >>>>> >>>>> Response: IPR concerns on this topic are well known. There is even = a >>>>> draft summarizing the current IPR status for VP8: >>>>> draft-benham-rtcweb-vp8litigation. The sense of the room was still t= hat >>>>> adopting the compromise text was appropriate. >>>>> >>>>> 2) Time: >>>>> >>>>> 2.1) Time to consider decision: >>>>> >>>>> Objection: The decision to consider the compromise proposal at this >>>>> meeting was provided on short notice and did not provide some the >>>>> opportunity to attend in person. >>>>> >>>>> Response: Six months ago the chairs made it clear discussion would b= e >>>>> revisited @ IETF 91 [0]. The first agenda proposal for the WG include= d this >>>>> topic [1], and the topic was never removed by the chairs. More >>>>> importantly, all decisions are confirmed on list; in person attendanc= e is >>>>> not required to be part of the process. >>>>> >>>>> 2.2) Time to consider text: >>>>> >>>>> Objection: The proposed text [2] is too new to be considered. >>>>> >>>>> Response: The requirement for browsers to support both VP8 and H.264 >>>>> was among the options in the straw poll conducted more than six month= s >>>>> ago. All decisions are confirmed on list so there will be ample time= to >>>>> discuss the proposal. >>>>> >>>>> 3) Trigger: >>>>> >>>>> Objection: The =E2=80=9Ctrigger=E2=80=9D sentence [3] is all kinds of= wrong because >>>>> it=E2=80=99s promising that the future IETF will update this specific= ation. >>>>> >>>>> Response: Like any IETF proposal, an RFC that documents the current >>>>> proposal can be changed through the consensus process at any other ti= me. >>>>> >>>>> >>>>> After the discussion, some clarifying questions about the hums, and >>>>> typing the hum questions on the screen, there was rough consensus in = the >>>>> room to add (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draf= t-ietf-rtcweb-video. >>>>> In keeping with IETF process, I am confirming this consensus call on = the >>>>> list. >>>>> >>>>> If anyone has any other issues that they would like to raise please d= o >>>>> by December 19th. >>>>> >>>>> Cheers, >>>>> spt (as chair) >>>>> >>>>> [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html >>>>> [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html >>>>> [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html >>>>> [3] The one that begins with "If compelling evidence ..." >>>>> [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >> > --f46d044267fefc905d0509dad09d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Dec 10, 2014 at 2:03 AM, Bernard Aboba <bernard.aboba@gmail.com<= /a>> wrote:
My bad.=C2= =A0

New question:=C2=A0 How can an endpoint that = implements video but=C2=A0none of the MTI codecs be construed as "WebR= TC Compatible"?=C2=A0

Well= , this seems like a generic complaint about the term "compatible"= , since such
endpoints are explicitly not required to meet any re= quirements:

     A WebRTC-compatible endpoint is an endpoint that =
is able to
      successfully communicate with a WebRTC endpoint, but may fail to
      meet some requirements of a WebRTC endpoint.  This may limit where
      in the network such an endpoint can be attached, or may limit the
      security guarantees that it offers to others.  It is not
      constrained by this specification; when it is mentioned at all, it
      is to note the implications on WebRTC-compatible endpoints of the
      requirements placed on WebRTC endpoints.
<=
font face=3D"arial, helvetica, sans-serif">
=
So, perhaps we need a new term,=
 but this doesn't seem like an issue limited to
video codecs
<= pre class=3D"" style=3D"font-size:1em;margin-top:0px;margin-bottom:0px;colo= r:rgb(0,0,0)">
= 
-Ekr

On Tue, Dec 9= , 2014 at 2:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:

On Tue, Dec 9, 2014 at 9:31 PM, Bernard Aboba <berna= rd.aboba@gmail.com> wrote:
<= div>Allowing an endpoint that implements video to call itself "WebRTC = compliant" without implementing either of the MTI codecs is so wrong-h= eaded that I am at a loss for words.

I believe you have misread the proposal. The term "WebRTC= compliant" never appears
=
"compliant" does not appear.

Rather= , endpoints which implement neither codec qualify as "WebRTC Compatibl= e".

-Ekr


On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway <erik@hookflash.com> wrote:
Thanks Sean,<= /div>

We can not support this draft at this time.

As RTC SDK vendors we very likely will support both codecs, but we = can not stand by a decision that will "impose" dual MTI on our de= veloper community.

According to this, every dev mu= st use both codecs for every app that is built using our tools. Codec selec= tion should be their choice and not be forced upon them. This seems to be a= rather unreasonable expectation.
<= br>

Erik Lagerway=C2=A0|=C2=A0Hookfl= ash=C2=A0| 1 (855)=C2=A0H= ookflash ext. 2 |=C2=A0Twitter=C2=A0|=C2=A0WebRTC.is= Blog=C2=A0
<= span style=3D"color:rgb(148,54,52);line-height:14px;font-size:10pt">=

On Fri, Dec 5, 2014 at 5= :36 AM, Sean Turner <turners@ieca.com> wrote:
=
All,

At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about co= decs, which I dubbed "the great codec compromise."=C2=A0 The comp= romise text that was discussed appears in slides 12-14 at [4] (which is a s= light editorial variation of the text proposed at [2]).

This message serves to confirm the sense of the room.

In the room, I heard the following objections and responses (and I=E2=80=99= m paraphrasing here), which I=E2=80=99ll take the liberty of categorizing a= s IPR, Time, and Trigger:

1) IPR:

Objections: There are still IPR concerns which may restrict what a particul= ar organization feels comfortable with including in their browser implement= ations.

Response:=C2=A0 IPR concerns on this topic are well known.=C2=A0 There is e= ven a draft summarizing the current IPR status for VP8: draft-benham-rtcweb= -vp8litigation.=C2=A0 The sense of the room was still that adopting the com= promise text was appropriate.

2) Time:

2.1) Time to consider decision:

Objection: The decision to consider the compromise proposal at this meeting= was provided on short notice and did not provide some the opportunity to a= ttend in person.

Response:=C2=A0 Six months ago the chairs made it clear discussion would be= revisited @ IETF 91 [0]. The first agenda proposal for the WG included thi= s topic [1], and the topic was never removed by the chairs.=C2=A0 =C2=A0 Mo= re importantly, all decisions are confirmed on list; in person attendance i= s not required to be part of the process.

2.2) Time to consider text:

Objection: The proposed text [2] is too new to be considered.

Response: The requirement for browsers to support both VP8 and H.264 was am= ong the options in the straw poll conducted more than six months ago.=C2=A0= All decisions are confirmed on list so there will be ample time to discuss= the proposal.

3) Trigger:

Objection: The =E2=80=9Ctrigger=E2=80=9D sentence [3] is all kinds of wrong= because it=E2=80=99s promising that the future IETF will update this speci= fication.

Response: Like any IETF proposal, an RFC that documents the current proposa= l can be changed through the consensus process at any other time.


After the discussion, some clarifying questions about the hums, and typing = the hum questions on the screen, there was rough consensus in the room to a= dd (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draft-ietf-rtcweb-v= ideo.=C2=A0 In keeping with IETF process, I am confirming this consensus ca= ll on the list.

If anyone has any other issues that they would like to raise please do by D= ecember 19th.

Cheers,
spt (as chair)

[0] http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg11194.html
[1] http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg13150.html
[2] http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg13432.html
[3] The one that begins with "If compelling evidence ..."
[4] http://www.ietf.org/proceedings/91/slides/slides-91= -rtcweb-7.pdf
_______________________________________________
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



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb



--f46d044267fefc905d0509dad09d-- From nobody Wed Dec 10 04:36:50 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49FF1A8733 for ; Wed, 10 Dec 2014 04:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfHFJMdjd8pc for ; Wed, 10 Dec 2014 04:36:40 -0800 (PST) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8C01A896B for ; Wed, 10 Dec 2014 04:36:38 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id w7so2031697qcr.0 for ; Wed, 10 Dec 2014 04:36:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=vGGyqtwvTdom+lDj2PlTLO6SE/w7RXckTRXd6ldOYSM=; b=Y7PAvzhvuX4oAE3ZYyvM8/aWXRnxGCK/I8SH/J1AliGMoCEjNGWgx7ouWJfbDhRSjo JbWnE1RhBWnU9zVrITpMOhnm9csc+A1RBMgeldkBQAZ9MIt4ht8lsKKDo8iFOFLK8Ku1 Fc2NZ5u5p8q5/brH5d0LcC2GT/jqC8nXxTKclqJ+xVH4ycwnaFy5KSJkwqZ3SQKVdRzS wM6g6Vura28mKFAA96TL0MgZ5YzcP9NTl4C39ZamOBBRB6TiHsB+QNv1vATN1x/t49oj sQg+AISpQ7ftfGORodapCfDLE56MJ2CCfeD+0ZFD/ottdGNDIOy4+ZOxD0q0EXJwRnPi bOkw== X-Gm-Message-State: ALoCoQkf2Qq8eIgxC3rwF42jDg/hNOTxQUIUSlDBwa6il84YxGvXsVvIfJnzlBjxiAzghe6v9Qe5 X-Received: by 10.140.101.145 with SMTP id u17mr7530865qge.84.1418214997780; Wed, 10 Dec 2014 04:36:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Wed, 10 Dec 2014 04:36:17 -0800 (PST) In-Reply-To: <5487331F.8050404@bbs.darktech.org> References: <5486C48D.8040602@alvestrand.no> <5487331F.8050404@bbs.darktech.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 10 Dec 2014 13:36:17 +0100 Message-ID: To: cowwoc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1qkvmxgi-k_Tze-3Ezh8PS4_vPk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 12:36:41 -0000 2014-12-09 18:36 GMT+01:00 cowwoc : >> Honestly, a +1 for =E2=80=9Cthose other people should do it=E2=80=9D is = meaningless. > > > That's a fair point. I'm guessing the vast majority of people answering o= n > the mailing list only plan to implement one codec because they are > non-browser implementors. And probably many people give +1 to "MUST implement both codecs" so they will just implement H264 in their systems and win anyhow. --=20 I=C3=B1aki Baz Castillo From nobody Wed Dec 10 04:42:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9571A88D3 for ; Wed, 10 Dec 2014 04:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-e_lzPHgCWd for ; Wed, 10 Dec 2014 04:42:05 -0800 (PST) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900871A1BC0 for ; Wed, 10 Dec 2014 04:42:05 -0800 (PST) Received: by mail-qg0-f41.google.com with SMTP id j5so2011971qga.28 for ; Wed, 10 Dec 2014 04:42:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Aqxh/9Kmuqd8S5OmprAkj4zzxOk0s3XNpte5B0fH/bo=; b=JLB71iFicKYzcYb/Y6R7VLWSHTgxJ6t4omTnPmVjHvrNh+mljHWW8k1LP8o9aK0S0E dhGTKHjKRd1lgqHVV3sWJ8rfR6GYNVAXH4+C7PGaxJmdLmdqb8DfWOxnu4v7Pjh494eA 5im8mUcinLwfADtdpHA+GB+1/oVuzETf8DC984FRmYZtilHJmoVNNDWtSozFJL/3QY+k tbTt8i5oPRmReHrQD3gRGYSkfD52N62Lr+vic80qjvQh98B1rCY4/PEc3aJp+ipXE1YA CwC+5dfekZJoHVQAOyNJbaaWfL/TVbLxCLDgWJfttUX7E/pm7Ye9wUSUdHGn71iPvPgQ yajQ== X-Gm-Message-State: ALoCoQmQ/TF5Opfjp82mnLVQaPZqV8794Z72BUb3d35I06n2M9ALg/m1zFNcSCwQ4WswMu23nP7+ X-Received: by 10.140.22.83 with SMTP id 77mr7475113qgm.19.1418215324824; Wed, 10 Dec 2014 04:42:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Wed, 10 Dec 2014 04:41:44 -0800 (PST) In-Reply-To: <54873575.3030804@nostrum.com> References: <5486C48D.8040602@alvestrand.no> <54873575.3030804@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 10 Dec 2014 13:41:44 +0100 Message-ID: To: Adam Roach Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TFejCPGk2d9wJ1N5nhtFT-96y5I Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 12:42:07 -0000 2014-12-09 18:46 GMT+01:00 Adam Roach : > On 12/9/14 11:32, David Singer wrote: >> >> I would also like to know from those confirming the sense of the room, >> whether THEY THEMSELVES intend to... > > > Wait, you're pressing other companies for future product plans? With the > implication that doing so is a prerequisite to participating in the > discussion? > > That's a mighty sharp blade there. You might check where it's pointed. According to what I understand, someone announcing that he or his company will implement both codecs is not about announcing a "product feature", but just the fact that such a product will be "WebRTC compliant". And that is what all of this subject is about, isn't? --=20 I=C3=B1aki Baz Castillo From nobody Wed Dec 10 04:55:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE591A3B9F for ; Wed, 10 Dec 2014 04:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYAa76S_D2Sw for ; Wed, 10 Dec 2014 04:54:57 -0800 (PST) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07CF1A8967 for ; Wed, 10 Dec 2014 04:54:53 -0800 (PST) Received: by mail-qg0-f52.google.com with SMTP id a108so2038532qge.11 for ; Wed, 10 Dec 2014 04:54:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=kCI2CsREUHumYO6qUS7u/Weu6viowHrX2Y0JzYc28xA=; b=FSVJ9BCbosLiceI+Nj0jYJZpgVkwuewR0kjIbTj4r2298VtUFkP3l3wcWhY+EvlAxC O5hg/0BAwDWD0Io89q7ggNX4O6DwLWQByIR1PMWHlFVD7emzI9wx9JM8E9EkXadYz5er 89IppobDYMXCDVyc4JJKd90AhJ92YobH8TWnTFiVFKQoTaenn6Ojd7UYLsm/uyUyGO1z Nys7jKTTjdo1i1qHtApUr7ejAP2MkAnqLcF9rDPaLc69mCUyfLbqeqgp1GE23xRgMjpM knW+oQCNXAPmqU9zYL4YC3sImXjqu/s5mW1Rb3PVusRPEqpKx6IzzZPtYLtiqyWWl01J dNFA== X-Gm-Message-State: ALoCoQnPtp36w19TP3DeO93TOf3oRfjgCfL5YW8sEx45JK9o6sWlcK3Jf1QhcS+OtunRzQCf2BYx X-Received: by 10.224.22.196 with SMTP id o4mr7868510qab.85.1418216089314; Wed, 10 Dec 2014 04:54:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Wed, 10 Dec 2014 04:54:29 -0800 (PST) In-Reply-To: References: <5486C48D.8040602@alvestrand.no> <54873575.3030804@nostrum.com> <53ECE529-C011-4666-B044-226613CA263D@apple.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 10 Dec 2014 13:54:29 +0100 Message-ID: To: "Cavigioli, Chris" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GOwltLauQLfqiwg8ai1KFK2Rd5A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 12:54:59 -0000 2014-12-09 20:11 GMT+01:00 Cavigioli, Chris : > Paying for codecs pays for research labs to continue their research to > invent new things Please, don't go there. The business model of research labs is not the subject here, and I assume you agree that the W3C's goal is not to satisfy any business model. Said that, there are some "minor" examples in the world that may contradict what you said, such as the Linux and open source whole ecosystem. Anyhow, that is not the subject. --=20 I=C3=B1aki Baz Castillo From nobody Wed Dec 10 06:47:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDDB1A1EF9 for ; Wed, 10 Dec 2014 06:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXuTDle3mOQT for ; Wed, 10 Dec 2014 06:47:38 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id B2EBB1A1B59 for ; Wed, 10 Dec 2014 06:47:37 -0800 (PST) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 10 Dec 2014 09:47:28 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0210.002; Wed, 10 Dec 2014 09:47:28 -0500 From: Gaelle Martin-Cocher To: Eric Rescorla , Bernard Aboba Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEJCKBITgiQUj50CzzuygMU2TV5yIDJ6AgAAEMgCAABkhAIAAMv0AgACrjwD//9xv0A== Date: Wed, 10 Dec 2014 14:47:27 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF35E2BB@XMB111CNC.rim.net> References: In-Reply-To: Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/alternative; boundary="_000_92D0D52F3A63344CA478CF12DB0648AADF35E2BBXMB111CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jMmUZ4cxdRsIBJjF5xQfcsArxJM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 14:47:41 -0000 --_000_92D0D52F3A63344CA478CF12DB0648AADF35E2BBXMB111CNCrimnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENClRoZSB2YWd1ZW5lc3Mgb2YgdGhlIFdlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50IGRlZmlu aXRpb24gYW5kIHRoZSBmZWF0dXJlIHNldCBpdCBjb3ZlcnMgaXMgd29ycmlzb21lLg0KSXQgaXMg aW50cm9kdWNpbmcgc3ViLXN0YW5kYXJkcyB3aXRoaW4gYSBzcGVjaWZpY2F0aW9uLg0KVGhlIHZh cmlvdXMgZGlzY3Vzc2lvbnMgc2hvdyB0aGF0IHdlIGhhdmUgYmVlbiBlc3NlbnRpYWxseSBsb29r aW5nIGF0IGl0IGVpdGhlciBhcyBjb250YWluaW5nICBhbGwgZmVhdHVyZXMgYnV0IG9uZSBjb2Rl Yywgb3IgdGhlIGZlYXR1cmUgc2V0IG5lZWRlZCBmb3IgYSBnYXRld2F5LiBUaGF0IGNhdGVnb3J5 IGNvdWxkIGNvdmVycyBzb21ldGhpbmcgdGhhdCBkb2VzIG9ubHkgZG9lcyAxNSUgb2YgV2ViUlRD LiBJdCBtaWdodCDigJxzdWNjZXNzZnVsbHkgY29tbXVuaWNhdGUgd2l0aCBhIFdlYlJUQyBlbmRw b2ludOKAnSBidXQgd2hhdCBkb2VzIGl0IG1lYW5zPw0KSG93IHBhaW5mdWwgd2lsbCB0aGF0IGJl IHRvIGRlYWwgd2l0aCBzdWNoIGVuZHBvaW50LCBhc3N1bWluZyBpdCBzb21ld2hhdCBjb25uZWN0 cyB0byB5b3VyIG93biBwcm9kdWN0Pw0KDQpJdCBtaWdodCBiZSBtb3JlIGFwcHJvcHJpYXRlIHRv IHJlbGF4IHJlcXVpcmVtZW50cyBmb3IgYm90aCB0aGUgV2ViUlRDIGdhdGV3YXkgYW5kIGEgbmV3 IGVudGl0eSB0aGFuIGhhdmluZyBzdWNoIGEgdmFndWUgY2F0ZWdvcnkuDQpHYcOrbGxlDQoNCkZy b206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg RXJpYyBSZXNjb3JsYQ0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxMCwgMjAxNCA2OjE4IEFN DQpUbzogQmVybmFyZCBBYm9iYQ0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFty dGN3ZWJdIGNvbmZpcm1pbmcgc2Vuc2Ugb2YgdGhlIHJvb206IG10aSBjb2RlYw0KDQpPbiBXZWQs IERlYyAxMCwgMjAxNCBhdCAyOjAzIEFNLCBCZXJuYXJkIEFib2JhIDxiZXJuYXJkLmFib2JhQGdt YWlsLmNvbTxtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20+PiB3cm90ZToNCk15IGJhZC4N Cg0KTmV3IHF1ZXN0aW9uOiAgSG93IGNhbiBhbiBlbmRwb2ludCB0aGF0IGltcGxlbWVudHMgdmlk ZW8gYnV0IG5vbmUgb2YgdGhlIE1USSBjb2RlY3MgYmUgY29uc3RydWVkIGFzICJXZWJSVEMgQ29t cGF0aWJsZSI/DQoNCldlbGwsIHRoaXMgc2VlbXMgbGlrZSBhIGdlbmVyaWMgY29tcGxhaW50IGFi b3V0IHRoZSB0ZXJtICJjb21wYXRpYmxlIiwgc2luY2Ugc3VjaA0KZW5kcG9pbnRzIGFyZSBleHBs aWNpdGx5IG5vdCByZXF1aXJlZCB0byBtZWV0IGFueSByZXF1aXJlbWVudHM6DQoNCg0KICAgICBB IFdlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50IGlzIGFuIGVuZHBvaW50IHRoYXQgaXMgYWJsZSB0 bw0KDQogICAgICBzdWNjZXNzZnVsbHkgY29tbXVuaWNhdGUgd2l0aCBhIFdlYlJUQyBlbmRwb2lu dCwgYnV0IG1heSBmYWlsIHRvDQoNCiAgICAgIG1lZXQgc29tZSByZXF1aXJlbWVudHMgb2YgYSBX ZWJSVEMgZW5kcG9pbnQuICBUaGlzIG1heSBsaW1pdCB3aGVyZQ0KDQogICAgICBpbiB0aGUgbmV0 d29yayBzdWNoIGFuIGVuZHBvaW50IGNhbiBiZSBhdHRhY2hlZCwgb3IgbWF5IGxpbWl0IHRoZQ0K DQogICAgICBzZWN1cml0eSBndWFyYW50ZWVzIHRoYXQgaXQgb2ZmZXJzIHRvIG90aGVycy4gIEl0 IGlzIG5vdA0KDQogICAgICBjb25zdHJhaW5lZCBieSB0aGlzIHNwZWNpZmljYXRpb247IHdoZW4g aXQgaXMgbWVudGlvbmVkIGF0IGFsbCwgaXQNCg0KICAgICAgaXMgdG8gbm90ZSB0aGUgaW1wbGlj YXRpb25zIG9uIFdlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50cyBvZiB0aGUNCg0KICAgICAgcmVx dWlyZW1lbnRzIHBsYWNlZCBvbiBXZWJSVEMgZW5kcG9pbnRzLg0KDQoNCg0KU28sIHBlcmhhcHMg d2UgbmVlZCBhIG5ldyB0ZXJtLCBidXQgdGhpcyBkb2Vzbid0IHNlZW0gbGlrZSBhbiBpc3N1ZSBs aW1pdGVkIHRvDQoNCnZpZGVvIGNvZGVjcw0KDQoNCg0KLUVrcg0KDQoNCk9uIFR1ZSwgRGVjIDks IDIwMTQgYXQgMjowMSBQTSwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JA cnRmbS5jb20+PiB3cm90ZToNCg0KT24gVHVlLCBEZWMgOSwgMjAxNCBhdCA5OjMxIFBNLCBCZXJu YXJkIEFib2JhIDxiZXJuYXJkLmFib2JhQGdtYWlsLmNvbTxtYWlsdG86YmVybmFyZC5hYm9iYUBn bWFpbC5jb20+PiB3cm90ZToNCkFsbG93aW5nIGFuIGVuZHBvaW50IHRoYXQgaW1wbGVtZW50cyB2 aWRlbyB0byBjYWxsIGl0c2VsZiAiV2ViUlRDIGNvbXBsaWFudCIgd2l0aG91dCBpbXBsZW1lbnRp bmcgZWl0aGVyIG9mIHRoZSBNVEkgY29kZWNzIGlzIHNvIHdyb25nLWhlYWRlZCB0aGF0IEkgYW0g YXQgYSBsb3NzIGZvciB3b3Jkcy4NCg0KSSBiZWxpZXZlIHlvdSBoYXZlIG1pc3JlYWQgdGhlIHBy b3Bvc2FsLiBUaGUgdGVybSAiV2ViUlRDIGNvbXBsaWFudCIgbmV2ZXIgYXBwZWFycw0KYW55d2hl cmUgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXZpZGVv LTAzLiBJbmRlZWQsIHRoZSB3b3JkDQoiY29tcGxpYW50IiBkb2VzIG5vdCBhcHBlYXIuDQoNClJh dGhlciwgZW5kcG9pbnRzIHdoaWNoIGltcGxlbWVudCBuZWl0aGVyIGNvZGVjIHF1YWxpZnkgYXMg IldlYlJUQyBDb21wYXRpYmxlIi4NCg0KLUVrcg0KDQoNCk9uIFR1ZSwgRGVjIDksIDIwMTQgYXQg MTI6MTYgUE0sIEVyaWsgTGFnZXJ3YXkgPGVyaWtAaG9va2ZsYXNoLmNvbTxtYWlsdG86ZXJpa0Bo b29rZmxhc2guY29tPj4gd3JvdGU6DQpUaGFua3MgU2VhbiwNCg0KV2UgY2FuIG5vdCBzdXBwb3J0 IHRoaXMgZHJhZnQgYXQgdGhpcyB0aW1lLg0KDQpBcyBSVEMgU0RLIHZlbmRvcnMgd2UgdmVyeSBs aWtlbHkgd2lsbCBzdXBwb3J0IGJvdGggY29kZWNzLCBidXQgd2UgY2FuIG5vdCBzdGFuZCBieSBh IGRlY2lzaW9uIHRoYXQgd2lsbCAiaW1wb3NlIiBkdWFsIE1USSBvbiBvdXIgZGV2ZWxvcGVyIGNv bW11bml0eS4NCg0KQWNjb3JkaW5nIHRvIHRoaXMsIGV2ZXJ5IGRldiBtdXN0IHVzZSBib3RoIGNv ZGVjcyBmb3IgZXZlcnkgYXBwIHRoYXQgaXMgYnVpbHQgdXNpbmcgb3VyIHRvb2xzLiBDb2RlYyBz ZWxlY3Rpb24gc2hvdWxkIGJlIHRoZWlyIGNob2ljZSBhbmQgbm90IGJlIGZvcmNlZCB1cG9uIHRo ZW0uIFRoaXMgc2VlbXMgdG8gYmUgYSByYXRoZXIgdW5yZWFzb25hYmxlIGV4cGVjdGF0aW9uLg0K DQoNCkVyaWsgTGFnZXJ3YXk8aHR0cDovL2NhLmxpbmtlZGluLmNvbS9pbi9sYWdlcndheT4gfCBI b29rZmxhc2g8aHR0cDovL2hvb2tmbGFzaC5jb20vPiB8IDEgKDg1NSkgSG9va2ZsYXNoIGV4dC4g MiB8IFR3aXR0ZXI8aHR0cDovL3R3aXR0ZXIuY29tL2VsYWdlcndheT4gfCBXZWJSVEMuaXMgQmxv ZzxodHRwOi8vd2VicnRjLmlzLz4NCg0KT24gRnJpLCBEZWMgNSwgMjAxNCBhdCA1OjM2IEFNLCBT ZWFuIFR1cm5lciA8dHVybmVyc0BpZWNhLmNvbTxtYWlsdG86dHVybmVyc0BpZWNhLmNvbT4+IHdy b3RlOg0KQWxsLA0KDQpBdCB0aGUgMm5kIFJUQ3dlYiBXRyBzZXNzaW9uIEAgSUVURiA5MSwgd2Ug aGFkIGEgbGl2ZWx5IGRpc2N1c3Npb24gYWJvdXQgY29kZWNzLCB3aGljaCBJIGR1YmJlZCAidGhl IGdyZWF0IGNvZGVjIGNvbXByb21pc2UuIiAgVGhlIGNvbXByb21pc2UgdGV4dCB0aGF0IHdhcyBk aXNjdXNzZWQgYXBwZWFycyBpbiBzbGlkZXMgMTItMTQgYXQgWzRdICh3aGljaCBpcyBhIHNsaWdo dCBlZGl0b3JpYWwgdmFyaWF0aW9uIG9mIHRoZSB0ZXh0IHByb3Bvc2VkIGF0IFsyXSkuDQoNClRo aXMgbWVzc2FnZSBzZXJ2ZXMgdG8gY29uZmlybSB0aGUgc2Vuc2Ugb2YgdGhlIHJvb20uDQoNCklu IHRoZSByb29tLCBJIGhlYXJkIHRoZSBmb2xsb3dpbmcgb2JqZWN0aW9ucyBhbmQgcmVzcG9uc2Vz IChhbmQgSeKAmW0gcGFyYXBocmFzaW5nIGhlcmUpLCB3aGljaCBJ4oCZbGwgdGFrZSB0aGUgbGli ZXJ0eSBvZiBjYXRlZ29yaXppbmcgYXMgSVBSLCBUaW1lLCBhbmQgVHJpZ2dlcjoNCg0KMSkgSVBS Og0KDQpPYmplY3Rpb25zOiBUaGVyZSBhcmUgc3RpbGwgSVBSIGNvbmNlcm5zIHdoaWNoIG1heSBy ZXN0cmljdCB3aGF0IGEgcGFydGljdWxhciBvcmdhbml6YXRpb24gZmVlbHMgY29tZm9ydGFibGUg d2l0aCBpbmNsdWRpbmcgaW4gdGhlaXIgYnJvd3NlciBpbXBsZW1lbnRhdGlvbnMuDQoNClJlc3Bv bnNlOiAgSVBSIGNvbmNlcm5zIG9uIHRoaXMgdG9waWMgYXJlIHdlbGwga25vd24uICBUaGVyZSBp cyBldmVuIGEgZHJhZnQgc3VtbWFyaXppbmcgdGhlIGN1cnJlbnQgSVBSIHN0YXR1cyBmb3IgVlA4 OiBkcmFmdC1iZW5oYW0tcnRjd2ViLXZwOGxpdGlnYXRpb24uICBUaGUgc2Vuc2Ugb2YgdGhlIHJv b20gd2FzIHN0aWxsIHRoYXQgYWRvcHRpbmcgdGhlIGNvbXByb21pc2UgdGV4dCB3YXMgYXBwcm9w cmlhdGUuDQoNCjIpIFRpbWU6DQoNCjIuMSkgVGltZSB0byBjb25zaWRlciBkZWNpc2lvbjoNCg0K T2JqZWN0aW9uOiBUaGUgZGVjaXNpb24gdG8gY29uc2lkZXIgdGhlIGNvbXByb21pc2UgcHJvcG9z YWwgYXQgdGhpcyBtZWV0aW5nIHdhcyBwcm92aWRlZCBvbiBzaG9ydCBub3RpY2UgYW5kIGRpZCBu b3QgcHJvdmlkZSBzb21lIHRoZSBvcHBvcnR1bml0eSB0byBhdHRlbmQgaW4gcGVyc29uLg0KDQpS ZXNwb25zZTogIFNpeCBtb250aHMgYWdvIHRoZSBjaGFpcnMgbWFkZSBpdCBjbGVhciBkaXNjdXNz aW9uIHdvdWxkIGJlIHJldmlzaXRlZCBAIElFVEYgOTEgWzBdLiBUaGUgZmlyc3QgYWdlbmRhIHBy b3Bvc2FsIGZvciB0aGUgV0cgaW5jbHVkZWQgdGhpcyB0b3BpYyBbMV0sIGFuZCB0aGUgdG9waWMg d2FzIG5ldmVyIHJlbW92ZWQgYnkgdGhlIGNoYWlycy4gICAgTW9yZSBpbXBvcnRhbnRseSwgYWxs IGRlY2lzaW9ucyBhcmUgY29uZmlybWVkIG9uIGxpc3Q7IGluIHBlcnNvbiBhdHRlbmRhbmNlIGlz IG5vdCByZXF1aXJlZCB0byBiZSBwYXJ0IG9mIHRoZSBwcm9jZXNzLg0KDQoyLjIpIFRpbWUgdG8g Y29uc2lkZXIgdGV4dDoNCg0KT2JqZWN0aW9uOiBUaGUgcHJvcG9zZWQgdGV4dCBbMl0gaXMgdG9v IG5ldyB0byBiZSBjb25zaWRlcmVkLg0KDQpSZXNwb25zZTogVGhlIHJlcXVpcmVtZW50IGZvciBi cm93c2VycyB0byBzdXBwb3J0IGJvdGggVlA4IGFuZCBILjI2NCB3YXMgYW1vbmcgdGhlIG9wdGlv bnMgaW4gdGhlIHN0cmF3IHBvbGwgY29uZHVjdGVkIG1vcmUgdGhhbiBzaXggbW9udGhzIGFnby4g IEFsbCBkZWNpc2lvbnMgYXJlIGNvbmZpcm1lZCBvbiBsaXN0IHNvIHRoZXJlIHdpbGwgYmUgYW1w bGUgdGltZSB0byBkaXNjdXNzIHRoZSBwcm9wb3NhbC4NCg0KMykgVHJpZ2dlcjoNCg0KT2JqZWN0 aW9uOiBUaGUg4oCcdHJpZ2dlcuKAnSBzZW50ZW5jZSBbM10gaXMgYWxsIGtpbmRzIG9mIHdyb25n IGJlY2F1c2UgaXTigJlzIHByb21pc2luZyB0aGF0IHRoZSBmdXR1cmUgSUVURiB3aWxsIHVwZGF0 ZSB0aGlzIHNwZWNpZmljYXRpb24uDQoNClJlc3BvbnNlOiBMaWtlIGFueSBJRVRGIHByb3Bvc2Fs LCBhbiBSRkMgdGhhdCBkb2N1bWVudHMgdGhlIGN1cnJlbnQgcHJvcG9zYWwgY2FuIGJlIGNoYW5n ZWQgdGhyb3VnaCB0aGUgY29uc2Vuc3VzIHByb2Nlc3MgYXQgYW55IG90aGVyIHRpbWUuDQoNCg0K QWZ0ZXIgdGhlIGRpc2N1c3Npb24sIHNvbWUgY2xhcmlmeWluZyBxdWVzdGlvbnMgYWJvdXQgdGhl IGh1bXMsIGFuZCB0eXBpbmcgdGhlIGh1bSBxdWVzdGlvbnMgb24gdGhlIHNjcmVlbiwgdGhlcmUg d2FzIHJvdWdoIGNvbnNlbnN1cyBpbiB0aGUgcm9vbSB0byBhZGQgKGFrYSDigJxzaG92ZeKAnSkg dGhlIHByb3Bvc2VkIHRleHQgaW50byBkcmFmdC1pZXRmLXJ0Y3dlYi12aWRlby4gIEluIGtlZXBp bmcgd2l0aCBJRVRGIHByb2Nlc3MsIEkgYW0gY29uZmlybWluZyB0aGlzIGNvbnNlbnN1cyBjYWxs IG9uIHRoZSBsaXN0Lg0KDQpJZiBhbnlvbmUgaGFzIGFueSBvdGhlciBpc3N1ZXMgdGhhdCB0aGV5 IHdvdWxkIGxpa2UgdG8gcmFpc2UgcGxlYXNlIGRvIGJ5IERlY2VtYmVyIDE5dGguDQoNCkNoZWVy cywNCnNwdCAoYXMgY2hhaXIpDQoNClswXSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvcnRjd2ViL2N1cnJlbnQvbXNnMTExOTQuaHRtbA0KWzFdIGh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9ydGN3ZWIvY3VycmVudC9tc2cxMzE1MC5odG1sDQpbMl0gaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50L21zZzEzNDMy Lmh0bWwNClszXSBUaGUgb25lIHRoYXQgYmVnaW5zIHdpdGggIklmIGNvbXBlbGxpbmcgZXZpZGVu Y2UgLi4uIg0KWzRdIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTEvc2xpZGVzL3Ns aWRlcy05MS1ydGN3ZWItNy5wZGYNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRjd2ViDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2Vi IG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQoNCg0K --_000_92D0D52F3A63344CA478CF12DB0648AADF35E2BBXMB111CNCrimnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjo3MC44NXB0IDcwLjg1 cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mIzQzOzE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHZhZ3VlbmVzcyBvZiB0aGUgV2ViUlRDLWNvbXBh dGlibGUgZW5kcG9pbnQgZGVmaW5pdGlvbiBhbmQgdGhlIGZlYXR1cmUgc2V0IGl0IGNvdmVycyBp cyB3b3JyaXNvbWUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgaXMgaW50cm9k dWNpbmcgc3ViLXN0YW5kYXJkcyB3aXRoaW4gYSBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5UaGUgdmFyaW91cyBkaXNjdXNzaW9ucyBzaG93IHRoYXQgd2UgaGF2 ZSBiZWVuIGVzc2VudGlhbGx5IGxvb2tpbmcgYXQgaXQgZWl0aGVyIGFzIGNvbnRhaW5pbmcmbmJz cDsgYWxsIGZlYXR1cmVzIGJ1dCBvbmUgY29kZWMsIG9yIHRoZSBmZWF0dXJlIHNldCBuZWVkZWQg Zm9yIGEgZ2F0ZXdheS4NCiBUaGF0IGNhdGVnb3J5IGNvdWxkIGNvdmVycyBzb21ldGhpbmcgdGhh dCBkb2VzIG9ubHkgZG9lcyAxNSUgb2YgV2ViUlRDLiBJdCBtaWdodCDigJxzdWNjZXNzZnVsbHkg Y29tbXVuaWNhdGUgd2l0aCBhIFdlYlJUQyBlbmRwb2ludOKAnSBidXQgd2hhdCBkb2VzIGl0IG1l YW5zPyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93IHBhaW5mdWwgd2ls bCB0aGF0IGJlIHRvIGRlYWwgd2l0aCBzdWNoIGVuZHBvaW50LCBhc3N1bWluZyBpdCBzb21ld2hh dCBjb25uZWN0cyB0byB5b3VyIG93biBwcm9kdWN0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgbWlnaHQgYmUgbW9y ZSBhcHByb3ByaWF0ZSB0byByZWxheCByZXF1aXJlbWVudHMgZm9yIGJvdGggdGhlIFdlYlJUQyBn YXRld2F5IGFuZCBhIG5ldyBlbnRpdHkgdGhhbiBoYXZpbmcgc3VjaCBhIHZhZ3VlIGNhdGVnb3J5 Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkdhw6tsbGU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2Vu dDo8L2I+IFdlZG5lc2RheSwgRGVjZW1iZXIgMTAsIDIwMTQgNjoxOCBBTTxicj4NCjxiPlRvOjwv Yj4gQmVybmFyZCBBYm9iYTxicj4NCjxiPkNjOjwvYj4gcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBjb25maXJtaW5nIHNlbnNlIG9mIHRoZSByb29tOiBt dGkgY29kZWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFdlZCwgRGVjIDEwLCAyMDE0IGF0IDI6MDMgQU0sIEJlcm5hcmQgQWJvYmEgJmx0Ozxh IGhyZWY9Im1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJl cm5hcmQuYWJvYmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IGJhZC4mbmJzcDsgPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5ldyBxdWVzdGlvbjom bmJzcDsgSG93IGNhbiBhbiBlbmRwb2ludCB0aGF0IGltcGxlbWVudHMgdmlkZW8gYnV0Jm5ic3A7 bm9uZSBvZiB0aGUgTVRJIGNvZGVjcyBiZSBjb25zdHJ1ZWQgYXMgJnF1b3Q7V2ViUlRDIENvbXBh dGlibGUmcXVvdDs/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2VsbCwgdGhpcyBzZWVtcyBsaWtlIGEgZ2VuZXJpYyBj b21wbGFpbnQgYWJvdXQgdGhlIHRlcm0gJnF1b3Q7Y29tcGF0aWJsZSZxdW90Oywgc2luY2Ugc3Vj aDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZW5k cG9pbnRzIGFyZSBleHBsaWNpdGx5IG5vdCByZXF1aXJlZCB0byBtZWV0IGFueSByZXF1aXJlbWVu dHM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QSBXZWJSVEMtY29tcGF0 aWJsZSBlbmRwb2ludCBpcyBhbiBlbmRwb2ludCB0aGF0IGlzIGFibGUgdG88bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1Y2Nlc3NmdWxseSBjb21tdW5pY2F0ZSB3 aXRoIGEgV2ViUlRDIGVuZHBvaW50LCBidXQgbWF5IGZhaWwgdG88bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1lZXQgc29tZSByZXF1aXJlbWVudHMgb2YgYSBXZWJS VEMgZW5kcG9pbnQuJm5ic3A7IFRoaXMgbWF5IGxpbWl0IHdoZXJlPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbiB0aGUgbmV0d29yayBzdWNoIGFuIGVuZHBvaW50 IGNhbiBiZSBhdHRhY2hlZCwgb3IgbWF5IGxpbWl0IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VjdXJpdHkgZ3VhcmFudGVlcyB0aGF0IGl0IG9mZmVycyB0 byBvdGhlcnMuJm5ic3A7IEl0IGlzIG5vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgY29uc3RyYWluZWQgYnkgdGhpcyBzcGVjaWZpY2F0aW9uOyB3aGVuIGl0IGlz IG1lbnRpb25lZCBhdCBhbGwsIGl0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBpcyB0byBub3RlIHRoZSBpbXBsaWNhdGlvbnMgb24gV2ViUlRDLWNvbXBhdGlibGUg ZW5kcG9pbnRzIG9mIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgcmVxdWlyZW1lbnRzIHBsYWNlZCBvbiBXZWJSVEMgZW5kcG9pbnRzLjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+U28sIHBlcmhhcHMgd2UgbmVlZCBhIG5ldyB0ZXJtLCBidXQgdGhpcyBk b2Vzbid0IHNlZW0gbGlrZSBhbiBpc3N1ZSBsaW1pdGVkIHRvPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+dmlkZW8gY29kZWNzPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tRWtyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRGVjIDksIDIwMTQgYXQgMjowMSBQ TSwgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIERlYyA5LCAyMDE0IGF0IDk6MzEgUE0s IEJlcm5hcmQgQWJvYmEgJmx0OzxhIGhyZWY9Im1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbG93 aW5nIGFuIGVuZHBvaW50IHRoYXQgaW1wbGVtZW50cyB2aWRlbyB0byBjYWxsIGl0c2VsZiAmcXVv dDtXZWJSVEMgY29tcGxpYW50JnF1b3Q7IHdpdGhvdXQgaW1wbGVtZW50aW5nIGVpdGhlciBvZiB0 aGUgTVRJIGNvZGVjcyBpcyBzbyB3cm9uZy1oZWFkZWQgdGhhdCBJIGFtIGF0IGEgbG9zcyBmb3Ig d29yZHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBiZWxpZXZlIHlvdSBoYXZlIG1pc3JlYWQgdGhlIHByb3Bvc2FsLiBUaGUg dGVybSAmcXVvdDtXZWJSVEMgY29tcGxpYW50JnF1b3Q7IG5ldmVyIGFwcGVhcnM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFueXdoZXJlIGluJm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2Vi LXZpZGVvLTAzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtcnRjd2ViLXZpZGVvLTAzPC9hPi4gSW5kZWVkLCB0aGUgd29yZDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7Y29tcGxpYW50 JnF1b3Q7IGRvZXMgbm90IGFwcGVhci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+UmF0aGVyLCBlbmRwb2ludHMgd2hpY2ggaW1wbGVtZW50IG5l aXRoZXIgY29kZWMgcXVhbGlmeSBhcyAmcXVvdDtXZWJSVEMgQ29tcGF0aWJsZSZxdW90Oy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRGVjIDksIDIwMTQgYXQgMTI6 MTYgUE0sIEVyaWsgTGFnZXJ3YXkgJmx0OzxhIGhyZWY9Im1haWx0bzplcmlrQGhvb2tmbGFzaC5j b20iIHRhcmdldD0iX2JsYW5rIj5lcmlrQGhvb2tmbGFzaC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIFNl YW4sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgY2Fu IG5vdCBzdXBwb3J0IHRoaXMgZHJhZnQgYXQgdGhpcyB0aW1lLjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgUlRDIFNESyB2ZW5kb3JzIHdlIHZlcnkgbGlr ZWx5IHdpbGwgc3VwcG9ydCBib3RoIGNvZGVjcywgYnV0IHdlIGNhbiBub3Qgc3RhbmQgYnkgYSBk ZWNpc2lvbiB0aGF0IHdpbGwgJnF1b3Q7aW1wb3NlJnF1b3Q7IGR1YWwgTVRJIG9uIG91ciBkZXZl bG9wZXIgY29tbXVuaXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BY2NvcmRpbmcgdG8gdGhpcywgZXZlcnkgZGV2IG11c3QgdXNlIGJvdGgg Y29kZWNzIGZvciBldmVyeSBhcHAgdGhhdCBpcyBidWlsdCB1c2luZyBvdXIgdG9vbHMuIENvZGVj IHNlbGVjdGlvbiBzaG91bGQgYmUgdGhlaXIgY2hvaWNlIGFuZCBub3QgYmUgZm9yY2VkIHVwb24g dGhlbS4gVGhpcyBzZWVtcyB0byBiZSBhIHJhdGhlciB1bnJlYXNvbmFibGUgZXhwZWN0YXRpb24u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6Izg4ODg4OCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtjb2xvcjpncmF5Ij48YSBocmVmPSJodHRwOi8vY2EubGlua2VkaW4uY29tL2lu L2xhZ2Vyd2F5IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiNDQzAwMDAiPkVy aWsgTGFnZXJ3YXk8L3NwYW4+PC9hPiZuYnNwO3wmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiM4ODg4ODgiPjxhIGhyZWY9Imh0dHA6Ly9ob29rZmxhc2guY29tLyIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Y29sb3I6IzMzMzMzMyI+SG9va2ZsYXNo PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtjb2xvcjpncmF5 Ij4mbmJzcDt8DQogMSAoODU1KTwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2NvbG9yOiM5NDM2MzQiPiZuYnNwOzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtjb2xvcjpncmF5Ij5Ib29rZmxhc2ggZXh0LiAyIHwmbmJzcDs8YSBocmVmPSJodHRwOi8v dHdpdHRlci5jb20vZWxhZ2Vyd2F5IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxMTU1Q0MiPlR3aXR0ZXI8L3NwYW4+PC9hPiZuYnNwO3wmbmJzcDs8YSBocmVmPSJodHRwOi8v d2VicnRjLmlzLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMTE1NUNDIj5X ZWJSVEMuaXMNCiBCbG9nPC9zcGFuPjwvYT4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OiM4ODg4ODgiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgRGVjIDUsIDIwMTQgYXQgNTozNiBBTSwgU2VhbiBUdXJu ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0dXJuZXJzQGllY2EuY29tIiB0YXJnZXQ9Il9ibGFuayI+ dHVybmVyc0BpZWNhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxsLDxicj4NCjxicj4NCkF0 IHRoZSAybmQgUlRDd2ViIFdHIHNlc3Npb24gQCBJRVRGIDkxLCB3ZSBoYWQgYSBsaXZlbHkgZGlz Y3Vzc2lvbiBhYm91dCBjb2RlY3MsIHdoaWNoIEkgZHViYmVkICZxdW90O3RoZSBncmVhdCBjb2Rl YyBjb21wcm9taXNlLiZxdW90OyZuYnNwOyBUaGUgY29tcHJvbWlzZSB0ZXh0IHRoYXQgd2FzIGRp c2N1c3NlZCBhcHBlYXJzIGluIHNsaWRlcyAxMi0xNCBhdCBbNF0gKHdoaWNoIGlzIGEgc2xpZ2h0 IGVkaXRvcmlhbCB2YXJpYXRpb24gb2YgdGhlIHRleHQgcHJvcG9zZWQNCiBhdCBbMl0pLjxicj4N Cjxicj4NClRoaXMgbWVzc2FnZSBzZXJ2ZXMgdG8gY29uZmlybSB0aGUgc2Vuc2Ugb2YgdGhlIHJv b20uPGJyPg0KPGJyPg0KSW4gdGhlIHJvb20sIEkgaGVhcmQgdGhlIGZvbGxvd2luZyBvYmplY3Rp b25zIGFuZCByZXNwb25zZXMgKGFuZCBJ4oCZbSBwYXJhcGhyYXNpbmcgaGVyZSksIHdoaWNoIEni gJlsbCB0YWtlIHRoZSBsaWJlcnR5IG9mIGNhdGVnb3JpemluZyBhcyBJUFIsIFRpbWUsIGFuZCBU cmlnZ2VyOjxicj4NCjxicj4NCjEpIElQUjo8YnI+DQo8YnI+DQpPYmplY3Rpb25zOiBUaGVyZSBh cmUgc3RpbGwgSVBSIGNvbmNlcm5zIHdoaWNoIG1heSByZXN0cmljdCB3aGF0IGEgcGFydGljdWxh ciBvcmdhbml6YXRpb24gZmVlbHMgY29tZm9ydGFibGUgd2l0aCBpbmNsdWRpbmcgaW4gdGhlaXIg YnJvd3NlciBpbXBsZW1lbnRhdGlvbnMuPGJyPg0KPGJyPg0KUmVzcG9uc2U6Jm5ic3A7IElQUiBj b25jZXJucyBvbiB0aGlzIHRvcGljIGFyZSB3ZWxsIGtub3duLiZuYnNwOyBUaGVyZSBpcyBldmVu IGEgZHJhZnQgc3VtbWFyaXppbmcgdGhlIGN1cnJlbnQgSVBSIHN0YXR1cyBmb3IgVlA4OiBkcmFm dC1iZW5oYW0tcnRjd2ViLXZwOGxpdGlnYXRpb24uJm5ic3A7IFRoZSBzZW5zZSBvZiB0aGUgcm9v bSB3YXMgc3RpbGwgdGhhdCBhZG9wdGluZyB0aGUgY29tcHJvbWlzZSB0ZXh0IHdhcyBhcHByb3By aWF0ZS48YnI+DQo8YnI+DQoyKSBUaW1lOjxicj4NCjxicj4NCjIuMSkgVGltZSB0byBjb25zaWRl ciBkZWNpc2lvbjo8YnI+DQo8YnI+DQpPYmplY3Rpb246IFRoZSBkZWNpc2lvbiB0byBjb25zaWRl ciB0aGUgY29tcHJvbWlzZSBwcm9wb3NhbCBhdCB0aGlzIG1lZXRpbmcgd2FzIHByb3ZpZGVkIG9u IHNob3J0IG5vdGljZSBhbmQgZGlkIG5vdCBwcm92aWRlIHNvbWUgdGhlIG9wcG9ydHVuaXR5IHRv IGF0dGVuZCBpbiBwZXJzb24uPGJyPg0KPGJyPg0KUmVzcG9uc2U6Jm5ic3A7IFNpeCBtb250aHMg YWdvIHRoZSBjaGFpcnMgbWFkZSBpdCBjbGVhciBkaXNjdXNzaW9uIHdvdWxkIGJlIHJldmlzaXRl ZCBAIElFVEYgOTEgWzBdLiBUaGUgZmlyc3QgYWdlbmRhIHByb3Bvc2FsIGZvciB0aGUgV0cgaW5j bHVkZWQgdGhpcyB0b3BpYyBbMV0sIGFuZCB0aGUgdG9waWMgd2FzIG5ldmVyIHJlbW92ZWQgYnkg dGhlIGNoYWlycy4mbmJzcDsgJm5ic3A7IE1vcmUgaW1wb3J0YW50bHksIGFsbCBkZWNpc2lvbnMg YXJlIGNvbmZpcm1lZCBvbg0KIGxpc3Q7IGluIHBlcnNvbiBhdHRlbmRhbmNlIGlzIG5vdCByZXF1 aXJlZCB0byBiZSBwYXJ0IG9mIHRoZSBwcm9jZXNzLjxicj4NCjxicj4NCjIuMikgVGltZSB0byBj b25zaWRlciB0ZXh0Ojxicj4NCjxicj4NCk9iamVjdGlvbjogVGhlIHByb3Bvc2VkIHRleHQgWzJd IGlzIHRvbyBuZXcgdG8gYmUgY29uc2lkZXJlZC48YnI+DQo8YnI+DQpSZXNwb25zZTogVGhlIHJl cXVpcmVtZW50IGZvciBicm93c2VycyB0byBzdXBwb3J0IGJvdGggVlA4IGFuZCBILjI2NCB3YXMg YW1vbmcgdGhlIG9wdGlvbnMgaW4gdGhlIHN0cmF3IHBvbGwgY29uZHVjdGVkIG1vcmUgdGhhbiBz aXggbW9udGhzIGFnby4mbmJzcDsgQWxsIGRlY2lzaW9ucyBhcmUgY29uZmlybWVkIG9uIGxpc3Qg c28gdGhlcmUgd2lsbCBiZSBhbXBsZSB0aW1lIHRvIGRpc2N1c3MgdGhlIHByb3Bvc2FsLjxicj4N Cjxicj4NCjMpIFRyaWdnZXI6PGJyPg0KPGJyPg0KT2JqZWN0aW9uOiBUaGUg4oCcdHJpZ2dlcuKA nSBzZW50ZW5jZSBbM10gaXMgYWxsIGtpbmRzIG9mIHdyb25nIGJlY2F1c2UgaXTigJlzIHByb21p c2luZyB0aGF0IHRoZSBmdXR1cmUgSUVURiB3aWxsIHVwZGF0ZSB0aGlzIHNwZWNpZmljYXRpb24u PGJyPg0KPGJyPg0KUmVzcG9uc2U6IExpa2UgYW55IElFVEYgcHJvcG9zYWwsIGFuIFJGQyB0aGF0 IGRvY3VtZW50cyB0aGUgY3VycmVudCBwcm9wb3NhbCBjYW4gYmUgY2hhbmdlZCB0aHJvdWdoIHRo ZSBjb25zZW5zdXMgcHJvY2VzcyBhdCBhbnkgb3RoZXIgdGltZS48YnI+DQo8YnI+DQo8YnI+DQpB ZnRlciB0aGUgZGlzY3Vzc2lvbiwgc29tZSBjbGFyaWZ5aW5nIHF1ZXN0aW9ucyBhYm91dCB0aGUg aHVtcywgYW5kIHR5cGluZyB0aGUgaHVtIHF1ZXN0aW9ucyBvbiB0aGUgc2NyZWVuLCB0aGVyZSB3 YXMgcm91Z2ggY29uc2Vuc3VzIGluIHRoZSByb29tIHRvIGFkZCAoYWthIOKAnHNob3Zl4oCdKSB0 aGUgcHJvcG9zZWQgdGV4dCBpbnRvIGRyYWZ0LWlldGYtcnRjd2ViLXZpZGVvLiZuYnNwOyBJbiBr ZWVwaW5nIHdpdGggSUVURiBwcm9jZXNzLCBJIGFtIGNvbmZpcm1pbmcNCiB0aGlzIGNvbnNlbnN1 cyBjYWxsIG9uIHRoZSBsaXN0Ljxicj4NCjxicj4NCklmIGFueW9uZSBoYXMgYW55IG90aGVyIGlz c3VlcyB0aGF0IHRoZXkgd291bGQgbGlrZSB0byByYWlzZSBwbGVhc2UgZG8gYnkgRGVjZW1iZXIg MTl0aC48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0Kc3B0IChhcyBjaGFpcik8YnI+DQo8YnI+DQpb MF0gPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Y3dlYi9j dXJyZW50L21zZzExMTk0Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9ydGN3ZWIvY3VycmVudC9tc2cxMTE5NC5odG1sPC9hPjxicj4N ClsxXSA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcnRjd2Vi L2N1cnJlbnQvbXNnMTMxNTAuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50L21zZzEzMTUwLmh0bWw8L2E+PGJy Pg0KWzJdIDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9ydGN3 ZWIvY3VycmVudC9tc2cxMzQzMi5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1cnJlbnQvbXNnMTM0MzIuaHRtbDwvYT48 YnI+DQpbM10gVGhlIG9uZSB0aGF0IGJlZ2lucyB3aXRoICZxdW90O0lmIGNvbXBlbGxpbmcgZXZp ZGVuY2UgLi4uJnF1b3Q7PGJyPg0KWzRdIDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJv Y2VlZGluZ3MvOTEvc2xpZGVzL3NsaWRlcy05MS1ydGN3ZWItNy5wZGYiIHRhcmdldD0iX2JsYW5r Ij4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTEvc2xpZGVzL3NsaWRlcy05MS1y dGN3ZWItNy5wZGY8L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRj d2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3 ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRj d2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_92D0D52F3A63344CA478CF12DB0648AADF35E2BBXMB111CNCrimnet_-- From nobody Wed Dec 10 06:58:59 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D511A7004 for ; Wed, 10 Dec 2014 06:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JxTzzimLKYH for ; Wed, 10 Dec 2014 06:58:50 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6F71A1BC9 for ; Wed, 10 Dec 2014 06:58:50 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y19so3847174wgg.14 for ; Wed, 10 Dec 2014 06:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=RORTTfk4syQYds8Pb4QAGGHkqt3n3KYO6YUc5OaKTjw=; b=XVQsxF9yjebLld2PQQ8/Q5Ts+MRG2Zudgs7vNIvUcfN3U8CKJK2SoSW+8cRoS1VDI+ SlxVaoPXgzLyW/HijzP6qmCMTwK6YmVV+ZCUBOVLxXHSByjyOSCskBAreL3HbMUpm4XC lKVUkz5JYPp9oVH7kGPmINMpzpgkD5jbxZUDg2gceldXrRLY1pv63ieLCsYGOKPJgfYo n8+kSGzNlaCM+Dqs8NodXIaBfl7x0bSvwvivi9g9rObO7wjnBEqX84rgRLNTk9Vn0wfY gGOR9eOERocsgnEu4aXSwYzvwgveGCwMIUCNUwBSWJ216XVoNkyv4nLarx3NYsjY2pEh SkVQ== X-Received: by 10.180.78.9 with SMTP id x9mr14014189wiw.39.1418223528858; Wed, 10 Dec 2014 06:58:48 -0800 (PST) Received: from [192.168.1.37] (136.Red-81-39-109.dynamicIP.rima-tde.net. [81.39.109.136]) by mx.google.com with ESMTPSA id l10sm18230472wif.20.2014.12.10.06.58.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 06:58:47 -0800 (PST) Message-ID: <54885FA3.3060602@gmail.com> Date: Wed, 10 Dec 2014 15:58:43 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <92D0D52F3A63344CA478CF12DB0648AADF35E2BB@XMB111CNC.rim.net> In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF35E2BB@XMB111CNC.rim.net> Content-Type: multipart/alternative; boundary="------------090606080203040208090502" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fURDkT86OUEUfrVwDzBK1OFayrg Subject: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of the room: mti codec) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 14:58:57 -0000 This is a multi-part message in MIME format. --------------090606080203040208090502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Gaelle It is vague on purpose. What WebRTC does in regards of "WebRTC compatible endpoints" is just describing a reality, there will be some entities that do not comply with the WebRTC specs, but still are able to speak with WebRTC devices/browsers/endpoints/gateways because they implement a set of specs that WebRTC is built upon. So you can either ignore them, or assume that they are in the wild outside and describe how they look like and how they could interact with WebRTC. And, by definition, you can't put any kind of requirement to entities that do comply with the spec. Best regards Sergio On 10/12/2014 15:47, Gaelle Martin-Cocher wrote: > > +1 > > The vagueness of the WebRTC-compatible endpoint definition and the > feature set it covers is worrisome. > > It is introducing sub-standards within a specification. > > The various discussions show that we have been essentially looking at > it either as containing all features but one codec, or the feature > set needed for a gateway. That category could covers something that > does only does 15% of WebRTC. It might "successfully communicate with > a WebRTC endpoint" but what does it means? > > How painful will that be to deal with such endpoint, assuming it > somewhat connects to your own product? > > It might be more appropriate to relax requirements for both the WebRTC > gateway and a new entity than having such a vague category. > > Gaëlle > > *From:*rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Eric > Rescorla > *Sent:* Wednesday, December 10, 2014 6:18 AM > *To:* Bernard Aboba > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] confirming sense of the room: mti codec > > On Wed, Dec 10, 2014 at 2:03 AM, Bernard Aboba > > wrote: > > My bad. > > New question: How can an endpoint that implements video but none of > the MTI codecs be construed as "WebRTC Compatible"? > > Well, this seems like a generic complaint about the term "compatible", > since such > > endpoints are explicitly not required to meet any requirements: > > A WebRTC-compatible endpoint is an endpoint that is able to > successfully communicate with a WebRTC endpoint, but may fail to > meet some requirements of a WebRTC endpoint. This may limit where > in the network such an endpoint can be attached, or may limit the > security guarantees that it offers to others. It is not > constrained by this specification; when it is mentioned at all, it > is to note the implications on WebRTC-compatible endpoints of the > requirements placed on WebRTC endpoints. > > So, perhaps we need a new term, but this doesn't seem like an issue limited to > video codecs > > -Ekr > > > On Tue, Dec 9, 2014 at 2:01 PM, Eric Rescorla > wrote: > > On Tue, Dec 9, 2014 at 9:31 PM, Bernard Aboba > > wrote: > > Allowing an endpoint that implements video to call itself "WebRTC > compliant" without implementing either of the MTI codecs is so > wrong-headed that I am at a loss for words. > > I believe you have misread the proposal. The term "WebRTC > compliant" never appears > > anywhere in > https://tools.ietf.org/html/draft-ietf-rtcweb-video-03. Indeed, > the word > > "compliant" does not appear. > > Rather, endpoints which implement neither codec qualify as "WebRTC > Compatible". > > -Ekr > > On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway > > wrote: > > Thanks Sean, > > We can not support this draft at this time. > > As RTC SDK vendors we very likely will support both codecs, > but we can not stand by a decision that will "impose" dual MTI > on our developer community. > > According to this, every dev must use both codecs for every > app that is built using our tools. Codec selection should be > their choice and not be forced upon them. This seems to be a > rather unreasonable expectation. > > > Erik Lagerway | Hookflash > | 1 (855)**Hookflash ext. 2 | Twitter > | WebRTC.is Blog > > > On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner > wrote: > > All, > > At the 2nd RTCweb WG session @ IETF 91, we had a lively > discussion about codecs, which I dubbed "the great codec > compromise." The compromise text that was discussed > appears in slides 12-14 at [4] (which is a slight > editorial variation of the text proposed at [2]). > > This message serves to confirm the sense of the room. > > In the room, I heard the following objections and > responses (and I'm paraphrasing here), which I'll take the > liberty of categorizing as IPR, Time, and Trigger: > > 1) IPR: > > Objections: There are still IPR concerns which may > restrict what a particular organization feels comfortable > with including in their browser implementations. > > Response: IPR concerns on this topic are well known. > There is even a draft summarizing the current IPR status > for VP8: draft-benham-rtcweb-vp8litigation. The sense of > the room was still that adopting the compromise text was > appropriate. > > 2) Time: > > 2.1) Time to consider decision: > > Objection: The decision to consider the compromise > proposal at this meeting was provided on short notice and > did not provide some the opportunity to attend in person. > > Response: Six months ago the chairs made it clear > discussion would be revisited @ IETF 91 [0]. The first > agenda proposal for the WG included this topic [1], and > the topic was never removed by the chairs. More > importantly, all decisions are confirmed on list; in > person attendance is not required to be part of the process. > > 2.2) Time to consider text: > > Objection: The proposed text [2] is too new to be considered. > > Response: The requirement for browsers to support both VP8 > and H.264 was among the options in the straw poll > conducted more than six months ago. All decisions are > confirmed on list so there will be ample time to discuss > the proposal. > > 3) Trigger: > > Objection: The "trigger" sentence [3] is all kinds of > wrong because it's promising that the future IETF will > update this specification. > > Response: Like any IETF proposal, an RFC that documents > the current proposal can be changed through the consensus > process at any other time. > > > After the discussion, some clarifying questions about the > hums, and typing the hum questions on the screen, there > was rough consensus in the room to add (aka "shove") the > proposed text into draft-ietf-rtcweb-video. In keeping > with IETF process, I am confirming this consensus call on > the list. > > If anyone has any other issues that they would like to > raise please do by December 19th. > > Cheers, > spt (as chair) > > [0] > http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html > [1] > http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html > [2] > http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html > [3] The one that begins with "If compelling evidence ..." > [4] > http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf > _______________________________________________ > --------------090606080203040208090502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Gaelle

It is vague on purpose. What WebRTC does in regards of "WebRTC compatible endpoints" is just describing a reality, there will be some entities that do not comply with the WebRTC specs, but still are able to speak with WebRTC devices/browsers/endpoints/gateways because they implement a set of specs that WebRTC is built upon.

So you can either ignore them, or assume that they are in the wild outside and describe how they look like and how they could interact with WebRTC. And, by definition, you can't put any kind of requirement to entities that do comply with the spec.

Best regards
Sergio

On 10/12/2014 15:47, Gaelle Martin-Cocher wrote:

+1

The vagueness of the WebRTC-compatible endpoint definition and the feature set it covers is worrisome.

It is introducing sub-standards within a specification.

The various discussions show that we have been essentially looking at it either as containing  all features but one codec, or the feature set needed for a gateway. That category could covers something that does only does 15% of WebRTC. It might “successfully communicate with a WebRTC endpoint” but what does it means?  

How painful will that be to deal with such endpoint, assuming it somewhat connects to your own product?

 

It might be more appropriate to relax requirements for both the WebRTC gateway and a new entity than having such a vague category.

Gaëlle

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Wednesday, December 10, 2014 6:18 AM
To: Bernard Aboba
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] confirming sense of the room: mti codec

 

On Wed, Dec 10, 2014 at 2:03 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

My bad. 

 

New question:  How can an endpoint that implements video but none of the MTI codecs be construed as "WebRTC Compatible"? 

 

Well, this seems like a generic complaint about the term "compatible", since such

endpoints are explicitly not required to meet any requirements:

 

     A WebRTC-compatible endpoint is an endpoint that is able to
      successfully communicate with a WebRTC endpoint, but may fail to
      meet some requirements of a WebRTC endpoint.  This may limit where
      in the network such an endpoint can be attached, or may limit the
      security guarantees that it offers to others.  It is not
      constrained by this specification; when it is mentioned at all, it
      is to note the implications on WebRTC-compatible endpoints of the
      requirements placed on WebRTC endpoints.
 
So, perhaps we need a new term, but this doesn't seem like an issue limited to
video codecs
 
-Ekr
 

On Tue, Dec 9, 2014 at 2:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:

 

On Tue, Dec 9, 2014 at 9:31 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

Allowing an endpoint that implements video to call itself "WebRTC compliant" without implementing either of the MTI codecs is so wrong-headed that I am at a loss for words.

 

I believe you have misread the proposal. The term "WebRTC compliant" never appears

"compliant" does not appear.

 

Rather, endpoints which implement neither codec qualify as "WebRTC Compatible".

 

-Ekr

 

 

On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway <erik@hookflash.com> wrote:

Thanks Sean,

 

We can not support this draft at this time.

 

As RTC SDK vendors we very likely will support both codecs, but we can not stand by a decision that will "impose" dual MTI on our developer community.

 

According to this, every dev must use both codecs for every app that is built using our tools. Codec selection should be their choice and not be forced upon them. This seems to be a rather unreasonable expectation.

 


Erik Lagerway | Hookflash | 1 (855) Hookflash ext. 2 | Twitter | WebRTC.is Blog 

 

On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner <turners@ieca.com> wrote:

All,

At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about codecs, which I dubbed "the great codec compromise."  The compromise text that was discussed appears in slides 12-14 at [4] (which is a slight editorial variation of the text proposed at [2]).

This message serves to confirm the sense of the room.

In the room, I heard the following objections and responses (and I’m paraphrasing here), which I’ll take the liberty of categorizing as IPR, Time, and Trigger:

1) IPR:

Objections: There are still IPR concerns which may restrict what a particular organization feels comfortable with including in their browser implementations.

Response:  IPR concerns on this topic are well known.  There is even a draft summarizing the current IPR status for VP8: draft-benham-rtcweb-vp8litigation.  The sense of the room was still that adopting the compromise text was appropriate.

2) Time:

2.1) Time to consider decision:

Objection: The decision to consider the compromise proposal at this meeting was provided on short notice and did not provide some the opportunity to attend in person.

Response:  Six months ago the chairs made it clear discussion would be revisited @ IETF 91 [0]. The first agenda proposal for the WG included this topic [1], and the topic was never removed by the chairs.    More importantly, all decisions are confirmed on list; in person attendance is not required to be part of the process.

2.2) Time to consider text:

Objection: The proposed text [2] is too new to be considered.

Response: The requirement for browsers to support both VP8 and H.264 was among the options in the straw poll conducted more than six months ago.  All decisions are confirmed on list so there will be ample time to discuss the proposal.

3) Trigger:

Objection: The “trigger” sentence [3] is all kinds of wrong because it’s promising that the future IETF will update this specification.

Response: Like any IETF proposal, an RFC that documents the current proposal can be changed through the consensus process at any other time.


After the discussion, some clarifying questions about the hums, and typing the hum questions on the screen, there was rough consensus in the room to add (aka “shove”) the proposed text into draft-ietf-rtcweb-video.  In keeping with IETF process, I am confirming this consensus call on the list.

If anyone has any other issues that they would like to raise please do by December 19th.

Cheers,
spt (as chair)

[0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html
[1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html
[2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html
[3] The one that begins with "If compelling evidence ..."
[4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf
_______________________________________________


--------------090606080203040208090502-- From nobody Wed Dec 10 07:16:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3951A19EF for ; Wed, 10 Dec 2014 07:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2kbch7rFCce for ; Wed, 10 Dec 2014 07:16:46 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id AFD601A0115 for ; Wed, 10 Dec 2014 07:16:45 -0800 (PST) Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail05.adl6.internode.on.net with ESMTP; 11 Dec 2014 01:46:44 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id CE5E6FFC74 for ; Thu, 11 Dec 2014 01:46:43 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CHAEgt2ebYR7 for ; Thu, 11 Dec 2014 01:46:42 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id A74A4FFBAD for ; Thu, 11 Dec 2014 01:46:42 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 9A00580470; Thu, 11 Dec 2014 01:46:42 +1030 (ACDT) Date: Thu, 11 Dec 2014 01:46:42 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141210151642.GL19538@hex.shelbyville.oz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mz887Gv2PAIvV9dDw295KzgnPkE Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 15:16:55 -0000 On Wed, Dec 10, 2014 at 12:17:36PM +0100, Eric Rescorla wrote: > On Wed, Dec 10, 2014 at 2:03 AM, Bernard Aboba > wrote: > > > My bad. > > > > New question: How can an endpoint that implements video but none of the > > MTI codecs be construed as "WebRTC Compatible"? > > > > Well, this seems like a generic complaint about the term "compatible", > since such > endpoints are explicitly not required to meet any requirements: > > A WebRTC-compatible endpoint is an endpoint that is able to > successfully communicate with a WebRTC endpoint, but may fail to > meet some requirements of a WebRTC endpoint. This may limit where > in the network such an endpoint can be attached, or may limit the > security guarantees that it offers to others. It is not > constrained by this specification; when it is mentioned at all, it > is to note the implications on WebRTC-compatible endpoints of the > requirements placed on WebRTC endpoints. > > > So, perhaps we need a new term, but this doesn't seem like an issue limited to > video codecs Yes, I thought the definition was already very clear; but given that even with Adam's clarification, people in this group (who you might reasonably expect to have read these documents) appear to be confused, are already transmuting the defined term WebRTC-compatible to "WebRTC Compatible" or even "WebRTC compliant", and are foreshadowing their fear that some implementers might abuse this to deliberately mislead the market (for whatever that is worth); then maybe renaming this term is useful. Maybe s/WebRTC-compatible endpoint/non-WebRTC endpoint/ ? That would be consistent with "It is not constrained by this specification", would still include my WebRTC controlled coffee maker, and might better avoid any sort of "Vista Capable" vs "Vista Ready" word games. Ron From nobody Wed Dec 10 09:20:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2207E1A3B9D for ; Wed, 10 Dec 2014 09:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPS0uCLjQbLx for ; Wed, 10 Dec 2014 09:20:02 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CAB51A1B71 for ; Wed, 10 Dec 2014 09:20:01 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-7e-548880bff0cc Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1E.06.04231.FB088845; Wed, 10 Dec 2014 18:19:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 18:19:59 +0100 From: Christer Holmberg To: Sergio Garcia Murillo , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of the room: mti codec) Thread-Index: AQHQFInZkmAzzEGKxUKMC7HDzOxP+JyJEfiY Date: Wed, 10 Dec 2014 17:19:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D58C9A8@ESESSMB209.ericsson.se> References: <92D0D52F3A63344CA478CF12DB0648AADF35E2BB@XMB111CNC.rim.net>, <54885FA3.3060602@gmail.com> In-Reply-To: <54885FA3.3060602@gmail.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D58C9A8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvje7+ho4Qg/v/TCzW/mtnt3j6bzuz A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWx6ehf9oKuc4wVG37+ZG1gXL+OsYuRk0NC wETi97kWJghbTOLCvfVsILaQwBFGif5j+hD2EkaJVxcTuxg5ONgELCS6/2mDhEUEkiR2n7vL CmILA9lrtn1jAykREUiWmLzBG6LESGLSpH6wEhYBVYnl5+6ClfAK+EpMnaXaxcgFNPwXs8T5 6/PAajgFNCWmf7zKAmIzAl3z/dQasMuYBcQlmr6sZIW4UkBiyZ7zzBC2qMTLx/9YIWryJbb9 ugEW5xUQlDg58wnLBEbhWUjaZyEpm4WkDCJuIPHl/W0oW1ti2cLXzBC2vkT3+9NMyOILGNlX MYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgRGz8Etv3V3MK5+7XiIUYCDUYmHt+B9e4gQa2JZ cWXuIUZpDhYlcd5F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAUS5+6ZM2kw5tmec2z aGiz+/WmYsXv4LoyQZH4B3v/zb++bGWXe/EEp/KfS9yvCoXYXb9YcYvhv3VeyvGLuRXeZe6r 1yzkvu52Jz622NIzoeTipSe8RWsjpHLEHvDypkkUrwlh2hu3NEpvqseKRcfO50qkcxzWMfYP /lc3Z9Xm41Fsm3OEF75TYinOSDTUYi4qTgQAcXVzYH8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/U_RwhJSGDPGpbiUwkZPbfyl0Tv4 Subject: Re: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of the room: mti codec) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 17:20:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D58C9A8ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, Note that Adam didn't define the terminology - he used the terminology defi= ned in the rtcweb-overview document. So, if someone has issues with the ter= minology, I think those issues should be addressed against that document. Regards, Christer Sent from my Windows Phone ________________________________ From: Sergio Garcia Murillo Sent: =FD10/=FD12/=FD2014 16:59 To: rtcweb@ietf.org Subject: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of the= room: mti codec) Hi Gaelle It is vague on purpose. What WebRTC does in regards of "WebRTC compatible e= ndpoints" is just describing a reality, there will be some entities that do= not comply with the WebRTC specs, but still are able to speak with WebRTC = devices/browsers/endpoints/gateways because they implement a set of specs t= hat WebRTC is built upon. So you can either ignore them, or assume that they are in the wild outside = and describe how they look like and how they could interact with WebRTC. An= d, by definition, you can't put any kind of requirement to entities that do= comply with the spec. Best regards Sergio On 10/12/2014 15:47, Gaelle Martin-Cocher wrote: +1 The vagueness of the WebRTC-compatible endpoint definition and the feature = set it covers is worrisome. It is introducing sub-standards within a specification. The various discussions show that we have been essentially looking at it ei= ther as containing all features but one codec, or the feature set needed f= or a gateway. That category could covers something that does only does 15% = of WebRTC. It might =93successfully communicate with a WebRTC endpoint=94 b= ut what does it means? How painful will that be to deal with such endpoint, assuming it somewhat c= onnects to your own product? It might be more appropriate to relax requirements for both the WebRTC gate= way and a new entity than having such a vague category. Ga=EBlle From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Wednesday, December 10, 2014 6:18 AM To: Bernard Aboba Cc: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec On Wed, Dec 10, 2014 at 2:03 AM, Bernard Aboba > wrote: My bad. New question: How can an endpoint that implements video but none of the MT= I codecs be construed as "WebRTC Compatible"? Well, this seems like a generic complaint about the term "compatible", sinc= e such endpoints are explicitly not required to meet any requirements: A WebRTC-compatible endpoint is an endpoint that is able to successfully communicate with a WebRTC endpoint, but may fail to meet some requirements of a WebRTC endpoint. This may limit where in the network such an endpoint can be attached, or may limit the security guarantees that it offers to others. It is not constrained by this specification; when it is mentioned at all, it is to note the implications on WebRTC-compatible endpoints of the requirements placed on WebRTC endpoints. So, perhaps we need a new term, but this doesn't seem like an issue limited= to video codecs -Ekr On Tue, Dec 9, 2014 at 2:01 PM, Eric Rescorla > wrote: On Tue, Dec 9, 2014 at 9:31 PM, Bernard Aboba > wrote: Allowing an endpoint that implements video to call itself "WebRTC compliant= " without implementing either of the MTI codecs is so wrong-headed that I a= m at a loss for words. I believe you have misread the proposal. The term "WebRTC compliant" never = appears anywhere in https://tools.ietf.org/html/draft-ietf-rtcweb-video-03. Indeed,= the word "compliant" does not appear. Rather, endpoints which implement neither codec qualify as "WebRTC Compatib= le". -Ekr On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway > wrote: Thanks Sean, We can not support this draft at this time. As RTC SDK vendors we very likely will support both codecs, but we can not = stand by a decision that will "impose" dual MTI on our developer community. According to this, every dev must use both codecs for every app that is bui= lt using our tools. Codec selection should be their choice and not be force= d upon them. This seems to be a rather unreasonable expectation. Erik Lagerway | Hookflash | 1 (855) Hookflash ext. 2 | Twitter | WebRTC.is Blog On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner > wrote: All, At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about co= decs, which I dubbed "the great codec compromise." The compromise text tha= t was discussed appears in slides 12-14 at [4] (which is a slight editorial= variation of the text proposed at [2]). This message serves to confirm the sense of the room. In the room, I heard the following objections and responses (and I=92m para= phrasing here), which I=92ll take the liberty of categorizing as IPR, Time,= and Trigger: 1) IPR: Objections: There are still IPR concerns which may restrict what a particul= ar organization feels comfortable with including in their browser implement= ations. Response: IPR concerns on this topic are well known. There is even a draf= t summarizing the current IPR status for VP8: draft-benham-rtcweb-vp8litiga= tion. The sense of the room was still that adopting the compromise text wa= s appropriate. 2) Time: 2.1) Time to consider decision: Objection: The decision to consider the compromise proposal at this meeting= was provided on short notice and did not provide some the opportunity to a= ttend in person. Response: Six months ago the chairs made it clear discussion would be revi= sited @ IETF 91 [0]. The first agenda proposal for the WG included this top= ic [1], and the topic was never removed by the chairs. More importantly,= all decisions are confirmed on list; in person attendance is not required = to be part of the process. 2.2) Time to consider text: Objection: The proposed text [2] is too new to be considered. Response: The requirement for browsers to support both VP8 and H.264 was am= ong the options in the straw poll conducted more than six months ago. All = decisions are confirmed on list so there will be ample time to discuss the = proposal. 3) Trigger: Objection: The =93trigger=94 sentence [3] is all kinds of wrong because it= =92s promising that the future IETF will update this specification. Response: Like any IETF proposal, an RFC that documents the current proposa= l can be changed through the consensus process at any other time. After the discussion, some clarifying questions about the hums, and typing = the hum questions on the screen, there was rough consensus in the room to a= dd (aka =93shove=94) the proposed text into draft-ietf-rtcweb-video. In ke= eping with IETF process, I am confirming this consensus call on the list. If anyone has any other issues that they would like to raise please do by D= ecember 19th. Cheers, spt (as chair) [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html [3] The one that begins with "If compelling evidence ..." [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf _______________________________________________ --_000_7594FB04B1934943A5C02806D1A2204B1D58C9A8ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

Note that Adam didn't define the terminology - he used the terminology defi= ned in the rtcweb-overview document. So, if someone has issues with the ter= minology, I think those issues should be addressed against that document.
Regards,

Christer

Sent from my Windows Phone
From: Sergio Garcia Murillo
Sent: =FD10= /=FD12/=FD2014 16:59
To: rtcweb@ietf.org
Subject: [rtcw= eb] WebRTC compatible endpoints (WAS: confirming sense of the room: mti cod= ec)

Hi Gaelle

It is vague on purpose. What WebRTC does in regards of "WebRTC compati= ble endpoints" is just describing a reality, there will be some entiti= es that do not comply with the WebRTC specs, but still are able to speak wi= th WebRTC devices/browsers/endpoints/gateways because they implement a set of specs that WebRTC is built upon.

So you can either ignore them, or assume that they are in the wild outside = and describe how they look like and how they could interact with WebRTC. An= d, by definition, you can't put any kind of requirement to entities that do= comply with the spec.

Best regards
Sergio

On 10/12/2014 15:47, Gaelle Martin-Cocher wrote:

+1

The vagueness of the We= bRTC-compatible endpoint definition and the feature set it covers is worris= ome.

It is introducing sub-s= tandards within a specification.

The various discussions= show that we have been essentially looking at it either as containing = ; all features but one codec, or the feature set needed for a gateway. That category could covers something that does only does 15% of W= ebRTC. It might =93successfully communicate with a WebRTC endpoint=94 but w= hat does it means?  

How painful will that b= e to deal with such endpoint, assuming it somewhat connects to your own pro= duct?

 

It might be more approp= riate to relax requirements for both the WebRTC gateway and a new entity th= an having such a vague category.

Ga=EBlle

 

From: rtcweb= [mailto:rtcweb-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Wednesday, December 10, 2014 6:18 AM
To: Bernard Aboba
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] confirming sense of the room: mti codec=

 

On Wed, Dec 10, 2014 at 2:03 AM, Bernard Aboba <<= a href=3D"mailto:bernard.aboba@gmail.com" target=3D"_blank">bernard.aboba@g= mail.com> wrote:

My bad. 

 

New question:  How can an endpoint that impleme= nts video but none of the MTI codecs be construed as "WebRTC Comp= atible"? 

 

Well, this seems like a generic complaint about the = term "compatible", since such

endpoints are explicitly not required to meet any re= quirements:

 

     A WebRTC-compatible endpoint is an endpoin=
t that is able to
      successfully c=
ommunicate with a WebRTC endpoint, but may fail to
      meet some requ=
irements of a WebRTC endpoint.  This may limit where
      in the network=
 such an endpoint can be attached, or may limit the
      security guara=
ntees that it offers to others.  It is not
      constrained by=
 this specification; when it is mentioned at all, it
      is to note the=
 implications on WebRTC-compatible endpoints of the
      requirements p=
laced on WebRTC endpoints.
 
So, perhaps we need a new term, but this does=
n't seem like an issue limited to
video codecs
 
-Ekr
 

On Tue, Dec 9, 2014 at 2:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:=

 

On Tue, Dec 9, 2014 at 9:31 PM, Bernard Aboba <bernard.aboba@gm= ail.com> wrote:

Allowing an endpoint that implements video to call i= tself "WebRTC compliant" without implementing either of the MTI c= odecs is so wrong-headed that I am at a loss for words.

 

I believe you have misread the proposal. The term &q= uot;WebRTC compliant" never appears

"compliant" does not appear.

 

Rather, endpoints which implement neither codec qual= ify as "WebRTC Compatible".

 

-Ekr

 

 

On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway <<= a href=3D"mailto:erik@hookflash.com" target=3D"_blank">erik@hookflash.com> wrote:

Thanks Sean,

 

We can not support this draft at this time.

 

As RTC SDK vendors we very likely will support both = codecs, but we can not stand by a decision that will "impose" dua= l MTI on our developer community.

 

According to this, every dev must use both codecs fo= r every app that is built using our tools. Codec selection should be their = choice and not be forced upon them. This seems to be a rather unreasonable = expectation.

 


Erik Lagerway | Hookflash | 1 (855) Hookflash ext. 2 | = Twitter | WebRTC.is Blog 

 

On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner <turners@ieca.com> = wrote:

All,

At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about co= decs, which I dubbed "the great codec compromise."  The comp= romise text that was discussed appears in slides 12-14 at [4] (which is a s= light editorial variation of the text proposed at [2]).

This message serves to confirm the sense of the room.

In the room, I heard the following objections and responses (and I=92m para= phrasing here), which I=92ll take the liberty of categorizing as IPR, Time,= and Trigger:

1) IPR:

Objections: There are still IPR concerns which may restrict what a particul= ar organization feels comfortable with including in their browser implement= ations.

Response:  IPR concerns on this topic are well known.  There is e= ven a draft summarizing the current IPR status for VP8: draft-benham-rtcweb= -vp8litigation.  The sense of the room was still that adopting the com= promise text was appropriate.

2) Time:

2.1) Time to consider decision:

Objection: The decision to consider the compromise proposal at this meeting= was provided on short notice and did not provide some the opportunity to a= ttend in person.

Response:  Six months ago the chairs made it clear discussion would be= revisited @ IETF 91 [0]. The first agenda proposal for the WG included thi= s topic [1], and the topic was never removed by the chairs.    Mo= re importantly, all decisions are confirmed on list; in person attendance is not required to be part of the process.

2.2) Time to consider text:

Objection: The proposed text [2] is too new to be considered.

Response: The requirement for browsers to support both VP8 and H.264 was am= ong the options in the straw poll conducted more than six months ago. = All decisions are confirmed on list so there will be ample time to discuss= the proposal.

3) Trigger:

Objection: The =93trigger=94 sentence [3] is all kinds of wrong because it= =92s promising that the future IETF will update this specification.

Response: Like any IETF proposal, an RFC that documents the current proposa= l can be changed through the consensus process at any other time.


After the discussion, some clarifying questions about the hums, and typing = the hum questions on the screen, there was rough consensus in the room to a= dd (aka =93shove=94) the proposed text into draft-ietf-rtcweb-video.  = In keeping with IETF process, I am confirming this consensus call on the list.

If anyone has any other issues that they would like to raise please do by D= ecember 19th.

Cheers,
spt (as chair)

[0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html
[1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html
[2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html
[3] The one that begins with "If compelling evidence ..."
[4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf
_______________________________________________


--_000_7594FB04B1934943A5C02806D1A2204B1D58C9A8ESESSMB209erics_-- From nobody Wed Dec 10 10:00:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDDB1A8763 for ; Wed, 10 Dec 2014 10:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EZSabrguQuD for ; Wed, 10 Dec 2014 09:59:57 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id A15731A00BD for ; Wed, 10 Dec 2014 09:59:56 -0800 (PST) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 10 Dec 2014 12:59:48 -0500 Received: from XCT111CNC.rim.net (10.65.161.211) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.210.2; Wed, 10 Dec 2014 12:59:48 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT111CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Wed, 10 Dec 2014 12:59:47 -0500 From: Gaelle Martin-Cocher To: Christer Holmberg , Sergio Garcia Murillo , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of the room: mti codec) Thread-Index: AQHQFInbVBWK6YoLoEyBNpmZ4G+pQ5yJZckA//+unHA= Date: Wed, 10 Dec 2014 17:59:47 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF35E6EF@XMB111CNC.rim.net> References: <92D0D52F3A63344CA478CF12DB0648AADF35E2BB@XMB111CNC.rim.net>, <54885FA3.3060602@gmail.com> <7594FB04B1934943A5C02806D1A2204B1D58C9A8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D58C9A8@ESESSMB209.ericsson.se> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/alternative; boundary="_000_92D0D52F3A63344CA478CF12DB0648AADF35E6EFXMB111CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Qpacu_DGtqtlKo49OiOcCqMbPmk Subject: Re: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of the room: mti codec) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 18:00:04 -0000 --_000_92D0D52F3A63344CA478CF12DB0648AADF35E6EFXMB111CNCrimnet_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable The main problem is with what the terminology covers and its inconsistent u= sage. The WebRTC gateway in https://tools.ietf.org/id/draft-alvestrand-rtcweb-gat= eways-01.txt is defined as a WebRTC-compatible endpoint with some requireme= nts being applied to it. I am not sure how the last sentence in the WebRTC-compatible endpoint defin= ition =93It is not constrained by this specification=85=94 applies to the= gateway. If a mobile app is centered around text or text and audio, it should not be= relegated in the WebRTC-compatible endpoint category and should be able to= benefit from the WebRTC non browser/endpoint terminology . If a WebRTC-compatible endpoint supports everything but a subset of functio= ns (e.g. does not support bundle) there could be requirements applied to i= t; in IETF or in other standardization groups that are referring to the IET= F terminology. I don=92t think it is fine to have in a specification an unclear category i= n which both =91meaningful=92 entities (gateway, current WebRTC librairies,= the above examples or Ron=92s coffee maker) and possibly some sub-standard= =93things=94 belong. One way would be to defined the minimum requirements for a WebRTC-compatibl= e endpoint to =93successfully communicate with a WebRTC endpoint=94. In addition, the WebRTC gateway could be removed from the WebRTC-compatible= endpoint category. There might be enough differences to justify two entit= ies. Changing the naming of =93WebRTC-compatible=94 to a less confusing term is = a cosmetic change (but might be a good thing). Ga=EBlle From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Wednesday, December 10, 2014 12:20 PM To: Sergio Garcia Murillo; rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of= the room: mti codec) Hi, Note that Adam didn't define the terminology - he used the terminology defi= ned in the rtcweb-overview document. So, if someone has issues with the ter= minology, I think those issues should be addressed against that document. Regards, Christer Sent from my Windows Phone ________________________________ From: Sergio Garcia Murillo Sent: =FD10/=FD12/=FD2014 16:59 To: rtcweb@ietf.org Subject: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of the= room: mti codec) Hi Gaelle It is vague on purpose. What WebRTC does in regards of "WebRTC compatible e= ndpoints" is just describing a reality, there will be some entities that do= not comply with the WebRTC specs, but still are able to speak with WebRTC = devices/browsers/endpoints/gateways because they implement a set of specs t= hat WebRTC is built upon. So you can either ignore them, or assume that they are in the wild outside = and describe how they look like and how they could interact with WebRTC. An= d, by definition, you can't put any kind of requirement to entities that do= comply with the spec. Best regards Sergio On 10/12/2014 15:47, Gaelle Martin-Cocher wrote: +1 The vagueness of the WebRTC-compatible endpoint definition and the feature = set it covers is worrisome. It is introducing sub-standards within a specification. The various discussions show that we have been essentially looking at it ei= ther as containing all features but one codec, or the feature set needed f= or a gateway. That category could covers something that does only does 15% = of WebRTC. It might =93successfully communicate with a WebRTC endpoint=94 b= ut what does it means? How painful will that be to deal with such endpoint, assuming it somewhat c= onnects to your own product? It might be more appropriate to relax requirements for both the WebRTC gate= way and a new entity than having such a vague category. Ga=EBlle From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Wednesday, December 10, 2014 6:18 AM To: Bernard Aboba Cc: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec On Wed, Dec 10, 2014 at 2:03 AM, Bernard Aboba > wrote: My bad. New question: How can an endpoint that implements video but none of the MT= I codecs be construed as "WebRTC Compatible"? Well, this seems like a generic complaint about the term "compatible", sinc= e such endpoints are explicitly not required to meet any requirements: A WebRTC-compatible endpoint is an endpoint that is able to successfully communicate with a WebRTC endpoint, but may fail to meet some requirements of a WebRTC endpoint. This may limit where in the network such an endpoint can be attached, or may limit the security guarantees that it offers to others. It is not constrained by this specification; when it is mentioned at all, it is to note the implications on WebRTC-compatible endpoints of the requirements placed on WebRTC endpoints. So, perhaps we need a new term, but this doesn't seem like an issue limited= to video codecs -Ekr On Tue, Dec 9, 2014 at 2:01 PM, Eric Rescorla > wrote: On Tue, Dec 9, 2014 at 9:31 PM, Bernard Aboba > wrote: Allowing an endpoint that implements video to call itself "WebRTC compliant= " without implementing either of the MTI codecs is so wrong-headed that I a= m at a loss for words. I believe you have misread the proposal. The term "WebRTC compliant" never = appears anywhere in https://tools.ietf.org/html/draft-ietf-rtcweb-video-03. Indeed,= the word "compliant" does not appear. Rather, endpoints which implement neither codec qualify as "WebRTC Compatib= le". -Ekr On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway > wrote: Thanks Sean, We can not support this draft at this time. As RTC SDK vendors we very likely will support both codecs, but we can not = stand by a decision that will "impose" dual MTI on our developer community. According to this, every dev must use both codecs for every app that is bui= lt using our tools. Codec selection should be their choice and not be force= d upon them. This seems to be a rather unreasonable expectation. Erik Lagerway | Hookflash | 1 (855) Hookflash ext. 2 | Twitter | WebRTC.is Blog On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner > wrote: All, At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about co= decs, which I dubbed "the great codec compromise." The compromise text tha= t was discussed appears in slides 12-14 at [4] (which is a slight editorial= variation of the text proposed at [2]). This message serves to confirm the sense of the room. In the room, I heard the following objections and responses (and I=92m para= phrasing here), which I=92ll take the liberty of categorizing as IPR, Time,= and Trigger: 1) IPR: Objections: There are still IPR concerns which may restrict what a particul= ar organization feels comfortable with including in their browser implement= ations. Response: IPR concerns on this topic are well known. There is even a draf= t summarizing the current IPR status for VP8: draft-benham-rtcweb-vp8litiga= tion. The sense of the room was still that adopting the compromise text wa= s appropriate. 2) Time: 2.1) Time to consider decision: Objection: The decision to consider the compromise proposal at this meeting= was provided on short notice and did not provide some the opportunity to a= ttend in person. Response: Six months ago the chairs made it clear discussion would be revi= sited @ IETF 91 [0]. The first agenda proposal for the WG included this top= ic [1], and the topic was never removed by the chairs. More importantly,= all decisions are confirmed on list; in person attendance is not required = to be part of the process. 2.2) Time to consider text: Objection: The proposed text [2] is too new to be considered. Response: The requirement for browsers to support both VP8 and H.264 was am= ong the options in the straw poll conducted more than six months ago. All = decisions are confirmed on list so there will be ample time to discuss the = proposal. 3) Trigger: Objection: The =93trigger=94 sentence [3] is all kinds of wrong because it= =92s promising that the future IETF will update this specification. Response: Like any IETF proposal, an RFC that documents the current proposa= l can be changed through the consensus process at any other time. After the discussion, some clarifying questions about the hums, and typing = the hum questions on the screen, there was rough consensus in the room to a= dd (aka =93shove=94) the proposed text into draft-ietf-rtcweb-video. In ke= eping with IETF process, I am confirming this consensus call on the list. If anyone has any other issues that they would like to raise please do by D= ecember 19th. Cheers, spt (as chair) [0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html [2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html [3] The one that begins with "If compelling evidence ..." [4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf _______________________________________________ --_000_92D0D52F3A63344CA478CF12DB0648AADF35E6EFXMB111CNCrimnet_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable

The main problem is with = what the terminology covers and its inconsistent usage.

 <= /p>

The WebRTC gateway in https://tools.ietf.org/id/draft-alvestrand-rtcweb-gateways-01.txt is= defined as a WebRTC-compatible endpoint with some requirements being appli= ed to it.

I am not sure how the las= t sentence in the WebRTC-compatible endpoint definition  =93It is not = constrained by this specification=85=94  applies to the gateway.<= /o:p>

 <= /p>

If a mobile app is center= ed around text or text and audio, it should not be relegated in the WebRTC-= compatible endpoint category and should be able to benefit from the WebRTC non browser/endpoint terminology .

 <= /p>

If a WebRTC-compatible en= dpoint supports everything but a subset of functions (e.g. does not support= bundle)  there could be requirements applied to it; in IETF or in other standardization groups that are referring to the IETF ter= minology.

 <= /p>

I don=92t think it is fin= e to have in a specification an unclear category in which both =91meaningfu= l=92 entities (gateway, current WebRTC librairies, the above examples or Ron=92s coffee maker) and possibly some sub-standard =93things=94 belon= g.

 <= /p>

One way would be to defin= ed the minimum requirements for a WebRTC-compatible endpoint to =93successf= ully communicate with a WebRTC endpoint=94.   <= /p>

In addition, the WebRTC g= ateway could be removed from the WebRTC-compatible endpoint category. There= might be enough differences to  justify two entities.

Changing the naming of = =93WebRTC-compatible=94 to a less confusing term is a cosmetic change (but = might be a good thing).

 <= /p>

Ga=EBlle

 <= /p>

 <= /p>

From: rtcweb [= mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Wednesday, December 10, 2014 12:20 PM
To: Sergio Garcia Murillo; rtcweb@ietf.org
Subject: Re: [rtcweb] WebRTC compatible endpoints (WAS: confirming s= ense of the room: mti codec)

 

Hi,

Note that Adam didn't define the terminology - he used the terminology defi= ned in the rtcweb-overview document. So, if someone has issues with the ter= minology, I think those issues should be addressed against that document.
Regards,

Christer

Sent from my Windows Phone

From: = Sergio Garcia Murillo
Sent: =FD10/=FD12/=FD2014 16:59
To: rtcweb@ietf.org
Subject: [rtcweb] WebRTC compatible endpoints (WAS: confirming sens= e of the room: mti codec)

Hi Gaelle

It is vague on purpose. What WebRTC does in regards of "WebRTC compati= ble endpoints" is just describing a reality, there will be some entiti= es that do not comply with the WebRTC specs, but still are able to speak wi= th WebRTC devices/browsers/endpoints/gateways because they implement a set of specs that WebRTC is built upon.

So you can either ignore them, or assume that they are in the wild outside = and describe how they look like and how they could interact with WebRTC. An= d, by definition, you can't put any kind of requirement to entities that do= comply with the spec.

Best regards
Sergio

On 10/12/2014 15:47, Gaelle Martin-Cocher wrote:

+1<= /p>

The vagueness of the WebR= TC-compatible endpoint definition and the feature set it covers is worrisom= e.

It is introducing sub-sta= ndards within a specification.

The various discussions s= how that we have been essentially looking at it either as containing  = all features but one codec, or the feature set needed for a gateway. That category could covers something that does only does 15% of WebRTC. It= might =93successfully communicate with a WebRTC endpoint=94 but what does = it means?  

How painful will that be = to deal with such endpoint, assuming it somewhat connects to your own produ= ct?

 <= /p>

It might be more appropri= ate to relax requirements for both the WebRTC gateway and a new entity than= having such a vague category.

Ga=EBlle

 <= /p>

From: rtcweb [= mailto:rtcweb-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Wednesday, December 10, 2014 6:18 AM
To: Bernard Aboba
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] confirming sense of the room: mti codec=

 

On Wed, Dec 10, 2014 at 2:03 AM, Bernard Aboba <<= a href=3D"mailto:bernard.aboba@gmail.com" target=3D"_blank">bernard.aboba@g= mail.com> wrote:

My bad. 

 

New question:  How can an endpoint that impleme= nts video but none of the MTI codecs be construed as "WebRTC Comp= atible"? 

 

Well, this seems like a generic complaint about the = term "compatible", since such

endpoints are explicitly not required to meet any re= quirements:

 

     A WebRTC-compatible endpoint is an endpoint t=
hat is able to
      successfully com=
municate with a WebRTC endpoint, but may fail to
      meet some requir=
ements of a WebRTC endpoint.  This may limit where

      in the network s=
uch an endpoint can be attached, or may limit the


      security guarant=
ees that it offers to others.  It is not


      constrained by t=
his specification; when it is mentioned at all, it


      is to note the i=
mplications on WebRTC-compatible endpoints of the


      requirements pla=
ced on WebRTC endpoints.


 <=
/pre>

So, perhaps we need a new term, but this doesn'=
t seem like an issue limited to


video codecs


 <=
/pre>

-Ekr


 <=
/pre>

On Tue, Dec 9, 2014 at 2:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:=

 

On Tue, Dec 9, 2014 at 9:31 PM, Bernard Aboba <bernard.aboba@gm= ail.com> wrote:

Allowing an endpoint that implements video to call i= tself "WebRTC compliant" without implementing either of the MTI c= odecs is so wrong-headed that I am at a loss for words.

 

I believe you have misread the proposal. The term &q= uot;WebRTC compliant" never appears

"compliant" does not appear.

 

Rather, endpoints which implement neither codec qual= ify as "WebRTC Compatible".

 

-Ekr

 

 

On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway <<= a href=3D"mailto:erik@hookflash.com" target=3D"_blank">erik@hookflash.com> wrote:

Thanks Sean,

 

We can not support this draft at this time.

 

As RTC SDK vendors we very likely will support both = codecs, but we can not stand by a decision that will "impose" dua= l MTI on our developer community.

 

According to this, every dev must use both codecs fo= r every app that is built using our tools. Codec selection should be their = choice and not be forced upon them. This seems to be a rather unreasonable = expectation.

 


Erik Lagerway | Hookflash | 1 (855) Hookflash ext. 2 | Twitter | WebRTC.is Blog 

 

On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner <turners@ieca.com> = wrote:

All,

At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about co= decs, which I dubbed "the great codec compromise."  The comp= romise text that was discussed appears in slides 12-14 at [4] (which is a s= light editorial variation of the text proposed at [2]).

This message serves to confirm the sense of the room.

In the room, I heard the following objections and responses (and I=92m para= phrasing here), which I=92ll take the liberty of categorizing as IPR, Time,= and Trigger:

1) IPR:

Objections: There are still IPR concerns which may restrict what a particul= ar organization feels comfortable with including in their browser implement= ations.

Response:  IPR concerns on this topic are well known.  There is e= ven a draft summarizing the current IPR status for VP8: draft-benham-rtcweb= -vp8litigation.  The sense of the room was still that adopting the com= promise text was appropriate.

2) Time:

2.1) Time to consider decision:

Objection: The decision to consider the compromise proposal at this meeting= was provided on short notice and did not provide some the opportunity to a= ttend in person.

Response:  Six months ago the chairs made it clear discussion would be= revisited @ IETF 91 [0]. The first agenda proposal for the WG included thi= s topic [1], and the topic was never removed by the chairs.    Mo= re importantly, all decisions are confirmed on list; in person attendance is not required to be part of the process.

2.2) Time to consider text:

Objection: The proposed text [2] is too new to be considered.

Response: The requirement for browsers to support both VP8 and H.264 was am= ong the options in the straw poll conducted more than six months ago. = All decisions are confirmed on list so there will be ample time to discuss= the proposal.

3) Trigger:

Objection: The =93trigger=94 sentence [3] is all kinds of wrong because it= =92s promising that the future IETF will update this specification.

Response: Like any IETF proposal, an RFC that documents the current proposa= l can be changed through the consensus process at any other time.


After the discussion, some clarifying questions about the hums, and typing = the hum questions on the screen, there was rough consensus in the room to a= dd (aka =93shove=94) the proposed text into draft-ietf-rtcweb-video.  = In keeping with IETF process, I am confirming this consensus call on the list.

If anyone has any other issues that they would like to raise please do by D= ecember 19th.

Cheers,
spt (as chair)

[0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html
[1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html
[2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html
[3] The one that begins with "If compelling evidence ..."
[4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf
_______________________________________________

 

--_000_92D0D52F3A63344CA478CF12DB0648AADF35E6EFXMB111CNCrimnet_-- From nobody Wed Dec 10 10:09:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041391A1A31 for ; Wed, 10 Dec 2014 10:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVtcQ9wnq89r for ; Wed, 10 Dec 2014 10:09:33 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id E4B281A00BD for ; Wed, 10 Dec 2014 10:09:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 79DC27C09BB for ; Wed, 10 Dec 2014 19:09:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSWT44aoUbYv for ; Wed, 10 Dec 2014 19:09:27 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:68db:b80d:1b40:19e2] (unknown [IPv6:2001:470:de0a:27:68db:b80d:1b40:19e2]) by mork.alvestrand.no (Postfix) with ESMTPSA id 8AA927C3557 for ; Wed, 10 Dec 2014 19:09:27 +0100 (CET) Message-ID: <54888C56.2060009@alvestrand.no> Date: Wed, 10 Dec 2014 19:09:26 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <92D0D52F3A63344CA478CF12DB0648AADF35E2BB@XMB111CNC.rim.net>, <54885FA3.3060602@gmail.com> <7594FB04B1934943A5C02806D1A2204B1D58C9A8@ESESSMB209.ericsson.se> <92D0D52F3A63344CA478CF12DB0648AADF35E6EF@XMB111CNC.rim.net> In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF35E6EF@XMB111CNC.rim.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ElJXp2uHfFWYCeL6XoP5-XhLgv4 Subject: Re: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of the room: mti codec) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 18:09:36 -0000 Den 10. des. 2014 18:59, skrev Gaelle Martin-Cocher: > The main problem is with what the terminology covers and its > inconsistent usage. > > > > The WebRTC gateway in > https://tools.ietf.org/id/draft-alvestrand-rtcweb-gateways-01.txt is > defined as a WebRTC-compatible endpoint with some requirements being > applied to it. > > I am not sure how the last sentence in the WebRTC-compatible endpoint > definition “It is not constrained by this specification…” applies to > the gateway. Renaming the term is certainly possible. And this thread has certainly made the point that the -gateways draft needs to be informative, not standards-track. > > > > If a mobile app is centered around text or text and audio, it should not > be relegated in the WebRTC-compatible endpoint category and should be > able to benefit from the WebRTC non browser/endpoint terminology . > > > > If a WebRTC-compatible endpoint supports everything but a subset of > functions (e.g. does not support bundle) there could be requirements > applied to it; in IETF or in other standardization groups that are > referring to the IETF terminology. I see absolutely no reason to go down this path. If you want a standard that specifies conformance to a spec that is part of the WebRTC spec, you are of course free to try to do so. But I see no reason to join in on that journey. From nobody Wed Dec 10 10:41:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF6A1A6FA8 for ; Wed, 10 Dec 2014 10:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-mvwTxPv2gI for ; Wed, 10 Dec 2014 10:40:59 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE3E1A6FD0 for ; Wed, 10 Dec 2014 10:40:14 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wp18so2713860obc.15 for ; Wed, 10 Dec 2014 10:40:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=gAB4OEEPqHuYAlZeFMHox3t6Sg0UNicHt1At87yEp/s=; b=u173IO8siUWoyoEyN7psP31Frl8Ovml03Imvb33+t3KkxxBmVRcilaq1lu2FvLR3wb Oo1qRp5tVSqHunmQ8mz8sPzpQxvacyt34tDBP4UDULgMGLQaMMtKLJpEAgwqUzF7S6A+ 7+/IJsuKyH2Oqgc33de/qbsHnL8Vq5pPsLnsFGmPVASj8CODGX8f93QjwjPjvHb30Iap 8Zdu4Gs8EKyg7metxN+gsXRczNGDnEA3eicrqWO+M8vz/+Vl0KeRv6OGaOCJMQJH/jx2 4/cC80vPN54hmngODXUi/Wsu9FTymMB/RljR+dbVD/mUtKhWhng6pqNCfEPOy6/VFcC0 BQvw== MIME-Version: 1.0 X-Received: by 10.202.54.86 with SMTP id d83mr3402280oia.55.1418236814042; Wed, 10 Dec 2014 10:40:14 -0800 (PST) Received: by 10.202.85.133 with HTTP; Wed, 10 Dec 2014 10:40:13 -0800 (PST) In-Reply-To: References: <5486C48D.8040602@alvestrand.no> <54873575.3030804@nostrum.com> <53ECE529-C011-4666-B044-226613CA263D@apple.com> Date: Thu, 11 Dec 2014 02:40:13 +0800 Message-ID: From: Alexandre GOUAILLARD To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a113ce1b08234020509e0fdae Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BopFpLbEz7D9G0ttwtILEYfTS0I Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 18:41:01 -0000 --001a113ce1b08234020509e0fdae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Temasys supports the dual codec proposal. We will support at least vp8 and H.264 in most of our products (BE, plugin, SDKs) and of course more codecs where it makes sense (AVC high profile is a good example, VP8 with temporal scalability is another). We plan to provide support for at least VP8 and H.264 (with hardware acc when possible i.e. iOS 8+) when porting webrtc to webkit. What will be supported in the ports/browsers using webkit as a rendering engine (*cough* *safari**cough*) will be up to those ports maintainers. On Wed, Dec 10, 2014 at 8:54 PM, I=C3=B1aki Baz Castillo wr= ote: > 2014-12-09 20:11 GMT+01:00 Cavigioli, Chris : > > Paying for codecs pays for research labs to continue their research to > > invent new things > > Please, don't go there. The business model of research labs is not the > subject here, and I assume you agree that the W3C's goal is not to > satisfy any business model. > > Said that, there are some "minor" examples in the world that may > contradict what you said, such as the Linux and open source whole > ecosystem. Anyhow, that is not the subject. > > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --=20 Alex. Gouaillard, PhD, PhD, MBA ---------------------------------------------------------------------------= --------- CTO - Temasys Communications, S'pore / Mountain View President - CoSMo Software, Cambridge, MA ---------------------------------------------------------------------------= --------- sg.linkedin.com/agouaillard - --001a113ce1b08234020509e0fdae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --047d7bae493ee60073050a5b5fa2-- From nobody Tue Dec 16 12:42:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B31F1A87CE for ; Tue, 16 Dec 2014 12:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwboUgtoS8zU for ; Tue, 16 Dec 2014 12:42:06 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597E31A8777 for ; Tue, 16 Dec 2014 12:42:06 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id r20so13565436wiv.6 for ; Tue, 16 Dec 2014 12:42:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OtDrsOmoTRX82JxmO7GYhTBkmCj/W7CPfUARALA6V+U=; b=fiOyCxr6d1/zj4gzddiPlPCaZL67owzoNujF/KGywxOPbdxVWCLMHMKF6nT3T3+SE5 4EXYD5Fdirgkf0KGaWOu+nnrk9c3FgOrBbXYpHh6DK36pnsKsLaM1Vt3Z5WT4BJGpWO+ fjz51gdOGqtmznzhDwpazyfD0sYNhN0uGj8BD6VmaQopp3qU4GcQdDpKjCcgLWpYng90 j2Uib05zliy/GIVo16br0AWknqYg5eKFFiP/WIbliv2q1JZiBgNpskjjPd6dI+IDj7zS YY7Cnfd6RY8QbODfSO7GUYAZAbbWdiodp5FRuwGUqXMIGIu2rhqNSZgVkxVinBU24m3q fDKg== X-Gm-Message-State: ALoCoQlfE0w/YHPGS5nOFs5EzhMj0eYx4pXObRvw44Oa+q8JavPNhXzFQ51Fzcvj82ksdARAiVty X-Received: by 10.180.7.201 with SMTP id l9mr7805130wia.80.1418762525191; Tue, 16 Dec 2014 12:42:05 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com. [209.85.212.180]) by mx.google.com with ESMTPSA id f7sm3466824wiz.13.2014.12.16.12.42.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 12:42:04 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so13851803wiv.13 for ; Tue, 16 Dec 2014 12:42:03 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.38.6 with SMTP id c6mr8152616wik.38.1418762523798; Tue, 16 Dec 2014 12:42:03 -0800 (PST) Received: by 10.217.191.202 with HTTP; Tue, 16 Dec 2014 12:42:03 -0800 (PST) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B296427@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> <92D0D52F3A63344CA478CF12DB0648AADF363463@XMB111CNC.rim.net> <949EF20990823C4C85C18D59AA11AD8B296427@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Tue, 16 Dec 2014 15:42:03 -0500 Message-ID: From: Roman Shpount To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=e89a8f64334e40773e050a5b64fd Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Ll97Bub_5BT6AqnhHklrOI0MFkg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 20:42:09 -0000 --e89a8f64334e40773e050a5b64fd Content-Type: text/plain; charset=UTF-8 On Tue, Dec 16, 2014 at 2:56 PM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > > Forget it. > > You are making an attempt to reduce the entire issue to IPR, and the > discussion prior to the last meeting had been wider that that, including > issues of interoperability with endpoints outside webRTC. > > As far as I am concerned an IPR free codec is irrelevant if I cannot talk > to the endpoints I need to, and just concentrating on the webrtc community > as the available endpoint may meet some deployers use cases, but not others. > There is no such thing as IPR free codec, unless you are talking about H.261 or MJPEG where IPR has expired. What we are looking for is a video codec with an acceptable quality (both VP8 and H.264 qualify) and reasonable licensing (both VP8 and H.264 have serious issues here). If it is confirmed the VP8 licensing issues are resolved (i.e. it went through the standardization process, all IPR declaration against it which prevent licensing are confirmed to not apply in court or due to some sort of licencing agreement), then VP8 is clearly superior. If H.264 fixes its licensing (i.e. present a clear, published, no royalty licensing terms with no use restrictions), it can be a superior codec. Legacy interop support is important, but to me at least, it is secondary to unrestricted use. Please see Opus vs AMR-WB+ for clear similarities. Also, VP9 or H.265 would clearly improve video quality, but both VP8 and H.264 with the current connection speeds allow for the highly usable video communications. I think that quality wise, either one of VP8 and H.264 can serve as usable MTI for a lot longer then the next two years or whatever time is required for the next great video codec to be developed. Especially in another 5-6 years when all the IPR on these codecs will expire. _____________ Roman Shpount --e89a8f64334e40773e050a5b64fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 16, 2014 at 2:56 PM, DRAGE, Keith (Keith) <keith.drag= e@alcatel-lucent.com> wrote:
Forget it.
=C2=A0
You are making an attempt to reduce the entire issue to IPR, and the disc= ussion prior to the last meeting had been wider that that, including issues= of interoperability with endpoints outside webRTC.
=C2=A0
As far as I am concerned an IPR free codec is irrelevant if I cannot talk= to the endpoints I need to, and just concentrating on the webrtc community= as the available endpoint may meet some deployers use cases, but not others.<= /font>

There is no such thing as IPR free codec, unless you are talking about H.= 261 or MJPEG where IPR has expired. What we are looking for is a video code= c with an acceptable quality (both VP8 and H.264 qualify) and reasonable li= censing (both VP8 and H.264 have serious issues here). If it is confirmed t= he VP8 licensing issues are resolved (i.e. it went through the standardizat= ion process, all IPR declaration against it which prevent licensing are con= firmed to not apply in court or due to some sort of licencing agreement), t= hen VP8 is clearly superior. If H.264 fixes its licensing (i.e. present a c= lear, published, no royalty licensing terms with no use restrictions), it c= an be a superior codec. Legacy interop support is important, but to me at l= east, it is secondary to unrestricted use. Please see Opus vs AMR-WB+ for c= lear similarities.

Also, VP9 or H.265 would clearl= y =C2=A0improve video quality, but both VP8 and H.264 with the current conn= ection speeds allow for the highly usable video communications. I think tha= t quality wise, either one of VP8 and H.264 can serve as usable MTI for a l= ot longer then the next two years or whatever time is required for the next= great video codec to be developed. Especially in another 5-6 years when al= l the IPR on these codecs will expire.
_____________
Roman Shpount
--e89a8f64334e40773e050a5b64fd-- From nobody Tue Dec 16 13:52:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9350A1A8754 for ; Tue, 16 Dec 2014 13:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5QP9VNlE6Ue for ; Tue, 16 Dec 2014 13:52:12 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8BE1A8766 for ; Tue, 16 Dec 2014 13:52:10 -0800 (PST) Received: (qmail 11600 invoked from network); 16 Dec 2014 21:52:08 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 13829 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 16 Dec 2014 21:52:08 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id F40D918A1C65 for ; Tue, 16 Dec 2014 21:52:06 +0000 (GMT) Received: from [192.168.157.34] (unknown [192.67.4.66]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id E921018A0621 for ; Tue, 16 Dec 2014 21:52:06 +0000 (GMT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: tim panton In-Reply-To: Date: Tue, 16 Dec 2014 21:52:05 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <55E22C2A-EB8A-4296-A33D-A0DC10373D02@phonefromhere.com> References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> <92D0D52F3A63344CA478CF12DB0648AADF363463@XMB111CNC.rim.net> <949EF20990823C4C85C18D59AA11AD8B296427@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zjyVPexEeGOqdfeTbzXbzkZgmbU Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 21:52:13 -0000 > On 16 Dec 2014, at 20:42, Roman Shpount wrote: >=20 >=20 > There is no such thing as IPR free codec, unless you are talking about = H.261 or MJPEG where IPR has expired. What we are looking for is a video = codec with an acceptable quality (both VP8 and H.264 qualify) and = reasonable licensing (both VP8 and H.264 have serious issues here). When does the H264/VP8 IPR expire? It is clear this discussion will be = kept going around in circles =E2=80=98till then. T.= From nobody Tue Dec 16 14:25:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC101A0052 for ; Tue, 16 Dec 2014 14:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr0QwMQTWRCt for ; Tue, 16 Dec 2014 14:25:14 -0800 (PST) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0EC1A0049 for ; Tue, 16 Dec 2014 14:25:06 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id l4so11587569lbv.39 for ; Tue, 16 Dec 2014 14:25:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0iXjf52X19UEkxjoV80dlQn/6v32TO+xXozWEr6pe5Y=; b=Kjf11J70VYlD0JmVe85LHLMg3Y1iQvA7KXaR/6FvCSviRBaxqMUGqzxbjldS8g6+VX 3q4iw8uHH6fa8z8v4n+/kAZKDp3NfBlMmW8PX32xric9zUisL16Sb9mZ+Sg2nV2fMWC2 08r+70FEhHZt2wltxWLE3OYPE7UOjolJxTpLIO3oJefe3ng2GjhRtvwcxu7Q5DW1GXRu N1QmuwYgzguGG8GflZnSwgZIcQyn5ec0L0Khl0dRoiuKJ5kX905BjPIlr3wMzwvKLcBt O+hkO/PCud0PKtAEFW6wdI4r7FloA5b1YgE6Khg96V71pgvh1lWnrqBTMGrAZIwJMciy DA8A== X-Gm-Message-State: ALoCoQnoJfkX/dUG3s9Jyj53ADQScboN9cXr9TFHJ6tCgNUsqPkrZXW20PKPrQtxb9lUSsePNDIC MIME-Version: 1.0 X-Received: by 10.152.170.194 with SMTP id ao2mr38666480lac.12.1418768703674; Tue, 16 Dec 2014 14:25:03 -0800 (PST) Received: by 10.25.12.215 with HTTP; Tue, 16 Dec 2014 14:25:03 -0800 (PST) In-Reply-To: <54909562.7060504@gmail.com> References: <54908A65.1010705@gmail.com> <54909562.7060504@gmail.com> Date: Tue, 16 Dec 2014 17:25:03 -0500 Message-ID: From: Richard Barnes To: Daniel-Constantin Mierla Content-Type: multipart/alternative; boundary=089e011615f299f052050a5cd407 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/n5DGZLbL0XMmL4PwN3NErxrN-0M Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] clarifications on current discussions - re: confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 22:25:19 -0000 --089e011615f299f052050a5cd407 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey Daniel, I think Sean's original message was pretty clear about this: """ After the discussion, some clarifying questions about the hums, and typing the hum questions on the screen, there was rough consensus in the room to add (aka =E2=80=9Cshove=E2=80=9D) the proposed text into draft-ietf-rtcweb-= video. In keeping with IETF process, I am confirming this consensus call on the list. """ Nonetheless, if you think people have missed this point, feel free to prompt them to comment in that thread. Thanks, --Richard On Tue, Dec 16, 2014 at 3:26 PM, Daniel-Constantin Mierla wrote: > > Hi Richard, > > thanks for the clarification! IMO, the initial message content was not > stating explicitly this is the goal and apparently it misled the > expectation from some of us. > > Maybe it would be appropriate to have a fresh message sent by WG chairs/A= D > (or other IETF 'official' involved in the process) to say it explicitly b= y > subject, just in case someone (else than me) didn't understand (from > current discussions) that there is an ongoing call on consensus for video > MTI codec. There are still three days left that can prevent negative > reactions later. > > Daniel > > > On 16/12/14 21:03, Richard Barnes wrote: > > > > Hi Daniel, > > Thanks for the question. The goal of Sean's message is indeed to seek > consensus on the codec question. The time for discussion is to allow for > any other issues to be raised, beyond those that were raised in the room = in > Honolulu. At the end of the comment period on Friday, Sean will review t= he > discussion and make a determination as to whether a rough consensus has > been reached. > > --Richard > > > On Tue, Dec 16, 2014 at 2:39 PM, Daniel-Constantin Mierla < > miconda@gmail.com> wrote: >> >> With many forks of the thread and various opinions, can anyone clarify >> the expectation of these discussions. Ideally will be the WG chairs >> stating what is the role of the current discussions, specially to the >> initial thread with the subject 'confirming sense of the room: mti >> codec' started by Sean Turner - link to archive: >> >> - http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html >> >> My understanding was that it is about clarifying what happened during >> the sessions in Honolulu, not a call on consensus for the proposal. I >> get the feeling that many understood it differently, being the call on >> consensus for video MTI codecs. I saw many people simply stating there >> position in replies to this thread, which is ok if they want to >> say/reiterate it, but not addressing any of the points set for >> discussion by Sean. >> >> For a call on consensus I would expect to be with a explicit subject, >> including or pointing to the (draft of) text to be adopted. >> >> Which side got it wrong here? >> >> Thanks, >> Daniel >> >> -- >> Daniel-Constantin Mierla >> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > -- > Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linked= in.com/in/miconda > > --089e011615f299f052050a5cd407 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Daniel,

I think Sean's original messag= e was pretty clear about this:
"""
After the discussio= n, some clarifying questions about the hums, and typing the hum questions o= n the screen, there was rough consensus in the room to add (aka =E2=80=9Cshove=E2=80=9D) the proposed text into=20 draft-ietf-rtcweb-video.=C2=A0 In keeping with IETF process, I am confirmin= g=20 this consensus call on the list.
""&qu= ot;

Nonetheless, if you think people have missed this point, f= eel free to prompt them to comment in that thread.

Thanks,
--Rich= ard



On Tue, Dec 16, 2014 at 3:26 PM, Daniel-Constantin Mierla = <miconda@gmail.com> wrote:
=20 =20 =20
Hi Richard,

thanks for the clarification! IMO, the initial message content was not stating explicitly this is the goal and apparently it misled the expectation from some of us.

Maybe it would be appropriate to have a fresh message sent by WG chairs/AD (or other IETF 'official' involved in the process) to= say it explicitly by subject, just in case someone (else than me) didn'= t understand (from current discussions) that there is an ongoing call on consensus for video MTI codec. There are still three days left that can prevent negative reactions later.

Daniel


On 16/12/14 21:03, Richard Barnes wrote:
<hat type=3D"AD" subtype=3D"proces= s-steward"/>

Hi Daniel,

Thanks for the question.=C2=A0 The goal of Sean's message is = indeed to seek consensus on the codec question.=C2=A0 The time for discussion is to allow for any other issues to be raised, beyond those that were raised in the room in Honolulu.=C2=A0 At t= he end of the comment period on Friday, Sean will review the discussion and make a determination as to whether a rough consensus has been reached.

--Richard


On Tue, Dec 16, 2014 at 2:39 PM, Daniel-Constantin Mierla <miconda@gmail.com> wrote= :
With many forks of the thread and various opinions, can anyone clarify the expectation of these discussions. Ideally will be the WG chairs
stating what is the role of the current discussions, specially to the
initial thread with the subject 'confirming sense of the room: mti
codec' started by Sean Turner - link to archive:

=C2=A0 =C2=A0- http://www.ietf.org/mail-ar= chive/web/rtcweb/current/msg13696.html

My understanding was that it is about clarifying what happened during
the sessions in Honolulu, not a call on consensus for the proposal. I
get the feeling that many understood it differently, being the call on
consensus for video MTI codecs. I saw many people simply stating there
position in replies to this thread, which is ok if they want to
say/reiterate it, but not addressing any of the points set for
discussion by Sean.

For a call on consensus I would expect to be with a explicit subject,
including or pointing to the (draft of) text to be adopted.

Which side got it wrong here?

Thanks,
Daniel

--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

_______________________________________________
rtcweb mailing list
rtcweb= @ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--=20
Daniel-Constantin Mierla
http://twitter.=
com/#!/miconda - http://www.linkedin.com/in/miconda
--089e011615f299f052050a5cd407-- From nobody Tue Dec 16 14:30:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8271A0049 for ; Tue, 16 Dec 2014 14:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2ZO-SMCi8oy for ; Tue, 16 Dec 2014 14:30:12 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11091A004C for ; Tue, 16 Dec 2014 14:30:11 -0800 (PST) Received: by mail-qg0-f49.google.com with SMTP id a108so10789492qge.8 for ; Tue, 16 Dec 2014 14:30:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P+OBCnbRYy3M18UPXY1Qry3L9agnTOcVbIYUAO/k5K8=; b=S2yNBkjowy1Cy1hafdJfVa5V5/Xsg/X7PL/pNhRHkH6aZq/ckgGlTfqeweCHjs6iDH 8nhG+VnFhG/djVdvMOO4VukRiB3v1VD0pwgIBwi/gUcKUtJAhMqAFUm8iBecrpdqlfI1 AmyStq0l15+iiCFWXm68RR2y3Euf3T3u5vA6nQ/bUir1WMQfG0NXYn18WiUpiLTZfJkf Y2J5+K6cZtp3ZtR9v8kzVqVZl47aA1lL8hCP6DUiHfSUbWeTahbG8smZOb8BaxlNfsfT 9l9N5z/Wpj4JjpdrEirLndzZ76Xy+lG7WobSDJYKo/LyIars9CAozAghLMxOCKaxwwJn 5H9Q== X-Received: by 10.140.88.197 with SMTP id t63mr14568355qgd.72.1418769011059; Tue, 16 Dec 2014 14:30:11 -0800 (PST) Received: from [172.31.98.85] ([50.244.156.11]) by mx.google.com with ESMTPSA id 73sm2114464qgt.42.2014.12.16.14.30.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 14:30:09 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12B440) In-Reply-To: Date: Tue, 16 Dec 2014 17:30:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <228CCD7E-143B-4ACA-9730-D3D6BB07694A@gmail.com> References: <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <54905132.40105@alvestrand.no> <5B1166AB-A2EA-4F83-ABB2-8947D044B159@apple.com> <54909198.7040409@nostrum.com> To: "" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ATsYkBw_bVKXXPhwdDJ3HUrmmRQ Subject: Re: [rtcweb] revisiting why WebRTC is succeeding everywhere but the Web X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 22:30:16 -0000 On Dec 16, 2014, at 3:18 PM, David Singer wrote: >=20 > no, quite the reverse. If all browsers are also devices, then we only nee= d to state the requirements for browsers if they differ from devices, and th= ey don=E2=80=99t, do they? [BA] Let us get real. The idea that codecs are holding back WebRTC web site= development is entirely bogus.=20 Today developers are building WebRTC mobile apps that interoperate across pl= atforms, based on a codec chosen by the developer. This works well enough th= at there are at least half a dozen major apps, each serving (tens? hundreds?= ) of millions of users.=20 What we have NOT seen is a comparable blossoming of Web sites based on WebRT= C. Clearly this cannot have to do with codecs because both WebRTC-enabled br= owsers support a common codec. So at present, a developer can build a mobile= app and web site using VP8 that interoperates. Yet that has not been enough. It doesn't take a genius to figure out why. Th= e IETF RTCWEB protocols are relatively mature (with the exception of new stu= ff like ICE mobility) since they are mostly based on RFCs that were already i= mplemented in working open source prior to WebRTC. So give a mobile develope= r open source code that works and they will figure out the APIs and what fix= es/customizations they need to make it work.=20 However the browser model is very different. The browser app developer typic= ally cannot compile their own browser or fix browser bugs so they have to li= ve with what is there. Today's polyfills typically only work for audio so wr= iting a multi-browser video app that supports multiple video streams is a ni= ghtmare even without a codec problem.=20 Imposing a dual MTI requirement will not solve this problem and in fact is l= ikely to make it worse, because I fully expect that video capabilities will d= iffer markedly between implementations. So today with the same codec we see b= rowsers differ in multi stream, simulcast and SVC capabilities. =46rom these= three dimensions, adding more codecs is likely to add to the dimensions of d= ifference on several more dimensions. Care to guess how much more time it wi= ll take to polyfill all the *new* differences? From nobody Tue Dec 16 14:33:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854BC1A8865 for ; Tue, 16 Dec 2014 14:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIiRJnR-rLZ2 for ; Tue, 16 Dec 2014 14:33:37 -0800 (PST) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08BA31A876B for ; Tue, 16 Dec 2014 14:33:37 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id dc16so307970qab.23 for ; Tue, 16 Dec 2014 14:33:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kKSEwK7X/pZEI2xRLIkVWjreAjzsFzdSuBG3qwUSaSM=; b=CUXPmXiToDJFnza3UepxNh4RYRm2RrZz30NjDjmV6zXZ4XtGkQwbqTTgEFTRx98t8V 5nm5dH57DQSK2PTiADBOP70QQ3q9kXaD6HpQwYqQrgOLho4jQpf6GDUhx+46ByeJ9gdC V/94DmJxbdD8gUnMqVo/kfJTTXqi9mVNcwVx5nKtdhDNvAz5YiaO9ksCm33kqeunvv59 wnqEg4kXmfC8n9je2H8TUkgPUsFLjMMK5O/5q1zCtIVOEQaqXc6n4vt4tr9s3aEW1Oq+ 3p22pl1PmmVeZ2dea9xClKaiK9uDfh66JuSqwiPfuhkzZij36/ArIOWsER0hE0MJqAgt BWbg== X-Received: by 10.140.95.225 with SMTP id i88mr6264914qge.2.1418769215978; Tue, 16 Dec 2014 14:33:35 -0800 (PST) Received: from [172.31.98.85] ([50.244.156.11]) by mx.google.com with ESMTPSA id k6sm2126333qaz.41.2014.12.16.14.33.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 14:33:34 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12B440) In-Reply-To: <55E22C2A-EB8A-4296-A33D-A0DC10373D02@phonefromhere.com> Date: Tue, 16 Dec 2014 17:33:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <38A5EC44-7F70-4E6B-AF46-AFED895C21C3@gmail.com> References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> <92D0D52F3A63344CA478CF12DB0648AADF363463@XMB111CNC.rim.net> <949EF20990823C4C85C18D59AA11AD8B296427@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55E22C2A-EB8A-4296-A33D-A0DC10373D02@phonefromhere.com> To: tim panton Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bB1-C3qKrMCaxldJ26h_EUibYYw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 22:33:38 -0000 On Dec 16, 2014, at 4:52 PM, tim panton wrote: >=20 > When does the H264/VP8 IPR expire? It is clear this discussion will be kep= t going around in circles =E2=80=98till then. [BA] Oh my. Aren't you the optimist? I fully expect the debate to continue b= eyond that point because by then we will have moved on to a debate about nex= t generation MTI and how soon we can expire the existing proposal (assuming i= t isn't OBE).= From nobody Tue Dec 16 14:34:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF411A008D for ; Tue, 16 Dec 2014 14:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sT0xIUA4f7WP for ; Tue, 16 Dec 2014 14:34:54 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7DF1A007B for ; Tue, 16 Dec 2014 14:34:54 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBGMYopW087431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2014 16:34:51 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <5490B38A.3030001@nostrum.com> Date: Tue, 16 Dec 2014 16:34:50 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Bernard Aboba , "" References: <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <54905132.40105@alvestrand.no> <5B1166AB-A2EA-4F83-ABB2-8947D044B159@apple.com> <54909198.7040409@nostrum.com> <228CCD7E-143B-4ACA-9730-D3D6BB07694A@gmail.com> In-Reply-To: <228CCD7E-143B-4ACA-9730-D3D6BB07694A@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6Eno3P9VjeRv-g2rscIfxTwB7DQ Subject: Re: [rtcweb] revisiting why WebRTC is succeeding everywhere but the Web X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 22:34:56 -0000 On 12/16/14 16:30, Bernard Aboba wrote: > Today's polyfills typically only work for audio... What are you talking about? /a From nobody Tue Dec 16 14:39:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD721A0084 for ; Tue, 16 Dec 2014 14:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFA10FbDfV8F for ; Tue, 16 Dec 2014 14:39:06 -0800 (PST) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00571A00A2 for ; Tue, 16 Dec 2014 14:39:06 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id i8so11034880qcq.39 for ; Tue, 16 Dec 2014 14:39:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ms4NDcMUmfizghITK5/Lbk6bXRQC7WIRN7qG/cM+B/4=; b=H3szoQ7lVtPGNTGGOW30FWdG9pbpEhcgZl9Q+4bGGfK6QrGyXoZmHAISJswygzYY3A p9+XX/7R74UYtfZGo7+vyID9wyEppNsFpbPFLESyPDaNz8WwINtqzEtoK3GGbw/7NMZn WkTowLtCdop/zL47uNJkgCZ1suETPSZ1WTjfZiJuFq/i675zBBExizYx/bkO9h1pQU2b d0T0xPwKGYt7Lmt9AXHfjzt00gpHIi1SbF5cOhPI7ebA5QuHcg7FQ5z6VLeUH3lVaRgp LIggmcI5y3Gsba6UjIq6OKWF0XTH/ePhoGUK5NTOcgux13de1jNoMGFU6gX5eoOYy9WI pwhQ== X-Received: by 10.224.169.2 with SMTP id w2mr69486145qay.33.1418769545882; Tue, 16 Dec 2014 14:39:05 -0800 (PST) Received: from [172.31.98.85] ([50.244.156.11]) by mx.google.com with ESMTPSA id b39sm448175qge.10.2014.12.16.14.39.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 14:39:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12B440) In-Reply-To: <5490B38A.3030001@nostrum.com> Date: Tue, 16 Dec 2014 17:39:04 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <54905132.40105@alvestrand.no> <5B1166AB-A2EA-4F83-ABB2-8947D044B159@apple.com> <54909198.7040409@nostrum.com> <228CCD7E-143B-4ACA-9730-D3D6BB07694A@gmail.com> <5490B38A.3030001@nostrum.com> To: Adam Roach Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xIcb_p4iOLag2nouIdUgc83EgxM Cc: "" Subject: Re: [rtcweb] revisiting why WebRTC is succeeding everywhere but the Web X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 22:39:08 -0000 Show me a polyfill that works for multi-stream video. > On Dec 16, 2014, at 5:34 PM, Adam Roach wrote: > >> On 12/16/14 16:30, Bernard Aboba wrote: >> Today's polyfills typically only work for audio... > > What are you talking about? > > /a From nobody Tue Dec 16 14:43:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384B41A008F for ; Tue, 16 Dec 2014 14:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7X4MZwVn56xT for ; Tue, 16 Dec 2014 14:43:53 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB5621A00B1 for ; Tue, 16 Dec 2014 14:43:52 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id tr6so13927852ieb.17 for ; Tue, 16 Dec 2014 14:43:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NrpeHWdmAnV/fD4lZMXZ3SekgpJ97l3tosrf8LB92jA=; b=Bdu2gyV/mYLMsLwczw4XxsyOb9rfc2Kd8SHnJkXBNxPxy0t8qSu+XcT753ImBW4nWK aajX1EjPER30KWKrlZbpVwWAmdrZps6hu0Co9Vnf1KMgsJZJj0fB0I3/JTbZ1ri8KOhL zZQ7xY/0f2Boy8hQ9P5jXBmMqFVa74I3fdRpFnN6xngZUrzTUn183ReenKpM1TCpMZ1r 1OzyYvmYs6XrSkftTpAl9YWvt9ruv3sFOsBiVb+0EMNMOr2IV6EYwpywCCEvlLyp8srK Qn6QSjJhwGycK8nFtzrIJ9J5NYgpF19vxqJ1Ve394eSHsrRiw1BHHNnyFVs+Sxp9nAfg hM2Q== MIME-Version: 1.0 X-Received: by 10.107.138.131 with SMTP id c3mr37379591ioj.0.1418769831780; Tue, 16 Dec 2014 14:43:51 -0800 (PST) Received: by 10.42.107.145 with HTTP; Tue, 16 Dec 2014 14:43:51 -0800 (PST) In-Reply-To: <228CCD7E-143B-4ACA-9730-D3D6BB07694A@gmail.com> References: <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <54905132.40105@alvestrand.no> <5B1166AB-A2EA-4F83-ABB2-8947D044B159@apple.com> <54909198.7040409@nostrum.com> <228CCD7E-143B-4ACA-9730-D3D6BB07694A@gmail.com> Date: Tue, 16 Dec 2014 14:43:51 -0800 Message-ID: From: Ted Hardie To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a113e9864d76830050a5d1783 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/04bqVZAJJPSQfAk3OHjuYpadoO8 Cc: "" Subject: Re: [rtcweb] revisiting why WebRTC is succeeding everywhere but the Web X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 22:43:55 -0000 --001a113e9864d76830050a5d1783 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 16, 2014 at 2:30 PM, Bernard Aboba wrote: > On Dec 16, 2014, at 3:18 PM, David Singer wrote: > > However the browser model is very different. The browser app developer > typically cannot compile their own browser or fix browser bugs so they ha= ve > to live with what is there. Today's polyfills typically only work for aud= io > so writing a multi-browser video app that supports multiple video streams > is a nightmare even without a codec problem. > > =E2=80=8BSo, can I confirm here that you mean polyfill in the same way =E2= =80=8BRemy Sharp did? That is, a piece of Javascript that replicates an API and functionality that the browser lacks? And so you are asserting that there are downloadable Javascript bits that replicate both the audio functionality and relevant API, but there are no downloadable Javascript bits that replicate the video functionality and relevant API? Have I gotten your meaning? Ted --001a113e9864d76830050a5d1783 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Dec 16, 2014 at 2:30 PM= , Bernard Aboba <bernard.aboba@gmail.com> wrote:
On Dec 16, 2014, at 3:1= 8 PM, David Singer <singer@apple.com= > wrote:

However the browser model is very different. The browser app developer typi= cally cannot compile their own browser or fix browser bugs so they have to = live with what is there. Today's polyfills typically only work for audi= o so writing a multi-browser video app that supports multiple video streams= is a nightmare even without a codec problem.

=C2=A0
=E2=80=8BSo, can I confirm here t= hat you mean polyfill in the same way =E2=80=8BRemy Sharp did?=C2=A0 That i= s, a piece of Javascript that replicates an API and functionality that the = browser lacks?

And so you are asserting that there a= re downloadable Javascript bits that replicate both the audio functionality= and relevant API, but there are no downloadable Javascript bits that repli= cate the video functionality and relevant API?

Have = I gotten your meaning?

Ted

=
--001a113e9864d76830050a5d1783-- From nobody Tue Dec 16 14:44:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7313D1A00B9 for ; Tue, 16 Dec 2014 14:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMFlmHRnyStl for ; Tue, 16 Dec 2014 14:44:17 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74091A00B7 for ; Tue, 16 Dec 2014 14:44:16 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id x12so18586200wgg.11 for ; Tue, 16 Dec 2014 14:44:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gO2/xu+xofqrr/tcmNTKVg9uCofwPvwZvHJVwQhno4c=; b=Ok/H6NWvNmOYs/9d5wqHak8zFhxAekXGEtTou1m2GVejJ+NJ8isd2X0V1uJPhLs9lB Kib33qsNblbxqZZbdyqjPcwGTE7BP+CIcivIjFzAml4Qcc/ToOO+0KBGMuLFDL+Wnn4B IZFMN6EUD3TVcGqNpBDd0+qMOW9ceJWU5Uhbg+I6eX2b3RhHYgahsEIPHti614ZmikfZ liI7JUf6WrvIE5GSWsqxNryyurAV52rowe8T4C+fc1hWLnjXrLu/YG+WqUIfkEbKG1Wv 3YrUZ7VaREdMEJ4gRMuRs0IS04U1I5TNkyICA9zQu32Bw7ZCc8pCRgtrZ/N6VG1dr5ZF hOXw== X-Gm-Message-State: ALoCoQnksCgkX0fU0cpqvv8qmoBwlK82pPW53CVT0MLEFQJiPzasvDvkairozpGiNoTjhFn1syLA X-Received: by 10.194.184.199 with SMTP id ew7mr67300187wjc.85.1418769855443; Tue, 16 Dec 2014 14:44:15 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com. [74.125.82.53]) by mx.google.com with ESMTPSA id ex9sm18598210wib.14.2014.12.16.14.44.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 14:44:14 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id l18so18627212wgh.40 for ; Tue, 16 Dec 2014 14:44:14 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.2.75 with SMTP id 11mr54945569wjs.78.1418769854278; Tue, 16 Dec 2014 14:44:14 -0800 (PST) Received: by 10.217.191.202 with HTTP; Tue, 16 Dec 2014 14:44:14 -0800 (PST) In-Reply-To: <38A5EC44-7F70-4E6B-AF46-AFED895C21C3@gmail.com> References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> <92D0D52F3A63344CA478CF12DB0648AADF363463@XMB111CNC.rim.net> <949EF20990823C4C85C18D59AA11AD8B296427@FR712WXCHMBA11.zeu.alcatel-lucent.com> <55E22C2A-EB8A-4296-A33D-A0DC10373D02@phonefromhere.com> <38A5EC44-7F70-4E6B-AF46-AFED895C21C3@gmail.com> Date: Tue, 16 Dec 2014 17:44:14 -0500 Message-ID: From: Roman Shpount To: Bernard Aboba Content-Type: multipart/alternative; boundary=047d7b3a834c2eb466050a5d1959 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lq8PC22qJPyLnHyuPCy_lC4DFZo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 22:44:18 -0000 --047d7b3a834c2eb466050a5d1959 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 16, 2014 at 5:33 PM, Bernard Aboba wrote: > > On Dec 16, 2014, at 4:52 PM, tim panton wrote: > > > > When does the H264/VP8 IPR expire? It is clear this discussion will be > kept going around in circles =E2=80=98till then. > > [BA] Oh my. Aren't you the optimist? I fully expect the debate to continu= e > beyond that point because by then we will have moved on to a debate about > next generation MTI and how soon we can expire the existing proposal > (assuming it isn't OBE). > > The way it goes we would be discussing remote holographic presence before this issue is resolved. _____________ Roman Shpount --047d7b3a834c2eb466050a5d1959 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 16, 2014 at 5:33 PM, Bernard Aboba <bernard.aboba@gmail.com<= /a>> wrote:
On Dec 16, 2014, at = 4:52 PM, tim panton <tim@phonef= romhere.com> wrote:
>
> When does the H264/VP8 IPR expire? It is clear this discussion will be= kept going around in circles =E2=80=98till then.

[BA] Oh my. Aren't you the optimist? I fully expect the debate t= o continue beyond that point because by then we will have moved on to a deb= ate about next generation MTI and how soon we can expire the existing propo= sal (assuming it isn't OBE).

=C2=A0<= /div>
The way it goes we would be discussing remote holographic presenc= e before this issue is resolved.=C2=A0
_____________
Roman Shpount
=C2=A0
--047d7b3a834c2eb466050a5d1959-- From nobody Tue Dec 16 15:08:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB961A010D for ; Tue, 16 Dec 2014 15:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4TfsVgcv_Is for ; Tue, 16 Dec 2014 15:08:02 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE1C1A0104 for ; Tue, 16 Dec 2014 15:08:02 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so2564629wgh.1 for ; Tue, 16 Dec 2014 15:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=9/cDnjynrCER3aeVWwH41R15cfczYrxtvkXxx7E/SdA=; b=t8tv6wRcaPBPHc/xbfgzKOxjWRLBfas7rw9uBI14+LBAXK8j01JeVKupucMjO2cTuz p1E/Lh0kBVPxTlXykIgnFzXQ1P73MyAW5GAVbCJDnrmBriUuxQcalHOg3xF01jzsnDCg LwpRx5NbQXt95P349aBm6da1WpkNbSmGMph6ESGK7E9KGN/Pkt+qiDzLcZ2PRJUDPO+Z e3x0l8afGDAvDGatFL6AnGpoGjgtq9AEOAdgrm+o96JxDeGJCvACLon81kz9hAbs3mWp bWQQvBmekAOBARkwCoKRfJehZ7WqRUg+YFV+m6Vv9hgEMWvBJL3oenUWU+eaRjfp6zGl 1RcA== X-Received: by 10.180.9.111 with SMTP id y15mr8492174wia.33.1418771280849; Tue, 16 Dec 2014 15:08:00 -0800 (PST) Received: from Saturns-MBP.fritz.box ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id vm8sm2833767wjc.6.2014.12.16.15.07.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Dec 2014 15:08:00 -0800 (PST) Message-ID: <5490BB4E.1020907@gmail.com> Date: Wed, 17 Dec 2014 00:07:58 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Richard Barnes References: <54908A65.1010705@gmail.com> <54909562.7060504@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030206080507000106050008" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sSxfYBI8K783zHL8ASVXrVrdQZU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] clarifications on current discussions - re: confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.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, 16 Dec 2014 23:08:05 -0000 This is a multi-part message in MIME format. --------------030206080507000106050008 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Richard, comments inline. On 16/12/14 23:25, Richard Barnes wrote: > Hey Daniel, > > I think Sean's original message was pretty clear about this: > """ > After the discussion, some clarifying questions about the hums, and > typing the hum questions on the screen, there was rough consensus in > the room to add (aka “shoveâ€) the proposed text into > draft-ietf-rtcweb-video. In keeping with IETF process, I am > confirming this consensus call on the list. > """ > Maybe the sequence of the events combined with rather sophisticated presentation (of what might have been expected as a simple, direct call to vote yes or no) has compromised the intended goal of the message for some people (or maybe only for me). I got it as being the presentation of what happened on site in Honolulu for the video MTI codec session, with the confirmation of chairs that there was a consensus call in the room for that specific proposal, resulting in a rough consensus, in the spirit that what happens on site is summarized 'officially' on mailing list. At the same time being a very active discussion on 'shoving' the proposed text, I thought that it needs to be done first (rise issues about & discuss up to Dec 19) and afterwards an explicit call on consensus with 'shoved' text. > Nonetheless, if you think people have missed this point, feel free to > prompt them to comment in that thread. OK. Thanks, Daniel > > Thanks, > --Richard > > > > On Tue, Dec 16, 2014 at 3:26 PM, Daniel-Constantin Mierla > > wrote: > > Hi Richard, > > thanks for the clarification! IMO, the initial message content was > not stating explicitly this is the goal and apparently it misled > the expectation from some of us. > > Maybe it would be appropriate to have a fresh message sent by WG > chairs/AD (or other IETF 'official' involved in the process) to > say it explicitly by subject, just in case someone (else than me) > didn't understand (from current discussions) that there is an > ongoing call on consensus for video MTI codec. There are still > three days left that can prevent negative reactions later. > > Daniel > > > On 16/12/14 21:03, Richard Barnes wrote: >> >> >> Hi Daniel, >> >> Thanks for the question. The goal of Sean's message is indeed to >> seek consensus on the codec question. The time for discussion is >> to allow for any other issues to be raised, beyond those that >> were raised in the room in Honolulu. At the end of the comment >> period on Friday, Sean will review the discussion and make a >> determination as to whether a rough consensus has been reached. >> >> --Richard >> >> >> On Tue, Dec 16, 2014 at 2:39 PM, Daniel-Constantin Mierla >> > wrote: >> >> With many forks of the thread and various opinions, can >> anyone clarify >> the expectation of these discussions. Ideally will be the WG >> chairs >> stating what is the role of the current discussions, >> specially to the >> initial thread with the subject 'confirming sense of the >> room: mti >> codec' started by Sean Turner - link to archive: >> >> - >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html >> >> My understanding was that it is about clarifying what >> happened during >> the sessions in Honolulu, not a call on consensus for the >> proposal. I >> get the feeling that many understood it differently, being >> the call on >> consensus for video MTI codecs. I saw many people simply >> stating there >> position in replies to this thread, which is ok if they want to >> say/reiterate it, but not addressing any of the points set for >> discussion by Sean. >> >> For a call on consensus I would expect to be with a explicit >> subject, >> including or pointing to the (draft of) text to be adopted. >> >> Which side got it wrong here? >> >> Thanks, >> Daniel >> >> -- >> Daniel-Constantin Mierla >> http://twitter.com/#!/miconda >> - >> http://www.linkedin.com/in/miconda >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > -- > Daniel-Constantin Mierla > http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda > -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda --------------030206080507000106050008 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Richard,

comments inline.

On 16/12/14 23:25, Richard Barnes wrote:
Hey Daniel,

I think Sean's original message was pretty clear about this:
"""
After the discussion, some clarifying questions about the hums, and typing the hum questions on the screen, there was rough consensus in the room to add (aka “shoveâ€) the proposed text into draft-ietf-rtcweb-video.  In keeping with IETF process, I am confirming this consensus call on the list.
"""


Maybe the sequence of the events combined with rather sophisticated presentation (of what might have been expected as a simple, direct call to vote yes or no) has compromised the intended goal of the message for some people (or maybe only for me).

I got it as being the presentation of what happened on site in Honolulu for the video MTI codec session, with the confirmation of chairs that there was a consensus call in the room for that specific proposal, resulting in a rough consensus, in the spirit that what happens on site is summarized 'officially' on mailing list. At the same time being a very active discussion on 'shoving' the proposed text, I thought that it needs to be done first (rise issues about & discuss up to Dec 19) and afterwards an explicit call on consensus with 'shoved' text.

Nonetheless, if you think people have missed this point, feel free to prompt them to comment in that thread.

OK.

Thanks,
Daniel


Thanks,
--Richard



On Tue, Dec 16, 2014 at 3:26 PM, Daniel-Constantin Mierla <miconda@gmail.com> wrote:
Hi Richard,

thanks for the clarification! IMO, the initial message content was not stating explicitly this is the goal and apparently it misled the expectation from some of us.

Maybe it would be appropriate to have a fresh message sent by WG chairs/AD (or other IETF 'official' involved in the process) to say it explicitly by subject, just in case someone (else than me) didn't understand (from current discussions) that there is an ongoing call on consensus for video MTI codec. There are still three days left that can prevent negative reactions later.

Daniel


On 16/12/14 21:03, Richard Barnes wrote:
<hat type="AD" subtype="process-steward"/>

Hi Daniel,

Thanks for the question.  The goal of Sean's message is indeed to seek consensus on the codec question.  The time for discussion is to allow for any other issues to be raised, beyond those that were raised in the room in Honolulu.  At the end of the comment period on Friday, Sean will review the discussion and make a determination as to whether a rough consensus has been reached.

--Richard


On Tue, Dec 16, 2014 at 2:39 PM, Daniel-Constantin Mierla <miconda@gmail.com> wrote:
With many forks of the thread and various opinions, can anyone clarify
the expectation of these discussions. Ideally will be the WG chairs
stating what is the role of the current discussions, specially to the
initial thread with the subject 'confirming sense of the room: mti
codec' started by Sean Turner - link to archive:

   - http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html

My understanding was that it is about clarifying what happened during
the sessions in Honolulu, not a call on consensus for the proposal. I
get the feeling that many understood it differently, being the call on
consensus for video MTI codecs. I saw many people simply stating there
position in replies to this thread, which is ok if they want to
say/reiterate it, but not addressing any of the points set for
discussion by Sean.

For a call on consensus I would expect to be with a explicit subject,
including or pointing to the (draft of) text to be adopted.

Which side got it wrong here?

Thanks,
Daniel

--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
--------------030206080507000106050008-- From nobody Tue Dec 16 15:23:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459711A017C for ; Tue, 16 Dec 2014 15:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FH794nkzmoXE for ; Tue, 16 Dec 2014 15:23:24 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D2711A0177 for ; Tue, 16 Dec 2014 15:23:24 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so2586729wgh.1 for ; Tue, 16 Dec 2014 15:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=H5LE9keDHZhx2nt8bbn2ytbjfojXlYukLk6JQXdj4mo=; b=rgYkg4dqkG0aIvlrhqe5B6qD9xaD1XnavV5mrDmjgrzBdlzM1grcoCOgwLK6VThdTB GwWxdGQHSi2NKlFLm7mJoHjYlq/WX7Kwq/6EfhHz7qeJreF97k77BN8FdL+/hy8cFKV8 +7/JDj5tM+vJl0ipx9ngpX7L1Oq118Ftvu7TBHhzBimN/FkIuPyeFBoXv49k1cIFjfzZ crfD/QwQLUz0r5Fx5zuWYBnPlWbfEq0kW/jPMqYY0tbnD71so1qspxZK6J2DelrhcpT1 cRJUUd6acm4FdOxcQD5Cy51DpEGELr8Alikf/739YRTyAX/xoIMmKY++TfhQBkUtl/yI uZsA== X-Received: by 10.194.59.234 with SMTP id c10mr55946125wjr.49.1418772202775; Tue, 16 Dec 2014 15:23:22 -0800 (PST) Received: from Saturns-MBP.fritz.box ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id ud4sm8857324wib.0.2014.12.16.15.23.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Dec 2014 15:23:21 -0800 (PST) Message-ID: <5490BEE8.1020905@gmail.com> Date: Wed, 17 Dec 2014 00:23:20 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wKF1RnYWd0PgrRHEYVrYJcPKVWM Subject: [rtcweb] Reminder: consensus call on a MTI video codec proposal by December 19, 2014 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.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, 16 Dec 2014 23:23:26 -0000 If for what so ever reason you missed the consensus call on MTI video codec, note that the process is ending by December 19, 2014 (more or less 3 days from now). The proposal is incorporated in the draft: - https://tools.ietf.org/html/draft-ietf-rtcweb-video-03 For further details, see the initial message for consensus call: - http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html If you are interested in the topic and want to state your vote for the proposal or against it, reply to the mailing list within that discussion thread (having the subject: "confirming sense of the room: mti codec"). Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From nobody Tue Dec 16 15:32:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A0C1A0373 for ; Tue, 16 Dec 2014 15:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ie-cp04sdPV for ; Tue, 16 Dec 2014 15:32:50 -0800 (PST) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63EE1A0367 for ; Tue, 16 Dec 2014 15:32:49 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id r5so11115791qcx.2 for ; Tue, 16 Dec 2014 15:32:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jpCUAGWfdXLP0M4I/MhDi8Df+UtgGOY+Yjg2bF/prMs=; b=p0NW0idXUiFl4XLBmtbZLHginB60lgsJBx/mTwZ1Oo+3xfLUdklUiI9z0HKBS1X3Xg cqQFEs9OiKBl/Sq3obPh+8IQIAQO74OwVWzrMCE4lqhs/wR/nl7DY4V1OeeVJRtWwFcR oWglDI+5uTBnWxEb17sGgfb1f1GaiA8fifDQax7SaoWRTQKKV+Sl8dvHI3M6QJgCNBNU S/N2c41GeeLBCLhM2xlN8EJ26OSuuCrVr+IMSmZly1uSfEJLfypEEAQ5hDo0c7BDjkX2 2gRr8k0ozi0cuhqsGe/VXOqNiyq9aJA2GiAkpBXPWwbpurI3sHQwUyB0//Qkfj2zePxQ 5eOQ== X-Received: by 10.224.56.3 with SMTP id w3mr72028469qag.51.1418772768888; Tue, 16 Dec 2014 15:32:48 -0800 (PST) Received: from [172.31.98.85] ([50.244.156.11]) by mx.google.com with ESMTPSA id y10sm2008600qad.23.2014.12.16.15.32.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 15:32:47 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-3A404D70-7FC7-4248-8779-352F24586739 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12B440) In-Reply-To: Date: Tue, 16 Dec 2014 18:32:47 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <54905132.40105@alvestrand.no> <5B1166AB-A2EA-4F83-ABB2-8947D044B159@apple.com> <54909198.7040409@nostrum.com> <228CCD7E-143B-4ACA-9730-D3D6BB07694A@gmail.com> To: Ted Hardie Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9v-Od3sYezNrq5gMDeuGatURxXI Cc: "" Subject: Re: [rtcweb] revisiting why WebRTC is succeeding everywhere but the Web X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 23:32:53 -0000 --Apple-Mail-3A404D70-7FC7-4248-8779-352F24586739 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It is possible to write a single stream audio/video app that runs on any bro= wser. But if you include the video features that enable collaborative Web a= pps like Skype for Web, Hangouts, Jitsi Meet, etc. then yes there are no pol= yfills today. So these Web apps need to be written for a particular browser= . By now people are getting used to installing a browser to run their favor= ite WebRTC web app. That's not the IETF's problem really (WebRTC protocols a= nd open source SDKs implementing same are in much better shape, and are bein= g widely used). But it is indicative of the mountain that WebRTC needs to be= climb to be a successful Web standard.=20 > On Dec 16, 2014, at 5:43 PM, Ted Hardie wrote: >=20 >> On Tue, Dec 16, 2014 at 2:30 PM, Bernard Aboba w= rote: >> On Dec 16, 2014, at 3:18 PM, David Singer wrote: >>=20 >> However the browser model is very different. The browser app developer ty= pically cannot compile their own browser or fix browser bugs so they have to= live with what is there. Today's polyfills typically only work for audio so= writing a multi-browser video app that supports multiple video streams is a= nightmare even without a codec problem. > =20 > =E2=80=8BSo, can I confirm here that you mean polyfill in the same way =E2= =80=8BRemy Sharp did? That is, a piece of Javascript that replicates an API= and functionality that the browser lacks? >=20 > And so you are asserting that there are downloadable Javascript bits that r= eplicate both the audio functionality and relevant API, but there are no dow= nloadable Javascript bits that replicate the video functionality and relevan= t API? >=20 > Have I gotten your meaning? >=20 > Ted >=20 --Apple-Mail-3A404D70-7FC7-4248-8779-352F24586739 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
It is possible to write a single strea= m audio/video app that runs on any browser.  But if you include the vid= eo features that enable collaborative Web apps like Skype for Web, Hangouts,= Jitsi Meet, etc. then yes there are no polyfills today.  So these Web a= pps need to be written for a particular browser.  By now people are get= ting used to installing a browser to run their favorite WebRTC web app. That= 's not the IETF's problem really (WebRTC protocols and open source SDKs impl= ementing same are in much better shape, and are being widely used). But it i= s indicative of the mountain that WebRTC needs to be climb to be a successfu= l Web standard. 

On Dec 16, 2014, at 5:43 PM, Ted Hardie &= lt;ted.ietf@gmail.com> wrote:
On Tue, Dec 16, 2014 at 2:30 PM, Bernard Aboba = <bernard.abo= ba@gmail.com> wrote:
On Dec 16, 2014, at 3:18 PM, David Singer <singer@apple.com> wrote:

However the browser model is very different. The browser app developer typic= ally cannot compile their own browser or fix browser bugs so they have to li= ve with what is there. Today's polyfills typically only work for audio so wr= iting a multi-browser video app that supports multiple video streams is a ni= ghtmare even without a codec problem.

 
=E2=80=8BSo, can I confirm here tha= t you mean polyfill in the same way =E2=80=8BRemy Sharp did?  That is, a= piece of Javascript that replicates an API and functionality that the brows= er lacks?

And so you are asserting that there are down= loadable Javascript bits that replicate both the audio functionality and rel= evant API, but there are no downloadable Javascript bits that replicate the v= ideo functionality and relevant API?

Have I gotten you= r meaning?

Ted

= --Apple-Mail-3A404D70-7FC7-4248-8779-352F24586739-- From nobody Tue Dec 16 16:15:48 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE7B1A0397 for ; Tue, 16 Dec 2014 16:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUj0SHcKqH13 for ; Tue, 16 Dec 2014 16:15:42 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F4E1A026F for ; Tue, 16 Dec 2014 16:15:42 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so13982589wiv.11 for ; Tue, 16 Dec 2014 16:15:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4FPE1thhAKj+aJYzyR/fiWSxTrHOiHNRQiV3/JRw7xA=; b=hXNNcdosqVjNSuP8n9PeWMrnomqGXWSCIMS6/TS1Ooluw4vCNR8QWM79KkyOnjXPE0 9MHcA08Ms3y9nBRZTxic3Vnyj7KJizuAaIJd4BZkqwNrI2H6oNZ9QGgqe/bK79vjFShs pfn0L8NFuTkWc4LubMBAGFGs96iRVXjHcjhflX3ruokUKbaWBGwXMHASySdQqh9kMSGD WZzDzC5r7rk70p0GURWWzCo7LAwzaMhEREuR1w4YAnG4dJ4cUfWB/HNQmbu8sOg8i9S2 AmFWdZ+FBJt6Ra3ZNn2MVOWbOZh8o/9YvIS6hht25lOVghsLCnHsm3dtEPcUYsRWJ3d/ Jz9g== X-Received: by 10.180.97.7 with SMTP id dw7mr5741449wib.6.1418775341242; Tue, 16 Dec 2014 16:15:41 -0800 (PST) Received: from Saturns-MBP.fritz.box ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id ce1sm2988488wjc.2.2014.12.16.16.15.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Dec 2014 16:15:40 -0800 (PST) Message-ID: <5490CB2A.8090307@gmail.com> Date: Wed, 17 Dec 2014 01:15:38 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <5490BEE8.1020905@gmail.com> In-Reply-To: <5490BEE8.1020905@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/aEftCWDB1HsIUQuSNUqi8TFgZg0 Subject: Re: [rtcweb] Reminder: consensus call on a MTI video codec proposal by December 19, 2014 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.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, 17 Dec 2014 00:15:46 -0000 On 17/12/14 00:23, Daniel-Constantin Mierla wrote: > If for what so ever reason you missed the consensus call on MTI video > codec, note that the process is ending by December 19, 2014 (more or > less 3 days from now). > > The proposal is incorporated in the draft: > > - https://tools.ietf.org/html/draft-ietf-rtcweb-video-03 > > For further details, see the initial message for consensus call: > > - http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html > > If you are interested in the topic and want to state your vote for the > proposal or against it, reply to the mailing list within that discussion > thread (having the subject: "confirming sense of the room: mti codec"). > Although the voting was used at some point on this list in the scope of deciding the MTI video codec for Webrtc, the term 'vote' was inadequately used in my reminder, so worth amending it not to end up on side discussions about IETF procedures -- the last paragraph above should have been: """ If you are interested in the topic and want to state your _opinions_ for the proposal or against it, reply to the mailing list within that discussion thread (having the subject: "confirming sense of the room: mti codec"). """ Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From nobody Tue Dec 16 16:44:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE191A1A11 for ; Tue, 16 Dec 2014 16:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXcXWnBwQ1RW for ; Tue, 16 Dec 2014 16:44:28 -0800 (PST) Received: from relay.mailchannels.net (ar-005-i207.relay.mailchannels.net [162.253.144.89]) by ietfa.amsl.com (Postfix) with ESMTP id 4F70B1A1A06 for ; Tue, 16 Dec 2014 16:44:26 -0800 (PST) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-33-12-218.us-west-2.compute.internal [10.33.12.218]) by relay.mailchannels.net (Postfix) with ESMTPA id 5B1EB1208D9 for ; Wed, 17 Dec 2014 00:44:23 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.245.145.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.2); Wed, 17 Dec 2014 00:44:23 GMT X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1418777063644:2910515384 X-MC-Ingress-Time: 1418777063644 Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:60092 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Y12io-0002mg-9u for rtcweb@ietf.org; Tue, 16 Dec 2014 18:44:10 -0600 Message-ID: <5490D1BB.2040309@jesup.org> Date: Tue, 16 Dec 2014 19:43:39 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> <92D0D52F3A63344CA478CF12DB0648AADF363463@XMB111CNC.rim.net> <949EF20990823C4C85C18D59AA11AD8B296427@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040006010303020105090908" X-AuthUser: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hOBWBbDuQfTuZGCbAuOUfypJhZk Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 00:44:30 -0000 This is a multi-part message in MIME format. --------------040006010303020105090908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/16/2014 3:42 PM, Roman Shpount wrote: > On Tue, Dec 16, 2014 at 2:56 PM, DRAGE, Keith (Keith) > > wrote: > > As far as I am concerned an IPR free codec is irrelevant if I > cannot talk to the endpoints I need to, and just concentrating on > the webrtc community as the available endpoint may meet some > deployers use cases, but not others. > > > There is no such thing as IPR free codec, unless you are talking about > H.261 or MJPEG where IPR has expired. What we are looking for is a > video codec with an acceptable quality (both VP8 and H.264 qualify) > and reasonable licensing (both VP8 and H.264 have serious issues > here). If it is confirmed the VP8 licensing issues are resolved (i.e. > it went through the standardization process, all IPR declaration > against it which prevent licensing are confirmed to not apply in court > or due to some sort of licencing agreement), then VP8 is clearly > superior. If H.264 fixes its licensing (i.e. present a clear, > published, no royalty licensing terms with no use restrictions), it > can be a superior codec. Legacy interop support is important, but to > me at least, it is secondary to unrestricted use. Please see Opus vs > AMR-WB+ for clear similarities. +1. "IPR-free" barely would even apply to H.261 - you'd also have avoid any of the (patented) tricks on the encoding side that have shown up during later codec evolution from that - but you always *can* avoid them by basing on ancient implementations. > Also, VP9 or H.265 would clearly improve video quality, but both VP8 > and H.264 with the current connection speeds allow for the highly > usable video communications. I think that quality wise, either one of > VP8 and H.264 can serve as usable MTI for a lot longer then the next > two years or whatever time is required for the next great video codec > to be developed. Especially in another 5-6 years when all the IPR on > these codecs will expire. +1 (Well, most of the patents on the decoder side and basic non-performant encoders may expire. Patents are weird.) We have better things to do... -- Randell Jesup -- rjesup a t mozilla d o t com --------------040006010303020105090908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/16/2014 3:42 PM, Roman Shpount wrote:
On Tue, Dec 16, 2014 at 2:56 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:
As far as I am concerned an IPR free codec is irrelevant if I cannot talk to the endpoints I need to, and just concentrating on the webrtc community as the available endpoint may meet some deployers use cases, but not others.

There is no such thing as IPR free codec, unless you are talking about H.261 or MJPEG where IPR has expired. What we are looking for is a video codec with an acceptable quality (both VP8 and H.264 qualify) and reasonable licensing (both VP8 and H.264 have serious issues here). If it is confirmed the VP8 licensing issues are resolved (i.e. it went through the standardization process, all IPR declaration against it which prevent licensing are confirmed to not apply in court or due to some sort of licencing agreement), then VP8 is clearly superior. If H.264 fixes its licensing (i.e. present a clear, published, no royalty licensing terms with no use restrictions), it can be a superior codec. Legacy interop support is important, but to me at least, it is secondary to unrestricted use. Please see Opus vs AMR-WB+ for clear similarities.

+1.  "IPR-free" barely would even apply to H.261 - you'd also have avoid any of the (patented) tricks on the encoding side that have shown up during later codec evolution from that  - but you always *can* avoid them by basing on ancient implementations. 

Also, VP9 or H.265 would clearly  improve video quality, but both VP8 and H.264 with the current connection speeds allow for the highly usable video communications. I think that quality wise, either one of VP8 and H.264 can serve as usable MTI for a lot longer then the next two years or whatever time is required for the next great video codec to be developed. Especially in another 5-6 years when all the IPR on these codecs will expire.

+1 (Well, most of the patents on the decoder side and basic non-performant encoders may expire.  Patents are weird.)

We have better things to do...
-- 
Randell Jesup -- rjesup a t mozilla d o t com
--------------040006010303020105090908-- From nobody Tue Dec 16 16:56:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330821A1A1D for ; Tue, 16 Dec 2014 16:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TeGln3ykjHg for ; Tue, 16 Dec 2014 16:56:35 -0800 (PST) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BBC61A1A1B for ; Tue, 16 Dec 2014 16:56:35 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id hy4so6844155vcb.16 for ; Tue, 16 Dec 2014 16:56:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yCaYOltv5IY6n4spceedRJlsFFpVlVxwHC+62LaMF7Y=; b=kaR6kun4BPUTcamJPBiuhJowHVzct2xbuNrIqLDGa9woZDUwZKZvzvlawm/ecxOdQo 8aGf0TZMWdo8gZOwlnE8v4vy3ukuPWt2NVkFUkSAULmGRyFRkpYvHNFzIpRNM05cE87x e16WX7VWwu98F3mBnr2UVEiB29Rd8++hsxjA3IfHlg/DhYvgC4SOgHFLtO1+o5UmgzsF jnYQpjPhp0USl83f7+SDbpAIvlNBkcYTvO2jAKQ9/QE7QIsD5guFP+AIAI6MWi7CvXUX rb0nuO2MW/S/hNRLwraaBToMO/W3YUTKAt33FxIywLgYW9//wx+zIGqY4wuSpEjQV3Oq CGfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yCaYOltv5IY6n4spceedRJlsFFpVlVxwHC+62LaMF7Y=; b=aYMqjMzXhuY/AlTudddXnqrZQra9m9Hv7a/Vn+C6cqyUjSPmE1FuAH7vWRZ3ktHAeE 7B8hZaUUwR6hquQToiwA9mtbXBUB95E27oW1ozoKSITbUodrFQYjwwKZKyEON/4vtmWq Mpj5CbB7BDhelykIuSj2COkwEufjRnkTZ5HXZrXgLQYnBMzF8DLFHpCNpMsa1YEUZa0E hX79J6k0vtHPOxXTp/5SPdTx8+AoHFfYNK6lxNztEqZZHxSXnXh5UJRc6cOInIeHgK9w 3Eey6OwSGPH71giDLAqZdAlVQqqwSmcktfaQZ1OkcsRwGqgs/ORw+u7UzHQsQYxpSW+w kykg== X-Gm-Message-State: ALoCoQmkjODZy0I3rgCqdObBcSYKKRAXvYEmd0IurnpfFpfgMglV1y8LtfOjg2j2042nKmEFnJnY X-Received: by 10.220.178.3 with SMTP id bk3mr16625503vcb.16.1418777794177; Tue, 16 Dec 2014 16:56:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.10.229 with HTTP; Tue, 16 Dec 2014 16:56:13 -0800 (PST) In-Reply-To: References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E63FD67@MCHP04MSX.global-ad.net> From: Justin Uberti Date: Tue, 16 Dec 2014 16:56:13 -0800 Message-ID: To: =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Content-Type: multipart/alternative; boundary=001a11c1d370700eb4050a5ef26d Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PFaSXvddNJXJ5jE87bnLxoxDun0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 00:56:40 -0000 --001a11c1d370700eb4050a5ef26d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Seems like something that should go into -transports (i.e. that WebRTC clients SHOULD obtain a srflx address from the TURN server, in addition to any provided STUN servers). On Tue, Dec 16, 2014 at 11:16 AM, =F0=9F=94=93Dan Wing wr= ote: > > > On Dec 16, 2014, at 9:40 AM, Justin Uberti wrote: > > Given that TURN servers can be used for STUN, is there a need to > autodiscover STUN-only servers? > > > I am not aware of spec encouraging such implementations, and I don't know > if everyone implementing WebRTC clients is going to be aware that TURN > servers can provide useful information about the mapped IP address. > Perhaps it just needs a few sentences in an appropriate spec? > > -d > > > > On Mon, Dec 15, 2014 at 5:23 PM, =F0=9F=94=93Dan Wing w= rote: >> >> >> On Dec 15, 2014, at 7:56 AM, Hutton, Andrew >> wrote: >> >> +1 Also wondering why it is not appropriate? >> >> F20 in the requirements draft states: >> >> F20 The browser must support the use of STUN and TURN >> servers that are supplied by entities other than >> the web application (i.e. the network provider). >> >> So I was thinking the need for specifying the discovery method would not >> be controversial. >> >> >> Note that draft-ietf-tram-turn-server-discovery only discovers TURN >> servers. If we need to discover STUN servers, too -- and I think we do = -- >> we need that document to expand its scope or a second document. >> >> I recently attended a talk where Matt Peterson presented Burning Man's >> network. That network assigns RFC6598 addresses to each Burning Man >> "camp", and their ISP provides CGN'd addresses to Burning Man. Each cam= p >> operates its own WiFi network, and we can all reasonably assume they are >> using typical consumer or SMB NAPT devices for those networks (e.g., >> D-Link, Linksys, Ubiquity, etc.). To avoid tromboning camp-to-camp WebR= TC >> traffic to their ISP's CGN, they would benefit from a STUN and a TURN >> server within the Burning Man network. His presentation can be found at >> https://www.nanog.org/meetings/nanog62/agenda (PDF and video). >> >> -d >> >> >> >> Andy >> >> >> *From:* Simon Perreault [mailto:sperreault@jive.com >> ] >> *Sent:* 15 December 2014 15:49 >> *To:* Eric Rescorla >> *Cc:* Hutton, Andrew; rtcweb@ietf.org >> *Subject:* Re: [rtcweb] rtcweb-transports reference to TRAM discovery >> >> >> On Mon, Dec 15, 2014 at 10:44 AM, Eric Rescorla wrote: >> I do not believe that this is an appropriate requirement >> >> Care to say why? >> >> Thanks, >> Simon >> _______________________________________________ >> 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 >> >> > --001a11c1d370700eb4050a5ef26d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Seems like something that should go into -transports (i.e.= that WebRTC clients SHOULD obtain a srflx address from the TURN server, in= addition to any provided STUN servers).
On Tue, Dec 16, 2014 at 11:16 AM, =F0=9F=94=93= Dan Wing <dwing@cisco.com> wrote:

On Dec= 16, 2014, at 9:40 AM, Justin Uberti <juberti@google.com> wrote:

Given that TURN servers can be used for ST= UN, is there a need to autodiscover STUN-only servers?

I am not aware of spec encouraging such implementa= tions, and I don't know if everyone implementing WebRTC clients is goin= g to be aware that TURN servers can provide useful information about the ma= pped IP address.=C2=A0 Perhaps it just needs a few sentences in an appropri= ate spec?

-d



On Mon, Dec 15, 2014 at 5:23 PM, =F0=9F=94=93Dan Wing <dwing@cisco.com<= /a>> wrote:


+1 Also wondering why it is not appropriate?
=C2=A0
F20 in the requirements draft states:
=C2=A0
= F20=C2=A0=C2=A0=C2=A0=C2= =A0 The browser must support the use of STUN and TURN<= /div>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 servers tha= t are supplied by entities other than
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the web application (i.e. = the network provider).
=C2=A0
So I was thinking th= e need for specifying the discovery method would not be controversial.

Note that draft-ietf-= tram-turn-server-discovery only discovers TURN servers.=C2=A0 If we need to= discover STUN servers, too -- and I think we do -- we need that document t= o expand its scope or a second document.

I recentl= y attended a talk where Matt Peterson presented Burning Man's network.= =C2=A0 That network assigns RFC6598 addresses to each Burning Man "cam= p", and their ISP provides CGN'd addresses to Burning Man.=C2=A0 E= ach camp operates its own WiFi network, and we can all reasonably assume th= ey are using typical consumer or SMB NAPT devices for those networks (e.g.,= D-Link, Linksys, Ubiquity, etc.).=C2=A0 To avoid tromboning camp-to-camp W= ebRTC traffic to their ISP's CGN, they would benefit from a STUN and a = TURN server within the Burning Man network.=C2=A0 His presentation can be f= ound at=C2=A0https://www.nanog.org/meetings/nanog62/agenda (PDF and vi= deo).

-d
<= br>

=C2=A0=
Andy
=C2=A0
= =C2=A0
From:=C2=A0Simo= n Perreault [mailt= o:sperreault@jive.com]=C2=A0
Sent:=C2=A015 December 2014 15:49
To:=C2=A0Eric RescorlaCc:=C2=A0Hutton, Andrew; rtcweb@ietf.org
Subject:=C2=A0= Re: [rtcweb] rtcweb-transports reference to TRAM discovery=
=C2=A0
=C2=A0
On Mon, Dec 15, 2014 at 10:44 AM, Eric Rescorla <ekr@rtfm.com> wrote:
I do not believe that this is an appropriate requirement

Care to say why?
=C2=A0
<= div>
Thanks,
Simon
______= _________________________________________
rtcweb mailing list
rtcweb@ietf.org
https:= //www.ietf.org/mailman/listinfo/rtcweb
<= br>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb


--001a11c1d370700eb4050a5ef26d-- From nobody Tue Dec 16 17:43:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0CD1A066C for ; Tue, 16 Dec 2014 17:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbUIjcqSdABI for ; Tue, 16 Dec 2014 17:43:38 -0800 (PST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ietfa.amsl.com (Postfix) with ESMTP id C4FA71A03A5 for ; Tue, 16 Dec 2014 17:43:38 -0800 (PST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 16 Dec 2014 17:43:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208,217";a="429922552" Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by FMSMGA003.fm.intel.com with ESMTP; 16 Dec 2014 17:32:32 -0800 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by ORSMSX109.amr.corp.intel.com (10.22.240.7) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 16 Dec 2014 17:43:38 -0800 Received: from fmsmsx118.amr.corp.intel.com ([169.254.1.40]) by fmsmsx111.amr.corp.intel.com ([169.254.12.106]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 17:43:37 -0800 From: "Cavigioli, Chris" To: Roman Shpount , "DRAGE, Keith (Keith)" Thread-Topic: [rtcweb] revisiting MTI Thread-Index: AQHQGK9jwmTfi08o30OOuzngWBrEEpySU1grgACFjgCAAAOiAIAABDqAgAAN0ACAAAebgP//p56pgACLmACAAAzZgP//zWSA Date: Wed, 17 Dec 2014 01:43:37 +0000 Message-ID: References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> <92D0D52F3A63344CA478CF12DB0648AADF363463@XMB111CNC.rim.net> <949EF20990823C4C85C18D59AA11AD8B296427@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.108] Content-Type: multipart/alternative; boundary="_000_E36D1A4AE0B6AA4091F1728D584A6AD240153977fmsmsx118amrcor_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/14NPxeOITyhJQJ1kGMx3gSTVmh0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 01:43:40 -0000 --_000_E36D1A4AE0B6AA4091F1728D584A6AD240153977fmsmsx118amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgICAgVGhlcmUgaXMgbm8gc3VjaCB0aGluZyBhcyBhIGd1YXJhbnRlZWQgSVBSIGZyZWUgY29k ZWMuDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgUm9tYW4gU2hwb3VudA0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMTYsIDIwMTQg MTI6NDIgUE0NClRvOiBEUkFHRSwgS2VpdGggKEtlaXRoKQ0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtydGN3ZWJdIHJldmlzaXRpbmcgTVRJDQoNCk9uIFR1ZSwgRGVjIDE2LCAy MDE0IGF0IDI6NTYgUE0sIERSQUdFLCBLZWl0aCAoS2VpdGgpIDxrZWl0aC5kcmFnZUBhbGNhdGVs LWx1Y2VudC5jb208bWFpbHRvOmtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbT4+IHdyb3Rl Og0KRm9yZ2V0IGl0Lg0KDQpZb3UgYXJlIG1ha2luZyBhbiBhdHRlbXB0IHRvIHJlZHVjZSB0aGUg ZW50aXJlIGlzc3VlIHRvIElQUiwgYW5kIHRoZSBkaXNjdXNzaW9uIHByaW9yIHRvIHRoZSBsYXN0 IG1lZXRpbmcgaGFkIGJlZW4gd2lkZXIgdGhhdCB0aGF0LCBpbmNsdWRpbmcgaXNzdWVzIG9mIGlu dGVyb3BlcmFiaWxpdHkgd2l0aCBlbmRwb2ludHMgb3V0c2lkZSB3ZWJSVEMuDQoNCkFzIGZhciBh cyBJIGFtIGNvbmNlcm5lZCBhbiBJUFIgZnJlZSBjb2RlYyBpcyBpcnJlbGV2YW50IGlmIEkgY2Fu bm90IHRhbGsgdG8gdGhlIGVuZHBvaW50cyBJIG5lZWQgdG8sIGFuZCBqdXN0IGNvbmNlbnRyYXRp bmcgb24gdGhlIHdlYnJ0YyBjb21tdW5pdHkgYXMgdGhlIGF2YWlsYWJsZSBlbmRwb2ludCBtYXkg bWVldCBzb21lIGRlcGxveWVycyB1c2UgY2FzZXMsIGJ1dCBub3Qgb3RoZXJzLg0KDQpUaGVyZSBp cyBubyBzdWNoIHRoaW5nIGFzIElQUiBmcmVlIGNvZGVjLCB1bmxlc3MgeW91IGFyZSB0YWxraW5n IGFib3V0IEguMjYxIG9yIE1KUEVHIHdoZXJlIElQUiBoYXMgZXhwaXJlZC4gV2hhdCB3ZSBhcmUg bG9va2luZyBmb3IgaXMgYSB2aWRlbyBjb2RlYyB3aXRoIGFuIGFjY2VwdGFibGUgcXVhbGl0eSAo Ym90aCBWUDggYW5kIEguMjY0IHF1YWxpZnkpIGFuZCByZWFzb25hYmxlIGxpY2Vuc2luZyAoYm90 aCBWUDggYW5kIEguMjY0IGhhdmUgc2VyaW91cyBpc3N1ZXMgaGVyZSkuIElmIGl0IGlzIGNvbmZp cm1lZCB0aGUgVlA4IGxpY2Vuc2luZyBpc3N1ZXMgYXJlIHJlc29sdmVkIChpLmUuIGl0IHdlbnQg dGhyb3VnaCB0aGUgc3RhbmRhcmRpemF0aW9uIHByb2Nlc3MsIGFsbCBJUFIgZGVjbGFyYXRpb24g YWdhaW5zdCBpdCB3aGljaCBwcmV2ZW50IGxpY2Vuc2luZyBhcmUgY29uZmlybWVkIHRvIG5vdCBh cHBseSBpbiBjb3VydCBvciBkdWUgdG8gc29tZSBzb3J0IG9mIGxpY2VuY2luZyBhZ3JlZW1lbnQp LCB0aGVuIFZQOCBpcyBjbGVhcmx5IHN1cGVyaW9yLiBJZiBILjI2NCBmaXhlcyBpdHMgbGljZW5z aW5nIChpLmUuIHByZXNlbnQgYSBjbGVhciwgcHVibGlzaGVkLCBubyByb3lhbHR5IGxpY2Vuc2lu ZyB0ZXJtcyB3aXRoIG5vIHVzZSByZXN0cmljdGlvbnMpLCBpdCBjYW4gYmUgYSBzdXBlcmlvciBj b2RlYy4gTGVnYWN5IGludGVyb3Agc3VwcG9ydCBpcyBpbXBvcnRhbnQsIGJ1dCB0byBtZSBhdCBs ZWFzdCwgaXQgaXMgc2Vjb25kYXJ5IHRvIHVucmVzdHJpY3RlZCB1c2UuIFBsZWFzZSBzZWUgT3B1 cyB2cyBBTVItV0IrIGZvciBjbGVhciBzaW1pbGFyaXRpZXMuDQoNCkFsc28sIFZQOSBvciBILjI2 NSB3b3VsZCBjbGVhcmx5ICBpbXByb3ZlIHZpZGVvIHF1YWxpdHksIGJ1dCBib3RoIFZQOCBhbmQg SC4yNjQgd2l0aCB0aGUgY3VycmVudCBjb25uZWN0aW9uIHNwZWVkcyBhbGxvdyBmb3IgdGhlIGhp Z2hseSB1c2FibGUgdmlkZW8gY29tbXVuaWNhdGlvbnMuIEkgdGhpbmsgdGhhdCBxdWFsaXR5IHdp c2UsIGVpdGhlciBvbmUgb2YgVlA4IGFuZCBILjI2NCBjYW4gc2VydmUgYXMgdXNhYmxlIE1USSBm b3IgYSBsb3QgbG9uZ2VyIHRoZW4gdGhlIG5leHQgdHdvIHllYXJzIG9yIHdoYXRldmVyIHRpbWUg aXMgcmVxdWlyZWQgZm9yIHRoZSBuZXh0IGdyZWF0IHZpZGVvIGNvZGVjIHRvIGJlIGRldmVsb3Bl ZC4gRXNwZWNpYWxseSBpbiBhbm90aGVyIDUtNiB5ZWFycyB3aGVuIGFsbCB0aGUgSVBSIG9uIHRo ZXNlIGNvZGVjcyB3aWxsIGV4cGlyZS4NCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg== --_000_E36D1A4AE0B6AA4091F1728D584A6AD240153977fmsmsx118amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VmVyZGFuYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mIzQzOzEmbmJzcDsmbmJzcDsm bmJzcDsgVGhlcmUgaXMgbm8gc3VjaCB0aGluZyBhcyBhIGd1YXJhbnRlZWQgSVBSIGZyZWUgY29k ZWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFttYWls dG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvbWFuIFNo cG91bnQ8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRGVjZW1iZXIgMTYsIDIwMTQgMTI6NDIg UE08YnI+DQo8Yj5Ubzo8L2I+IERSQUdFLCBLZWl0aCAoS2VpdGgpPGJyPg0KPGI+Q2M6PC9iPiBy dGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIHJldmlzaXRp bmcgTVRJPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBUdWUsIERlYyAxNiwgMjAxNCBhdCAyOjU2IFBNLCBEUkFHRSwgS2VpdGggKEtlaXRoKSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsdWUiPkZvcmdldCBpdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsdWUiPllvdSBhcmUgbWFraW5nIGFuIGF0dGVtcHQgdG8gcmVkdWNlIHRoZSBlbnRp cmUgaXNzdWUgdG8gSVBSLCBhbmQgdGhlIGRpc2N1c3Npb24gcHJpb3IgdG8gdGhlIGxhc3QgbWVl dGluZyBoYWQgYmVlbiB3aWRlciB0aGF0IHRoYXQsIGluY2x1ZGluZyBpc3N1ZXMgb2YgaW50ZXJv cGVyYWJpbGl0eSB3aXRoIGVuZHBvaW50cw0KIG91dHNpZGUgd2ViUlRDLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+QXMgZmFyIGFzIEkgYW0gY29u Y2VybmVkIGFuIElQUiBmcmVlIGNvZGVjIGlzIGlycmVsZXZhbnQgaWYgSSBjYW5ub3QgdGFsayB0 byB0aGUgZW5kcG9pbnRzIEkgbmVlZCB0bywgYW5kIGp1c3QgY29uY2VudHJhdGluZyBvbiB0aGUg d2VicnRjIGNvbW11bml0eSBhcyB0aGUgYXZhaWxhYmxlIGVuZHBvaW50IG1heQ0KIG1lZXQgc29t ZSBkZXBsb3llcnMgdXNlIGNhc2VzLCBidXQgbm90IG90aGVycy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzIG5vIHN1 Y2ggdGhpbmcgYXMgSVBSIGZyZWUgY29kZWMsIHVubGVzcyB5b3UgYXJlIHRhbGtpbmcgYWJvdXQg SC4yNjEgb3IgTUpQRUcgd2hlcmUgSVBSIGhhcyBleHBpcmVkLiBXaGF0IHdlIGFyZSBsb29raW5n IGZvciBpcyBhIHZpZGVvIGNvZGVjIHdpdGggYW4gYWNjZXB0YWJsZSBxdWFsaXR5IChib3RoIFZQ OCBhbmQgSC4yNjQgcXVhbGlmeSkgYW5kIHJlYXNvbmFibGUgbGljZW5zaW5nIChib3RoDQogVlA4 IGFuZCBILjI2NCBoYXZlIHNlcmlvdXMgaXNzdWVzIGhlcmUpLiBJZiBpdCBpcyBjb25maXJtZWQg dGhlIFZQOCBsaWNlbnNpbmcgaXNzdWVzIGFyZSByZXNvbHZlZCAoaS5lLiBpdCB3ZW50IHRocm91 Z2ggdGhlIHN0YW5kYXJkaXphdGlvbiBwcm9jZXNzLCBhbGwgSVBSIGRlY2xhcmF0aW9uIGFnYWlu c3QgaXQgd2hpY2ggcHJldmVudCBsaWNlbnNpbmcgYXJlIGNvbmZpcm1lZCB0byBub3QgYXBwbHkg aW4gY291cnQgb3IgZHVlIHRvIHNvbWUgc29ydA0KIG9mIGxpY2VuY2luZyBhZ3JlZW1lbnQpLCB0 aGVuIFZQOCBpcyBjbGVhcmx5IHN1cGVyaW9yLiBJZiBILjI2NCBmaXhlcyBpdHMgbGljZW5zaW5n IChpLmUuIHByZXNlbnQgYSBjbGVhciwgcHVibGlzaGVkLCBubyByb3lhbHR5IGxpY2Vuc2luZyB0 ZXJtcyB3aXRoIG5vIHVzZSByZXN0cmljdGlvbnMpLCBpdCBjYW4gYmUgYSBzdXBlcmlvciBjb2Rl Yy4gTGVnYWN5IGludGVyb3Agc3VwcG9ydCBpcyBpbXBvcnRhbnQsIGJ1dCB0byBtZSBhdCBsZWFz dCwNCiBpdCBpcyBzZWNvbmRhcnkgdG8gdW5yZXN0cmljdGVkIHVzZS4gUGxlYXNlIHNlZSBPcHVz IHZzIEFNUi1XQiYjNDM7IGZvciBjbGVhciBzaW1pbGFyaXRpZXMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28sIFZQOSBvciBILjI2NSB3 b3VsZCBjbGVhcmx5ICZuYnNwO2ltcHJvdmUgdmlkZW8gcXVhbGl0eSwgYnV0IGJvdGggVlA4IGFu ZCBILjI2NCB3aXRoIHRoZSBjdXJyZW50IGNvbm5lY3Rpb24gc3BlZWRzIGFsbG93IGZvciB0aGUg aGlnaGx5IHVzYWJsZSB2aWRlbyBjb21tdW5pY2F0aW9ucy4gSSB0aGluayB0aGF0IHF1YWxpdHkg d2lzZSwgZWl0aGVyIG9uZSBvZiBWUDggYW5kIEguMjY0IGNhbiBzZXJ2ZSBhcyB1c2FibGUNCiBN VEkgZm9yIGEgbG90IGxvbmdlciB0aGVuIHRoZSBuZXh0IHR3byB5ZWFycyBvciB3aGF0ZXZlciB0 aW1lIGlzIHJlcXVpcmVkIGZvciB0aGUgbmV4dCBncmVhdCB2aWRlbyBjb2RlYyB0byBiZSBkZXZl bG9wZWQuIEVzcGVjaWFsbHkgaW4gYW5vdGhlciA1LTYgeWVhcnMgd2hlbiBhbGwgdGhlIElQUiBv biB0aGVzZSBjb2RlY3Mgd2lsbCBleHBpcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNo cG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E36D1A4AE0B6AA4091F1728D584A6AD240153977fmsmsx118amrcor_-- From nobody Tue Dec 16 19:55:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353E71A01A9 for ; Tue, 16 Dec 2014 19:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJ_dbHUj8jHt for ; Tue, 16 Dec 2014 19:55:00 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE0B1A1B12 for ; Tue, 16 Dec 2014 19:54:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6320; q=dns/txt; s=iport; t=1418788499; x=1419998099; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=RJdSel0rihK3VBdaUo6Z7VRuT8cIdsLCC9iMyb4XkXM=; b=Lvdq1LXmsYv2A8778d5aiwsSAT7uLdLnG23wHXKDLJXnBJ8BbvBNrRe1 jPajT0gmvA6/lBf1AA30W3qG3559T2kGCYLII2Of3/wCd6xSlZectla34 5uA3E0+EiDKlBA8rbecHESQnH9wkiSJIc3kddGNEKE24MEpZgTotcvUWe o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkFAEX9kFStJA2M/2dsb2JhbABagkNDUlgExXkBCYUoSgKBHxYBAQEBAX2EDAEBAQQBAQFrGwIBCBEDAQIoByEGCxQJCAIEARIJiA8DEQ3Obw2FSQEBAQEBAQEDAQEBAQEBAQEajUqBVwEBPg0LhCkFjgeHLYFDi2aFUyKDbG4BgQs5fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,591,1413244800"; d="scan'208,217";a="380721394" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-8.cisco.com with ESMTP; 17 Dec 2014 03:54:58 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sBH3swrA030609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Dec 2014 03:54:58 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.28]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 21:54:58 -0600 From: "Ram Mohan R (rmohanr)" To: Muthu Arul Mozhi Perumal , Christer Holmberg , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-10.txt Thread-Index: AQHQGa05RQziK8e4a0aod+gUcmHR1w== Date: Wed, 17 Dec 2014 03:54:57 +0000 Message-ID: References: <20141215034305.14105.51004.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D5C7B1D@ESESSMB208.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5CACA0@ESESSMB208.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.196.64.138] Content-Type: multipart/alternative; boundary="_000_D0B6FE321C789rmohanrciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/06JNAW0ZHdMbqNeBq4ewGm2Nlpo Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 03:55:02 -0000 --_000_D0B6FE321C789rmohanrciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Proposed text looks good to me. I will go ahead and incorporate this if oth= ers have no issues. Ram From: Muthu Arul Mozhi Perumal > Date: Monday, 15 December 2014 8:22 pm To: Christer Holmberg > Cc: "rtcweb@ietf.org" > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-= 10.txt We discussed this earlier in the WG: http://www.ietf.org/mail-archive/web/rtcweb/current/msg13020.html In fact, -08 had the following non-normative text: A WebRTC implementation [I-D.ietf-rtcweb-overview], which implements full ICE, performs consent freshness test using STUN request/response as described below: I think the text in -10 can be replaced with: A full ICE implementation performs consent freshness test using STUN request/response as described below: And the security-arch / overview documents can specify how it applies to We= bRTC. Muthu On Mon, Dec 15, 2014 at 7:19 PM, Christer Holmberg > wrote: Hi, >I suggest to simply remove the whole paragraph and the reference. That is my suggestion also :) As Harald indicated he will add text to the overview document about the usa= ge, nothing is "lost". Regards, Christer _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_D0B6FE321C789rmohanrciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <712D235020B8FF47B2209EF1B02FD541@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Proposed text looks good to me. I will go ahead and incorporate this i= f others have no issues.

Ram

From: Muthu Arul Mozhi Perumal <= muthu.arul@gmail.com>
Date: Monday, 15 December 2014 8:22= pm
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "rtcweb@ietf.org" <= rtcweb@ietf.org>
Subject: Re: [rtcweb] I-D Action: d= raft-ietf-rtcweb-stun-consent-freshness-10.txt

We discussed this earlier in the WG:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg13020.html=

In fact, -08 had the following non-= normative text:
   A WebRTC implementation [I-D.ietf= -rtcweb-overview], which implements
   full ICE, performs consent freshn= ess test using STUN request/response
   as described below:

I think the text in -10 can be replaced with:<= /div>
   A full ICE implementation perform= s consent freshness test using STUN 
   request/response as described bel= ow:

And the security-arch / overview documents can= specify how it applies to WebRTC.

Muthu

On Mon, Dec 15, 2014 at 7:19 PM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

>I suggest to simply remove the whole paragraph and the reference.

That is my suggestion also :)

As Harald indicated he will add text to the overview document about the usa= ge, nothing is "lost".

Regards,

Christer

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--_000_D0B6FE321C789rmohanrciscocom_-- From nobody Wed Dec 17 03:37:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C041A88CF for ; Wed, 17 Dec 2014 03:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZi4Pg8aDYBJ for ; Wed, 17 Dec 2014 03:37:25 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3B41A88CC for ; Wed, 17 Dec 2014 03:37:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5412; q=dns/txt; s=iport; t=1418816245; x=1420025845; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3L4TfO4BMu8P7pnKhdo62Cqjgjur6tg7uAkOA7Kw3TM=; b=cTKVILHSAeR208I4kiq3sN3WabyFK7OJgx9c0x4JQFc5wRwtDhdYkoWJ qGV6L4rN6/0AnYyPzInzu90o95Q6YINvfFHZVpGgKlocfDo3IKhlFukD0 EUDXGKBphnuRh2DmcyAWQmhhjuUolv642fWIC7Q8iDTsDz9QF4Xei7fh0 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEHADRqkVStJV2T/2dsb2JhbABagwZSTQsEgwLCZAqFKEoCHIEDFgEBAQEBfYQMAQEBAwEBAQEgEToLBQsCAQYCEQQBAQECAiMDAgICJQsUAQgIAgQOBYgkCA2hHpxolh0BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEhjh4zB4JoLoETAQSEKwKJW4hwgQuFEosjIoNsb4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,593,1413244800"; d="scan'208";a="113867629" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by mtv-iport-2.cisco.com with ESMTP; 17 Dec 2014 11:37:25 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sBHBbNe8027630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Dec 2014 11:37:24 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.155]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 05:37:23 -0600 From: "Pal Martinsen (palmarti)" To: "Dan Wing (dwing)" Thread-Topic: [rtcweb] rtcweb-transports reference to TRAM discovery Thread-Index: AdAYdVah0SPsel0ORrys7Zw+IDeNbwAOwVWAAAAno4AAAD+hAAATz+iAACIbVgAAA1/SgAAiPcKA Date: Wed, 17 Dec 2014 11:37:23 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E63FD67@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.74] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xp97I7afCoJ1f_D0vDjDl47uwvs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 11:37:34 -0000 DQo+IE9uIDE2IERlYyAyMDE0LCBhdCAyMDoxNiwgRGFuIFdpbmcgKGR3aW5nKSA8ZHdpbmdAY2lz Y28uY29tPiB3cm90ZToNCj4gDQo+IA0KPiBPbiBEZWMgMTYsIDIwMTQsIGF0IDk6NDAgQU0sIEp1 c3RpbiBVYmVydGkgPGp1YmVydGlAZ29vZ2xlLmNvbT4gd3JvdGU6DQo+IA0KPj4gR2l2ZW4gdGhh dCBUVVJOIHNlcnZlcnMgY2FuIGJlIHVzZWQgZm9yIFNUVU4sIGlzIHRoZXJlIGEgbmVlZCB0byBh dXRvZGlzY292ZXIgU1RVTi1vbmx5IHNlcnZlcnM/DQo+IA0KPiBJIGFtIG5vdCBhd2FyZSBvZiBz cGVjIGVuY291cmFnaW5nIHN1Y2ggaW1wbGVtZW50YXRpb25zLCBhbmQgSSBkb24ndCBrbm93IGlm IGV2ZXJ5b25lIGltcGxlbWVudGluZyBXZWJSVEMgY2xpZW50cyBpcyBnb2luZyB0byBiZSBhd2Fy ZSB0aGF0IFRVUk4gc2VydmVycyBjYW4gcHJvdmlkZSB1c2VmdWwgaW5mb3JtYXRpb24gYWJvdXQg dGhlIG1hcHBlZCBJUCBhZGRyZXNzLiAgUGVyaGFwcyBpdCBqdXN0IG5lZWRzIGEgZmV3IHNlbnRl bmNlcyBpbiBhbiBhcHByb3ByaWF0ZSBzcGVjPw0KPiANClRoZSBpbmZvcm1hdGlvbiBpcyBidXJp ZWQgZGVlcCBkb3duIGluIHRoZSBUVVJOIFJGQyA1NzY2IFNlY3Rpb24gNi4yLiBJdCBzdGF0ZXMg dGhhdCB0aGUgYWxsb2NhdGlvbiBzdWNjZXNzIHJlc3BvbnNlIGNvbnRhaW5zIGEgWE9SLU1BUFBF RC1BRERSRVNTIGF0dHJpYnV0ZS4gKE5vIHVzZSBvZiBTSE9VTEQgb3IgTVVTVCkuDQoNCkl0IGFs c28gaGF2ZSBhIG5pY2Ugbm90ZToNCiJOT1RFOiBUaGUgWE9SLU1BUFBFRC1BRERSRVNTIGF0dHJp YnV0ZSBpcyBpbmNsdWRlZCBpbiB0aGUgcmVzcG9uc2UNCiBhcyBhIGNvbnZlbmllbmNlIHRvIHRo ZSBjbGllbnQuICBUVVJOIGl0c2VsZiBkb2VzIG5vdCBtYWtlIHVzZSBvZg0KIHRoaXMgdmFsdWUs IGJ1dCBjbGllbnRzIHJ1bm5pbmcgSUNFIGNhbiBvZnRlbiBuZWVkIHRoaXMgdmFsdWUgYW5kDQog Y2FuIHRodXMgYXZvaWQgaGF2aW5nIHRvIGRvIGFuIGV4dHJhIEJpbmRpbmcgdHJhbnNhY3Rpb24g d2l0aCBzb21lDQogU1RVTiBzZXJ2ZXIgdG8gbGVhcm4gaXQu4oCdDQoNClN0YXRpbmcgdGhlIGFi b3ZlIGluIHNvbWUgb3ZlcnZpZXcgZG9jdW1lbnQgd2lsbCBoZWxwIHBlb3BsZSBkZXBsb3lpbmcg V2ViUlRDIHVuZGVyc3RhbmQgdGhlIHJlcXVpcmVtZW50cy4gVGhlIHRleHQgaW4gdGhlIFRVTlIg UkZDIHdpbGwgcHJvYmFibHkgb25seSBiZSByZWFkIGJ5IFRVUk4gZGV2ZWxvcGVycy4NCg0KTW9y ZSBpbXBvcnRhbnRseSB3aGF0IGlzIG1pc3NpbmcgaXMgdGV4dCBzdGF0aW5nIHRoYXQgZGVwbG95 ZWQgV2ViUlRDIHR1cm4gc2VydmVycyBzaG91bGQgYWxzbyBzZW5kIGFwcHJvcHJpYXRlIHJlc3Bv bnNlcyB0byBCaW5kaW5nIFJlcXVlc3RzOyBpbiBvdGhlciB3b3JkcyBhY3QgYXMgYSBTVFVOIHNl cnZlci4gTm90IHN1cmUgYWJvdXQgdGhlIGFwcHJvcHJpYXRlIHNwZWMsIGJ1dCBpdCBjYW4gZ28g aW50byBUVVJOYmlzIG9yIHNvbWUgV2ViUlRDIG92ZXJ2aWV3IGRvY3VtZW50LiANCg0KLi0uDQpQ w6VsLUVyaWsNCg0KDQoNCj4gLWQNCj4gDQo+IA0KPj4gDQo+PiBPbiBNb24sIERlYyAxNSwgMjAx NCBhdCA1OjIzIFBNLCDwn5STRGFuIFdpbmcgPGR3aW5nQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiAN Cj4+IE9uIERlYyAxNSwgMjAxNCwgYXQgNzo1NiBBTSwgSHV0dG9uLCBBbmRyZXcgPGFuZHJldy5o dXR0b25AdW5pZnkuY29tPiB3cm90ZToNCj4+IA0KPj4+ICsxIEFsc28gd29uZGVyaW5nIHdoeSBp dCBpcyBub3QgYXBwcm9wcmlhdGU/DQo+Pj4gIA0KPj4+IEYyMCBpbiB0aGUgcmVxdWlyZW1lbnRz IGRyYWZ0IHN0YXRlczoNCj4+PiAgDQo+Pj4gRjIwICAgICBUaGUgYnJvd3NlciBtdXN0IHN1cHBv cnQgdGhlIHVzZSBvZiBTVFVOIGFuZCBUVVJODQo+Pj4gICAgICAgICAgICBzZXJ2ZXJzIHRoYXQg YXJlIHN1cHBsaWVkIGJ5IGVudGl0aWVzIG90aGVyIHRoYW4NCj4+PiAgICAgICAgICAgIHRoZSB3 ZWIgYXBwbGljYXRpb24gKGkuZS4gdGhlIG5ldHdvcmsgcHJvdmlkZXIpLg0KPj4+ICANCj4+PiBT byBJIHdhcyB0aGlua2luZyB0aGUgbmVlZCBmb3Igc3BlY2lmeWluZyB0aGUgZGlzY292ZXJ5IG1l dGhvZCB3b3VsZCBub3QgYmUgY29udHJvdmVyc2lhbC4NCj4+IA0KPj4gTm90ZSB0aGF0IGRyYWZ0 LWlldGYtdHJhbS10dXJuLXNlcnZlci1kaXNjb3Zlcnkgb25seSBkaXNjb3ZlcnMgVFVSTiBzZXJ2 ZXJzLiAgSWYgd2UgbmVlZCB0byBkaXNjb3ZlciBTVFVOIHNlcnZlcnMsIHRvbyAtLSBhbmQgSSB0 aGluayB3ZSBkbyAtLSB3ZSBuZWVkIHRoYXQgZG9jdW1lbnQgdG8gZXhwYW5kIGl0cyBzY29wZSBv ciBhIHNlY29uZCBkb2N1bWVudC4NCj4+IA0KPj4gSSByZWNlbnRseSBhdHRlbmRlZCBhIHRhbGsg d2hlcmUgTWF0dCBQZXRlcnNvbiBwcmVzZW50ZWQgQnVybmluZyBNYW4ncyBuZXR3b3JrLiAgVGhh dCBuZXR3b3JrIGFzc2lnbnMgUkZDNjU5OCBhZGRyZXNzZXMgdG8gZWFjaCBCdXJuaW5nIE1hbiAi Y2FtcCIsIGFuZCB0aGVpciBJU1AgcHJvdmlkZXMgQ0dOJ2QgYWRkcmVzc2VzIHRvIEJ1cm5pbmcg TWFuLiAgRWFjaCBjYW1wIG9wZXJhdGVzIGl0cyBvd24gV2lGaSBuZXR3b3JrLCBhbmQgd2UgY2Fu IGFsbCByZWFzb25hYmx5IGFzc3VtZSB0aGV5IGFyZSB1c2luZyB0eXBpY2FsIGNvbnN1bWVyIG9y IFNNQiBOQVBUIGRldmljZXMgZm9yIHRob3NlIG5ldHdvcmtzIChlLmcuLCBELUxpbmssIExpbmtz eXMsIFViaXF1aXR5LCBldGMuKS4gIFRvIGF2b2lkIHRyb21ib25pbmcgY2FtcC10by1jYW1wIFdl YlJUQyB0cmFmZmljIHRvIHRoZWlyIElTUCdzIENHTiwgdGhleSB3b3VsZCBiZW5lZml0IGZyb20g YSBTVFVOIGFuZCBhIFRVUk4gc2VydmVyIHdpdGhpbiB0aGUgQnVybmluZyBNYW4gbmV0d29yay4g IEhpcyBwcmVzZW50YXRpb24gY2FuIGJlIGZvdW5kIGF0IGh0dHBzOi8vd3d3Lm5hbm9nLm9yZy9t ZWV0aW5ncy9uYW5vZzYyL2FnZW5kYSAoUERGIGFuZCB2aWRlbykuDQo+PiANCj4+IC1kDQo+PiAN Cj4+IA0KPj4+ICANCj4+PiBBbmR5DQo+Pj4gIA0KPj4+ICANCj4+PiBGcm9tOiBTaW1vbiBQZXJy ZWF1bHQgW21haWx0bzpzcGVycmVhdWx0QGppdmUuY29tXSANCj4+PiBTZW50OiAxNSBEZWNlbWJl ciAyMDE0IDE1OjQ5DQo+Pj4gVG86IEVyaWMgUmVzY29ybGENCj4+PiBDYzogSHV0dG9uLCBBbmRy ZXc7IHJ0Y3dlYkBpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBydGN3ZWItdHJh bnNwb3J0cyByZWZlcmVuY2UgdG8gVFJBTSBkaXNjb3ZlcnkNCj4+PiAgDQo+Pj4gIA0KPj4+IE9u IE1vbiwgRGVjIDE1LCAyMDE0IGF0IDEwOjQ0IEFNLCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5j b20+IHdyb3RlOg0KPj4+IEkgZG8gbm90IGJlbGlldmUgdGhhdCB0aGlzIGlzIGFuIGFwcHJvcHJp YXRlIHJlcXVpcmVtZW50DQo+Pj4gDQo+Pj4gQ2FyZSB0byBzYXkgd2h5Pw0KPj4+ICANCj4+PiBU aGFua3MsDQo+Pj4gU2ltb24NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+PiBydGN3ZWJAaWV0Zi5v cmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPj4g DQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+PiBydGN3ZWJAaWV0Zi5vcmcNCj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+PiANCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHJ0Y3dlYiBtYWlsaW5n IGxpc3QNCj4gcnRjd2ViQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcnRjd2ViDQoNCg== From nobody Wed Dec 17 04:33:30 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644621A8977; Wed, 17 Dec 2014 04:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z45PmSoPu2GN; Wed, 17 Dec 2014 04:33:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AE71A8948; Wed, 17 Dec 2014 04:33:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141217123326.17146.9261.idtracker@ietfa.amsl.com> Date: Wed, 17 Dec 2014 04:33:26 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5lFmFsZ_B1pLki40_k2oAcWOg78 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-15.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 12:33:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Web Real-Time Communication Use-cases and Requirements Authors : Christer Holmberg Stefan Hakansson Goran AP Eriksson Filename : draft-ietf-rtcweb-use-cases-and-requirements-15.txt Pages : 33 Date : 2014-12-17 Abstract: This document describes web based real-time communication use-cases. Requirements on the browser functionality are derived from the use- cases. This document was developed in an initial phase of the work with rather minor updates at later stages. It has not really served as a tool in deciding features or scope for the WGs efforts so far. It is being published to record the early conclusions of the working group. It will not be used as a set of rigid guidelines that specifications and implementations will be held to in the future. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-use-cases-and-requirements-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 17 05:15:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A521A8A6C for ; Wed, 17 Dec 2014 05:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbIKRHfT34nG for ; Wed, 17 Dec 2014 05:15:04 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859F91A8A6B for ; Wed, 17 Dec 2014 05:15:03 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-1d-549181d5600e Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2F.E4.29772.5D181945; Wed, 17 Dec 2014 14:15:01 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 14:15:01 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: BUNDLE: How to process bundled m- lines when no address fulfills the criteria for being selected as the offerer BUNDLE address? Thread-Index: AdAZ+3RRvr7r/rTWQnCuYlntTHiCwQ== Date: Wed, 17 Dec 2014 13:15:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5F98D8@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D5F98D8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje7VxokhBvd6dCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxor3cxgL/ptWvNyyibWB8ZheFyMHh4SAicTzg0xdjJxAppjE hXvr2boYuTiEBI4wSjz82cIK4SxhlNi+chE7SAObgIVE9z9tkAYRAXWJyw8vsIPUCAt0MUoc uAfSAJLoZ5T4eFAapF5EQE/i6SpmkDCLgKrEkndPwJbxCvhKrDx4HMxmBFr8/dQaMJtZQFzi 1pP5UAcJSCzZc54ZwhaVePn4HyuErSjR/rSBEaI+X2Ln4T1QMwUlTs58wjKBUWgWklGzkJTN QlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzGKFqcWJ+WmGxnppRZlJhcX5+fp5aWW bGIERsTBLb8NdjC+fO54iFGAg1GJh3fDxwkhQqyJZcWVuYcYpTlYlMR5F56bFywkkJ5Ykpqd mlqQWhRfVJqTWnyIkYmDU6qB0YhP31F4y0ITj3pHQ5mvrpplipYmP/ZHvyubfKu442GSo/Ky 9eUMEoceSXnIVMa9jBEwnp1gtPmP2RtvwYzLb6XMa9kTdrx3LtbnfXdqnfZETkafc3nWfJPD 18gfUCv9FRFo3Hxu+82MR53Gdc88tW7ayM2bfGrewdvHdyzmKi30nNp92VlXiaU4I9FQi7mo OBEAUmeYXWkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8CyfP2O1cdEni5duma6q9RoRcuE Subject: [rtcweb] BUNDLE: How to process bundled m- lines when no address fulfills the criteria for being selected as the offerer BUNDLE address? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 13:15:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D5F98D8ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We currently have the following text in BUNDLE, when the answerer selects t= he offerer BUNDLE address: "If one or more of the criteria are not fulfilled, the answ= erer MUST select the next identification-tag in the identification-tag list, and perf= orm the same criteria check for the "m=3D" line associated with that identificati= on-tag. If there are no more identification-tags in the identification-tag list, th= e answerer MUST NOT create the BUNDLE group." Now, as the text says, if there is no bundled "m=3D" line address in the of= fer which fulfills the criteria for being selected as the offerer BUNDLE ad= dress, the answer MUST NOT create the offerer BUNDLE group. So far so good. However, I think it would be good to have some text on what the answerer DO= ES with the "m=3D" lines (in case the answerer doesn't reject the whole off= er, that is). So, I suggested to append the following text to the paragraph: "Unless the answerer rejects the whole offer, the answerer MUST apply the = answerer procedures for moving an "m=3D" line out of a BUNDLE group to each bundled= "m=3D" line in the offer when creating the answer." This basically means that, if the "m=3D" line had a shared address, or a bu= ndle-only attribute, it will be rejected. If the "m=3D" line had a unique a= ddress, the answerer will assign a unique address in the answer. Comments? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D5F98D8ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We currently have the following text in BUNDLE, when= the answerer selects the offerer BUNDLE address:

 

        &nbs= p;       “If one or more of the criteri= a are not fulfilled, the answerer MUST select the next

        &nbs= p;       identification-tag in the identifica= tion-tag list, and perform the same criteria

        &nbs= p;       check for the "m=3D" line = associated with that identification-tag. If there are no

        &nbs= p;       more identification-tags in the iden= tification-tag list, the answerer MUST NOT

        &nbs= p;       create the BUNDLE group.”=

 

Now, as the text says, if there is no bundled “= ;m=3D” line address in the offer which fulfills the criteria for bein= g selected as the offerer BUNDLE address, the answer MUST NOT create the of= ferer BUNDLE group. So far so good.

 

However, I think it would be good to have some text = on what the answerer DOES with the “m=3D” lines (in case the an= swerer doesn’t reject the whole offer, that is).

 

So, I suggested to append the following text to the = paragraph:

 

“Unless the answe= rer rejects the whole offer, the answerer  MUST apply the answerer

procedures for moving a= n "m=3D" line out of a BUNDLE group to each  bundled "m= =3D" line

in the offer when creat= ing the answer.”

 

This basically means that, if the “m=3D”= line had a shared address, or a bundle-only attribute, it will be rejected= . If the “m=3D” line had a unique address, the answerer will as= sign a unique address in the answer.

 

Comments?

 

Regards,

 

Christer

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D5F98D8ESESSMB209erics_-- From nobody Wed Dec 17 06:28:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EDE1A1B57 for ; Wed, 17 Dec 2014 06:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyWi3_6XGXOw for ; Wed, 17 Dec 2014 06:28:46 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DCBD1A8984 for ; Wed, 17 Dec 2014 06:28:41 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-61-5491931710bc Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 84.F6.24955.71391945; Wed, 17 Dec 2014 15:28:39 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 15:28:39 +0100 From: Christer Holmberg To: Christer Holmberg , "rtcweb@ietf.org" Thread-Topic: [rtcweb] BUNDLE: How to process bundled m- lines when no address fulfills the criteria for being selected as the offerer BUNDLE address? Thread-Index: AQHQGgW/HRmAIoX/gUODS44HNPTVzA== Date: Wed, 17 Dec 2014 14:28:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5FCB49@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D5F98D8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5F98D8@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D5FCB49ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvja745IkhBr2bdS3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoXTwQWfrSrmrixtYNxp1MXIySEhYCIxb/NNdghbTOLCvfVs XYxcHEICRxglZj0+xAThLGGUWPa9h7GLkYODTcBCovufNkiDiECsxIrN01lAaoQFZjJKXO+5 xQ7iiAjMYpToa3/PDlGlJ3H9Yy8LiM0ioCoxf/MKNpBBvAK+Ege6pEDCQkDmuSmfwEo4Bfwk 5u1ZzAxiMwJd9P3UGiYQm1lAXKLpy0pWiEsFJJbsOc8MYYtKvHz8jxWiJl/i4v5FjCA2r4Cg xMmZT1gmMArPQtI+C0nZLCRlEHEDiS/vb0PZ2hLLFr5mhrD1Jbrfn2ZCFl/AyL6KUbQ4tTgp N93IWC+1KDO5uDg/Ty8vtWQTIzBSDm75rbqD8fIbx0OMAhyMSjy8Gz5OCBFiTSwrrsw9xCjN waIkzrvw3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwtU6L++PRvu3ogpbpQLsGz7rlD XesdlyLXd5P33D0usM5nYvDsO7nrPeZdSW1YbX6oS2fH3fMLQ8zDn7RrHUoUsd/Q5lRaeS10 xq6Za5y2l5VO427ekLQ58fm3PuPvl/vjTCqMNiwwP7Hr6fn36kzKF5mqtP7arzW7OuXK/mlF +kL35lo8eFuuxFKckWioxVxUnAgAF9HFj3UCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/j7_Hcn3wOF-A5laOmthV2mzOZVk Subject: Re: [rtcweb] BUNDLE: How to process bundled m- lines when no address fulfills the criteria for being selected as the offerer BUNDLE address? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 14:28:50 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D5FCB49ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Sorry - wrong list. Please discard and continue with your codec discussion = :) Regards, Christet Sent from my Windows Phone ________________________________ From: Christer Holmberg Sent: =FD17/=FD12/=FD2014 15:15 To: rtcweb@ietf.org Subject: [rtcweb] BUNDLE: How to process bundled m- lines when no address f= ulfills the criteria for being selected as the offerer BUNDLE address? Hi, We currently have the following text in BUNDLE, when the answerer selects t= he offerer BUNDLE address: =93If one or more of the criteria are not fulfilled, the an= swerer MUST select the next identification-tag in the identification-tag list, and perf= orm the same criteria check for the "m=3D" line associated with that identificati= on-tag. If there are no more identification-tags in the identification-tag list, th= e answerer MUST NOT create the BUNDLE group.=94 Now, as the text says, if there is no bundled =93m=3D=94 line address in th= e offer which fulfills the criteria for being selected as the offerer BUNDL= E address, the answer MUST NOT create the offerer BUNDLE group. So far so g= ood. However, I think it would be good to have some text on what the answerer DO= ES with the =93m=3D=94 lines (in case the answerer doesn=92t reject the who= le offer, that is). So, I suggested to append the following text to the paragraph: =93Unless the answerer rejects the whole offer, the answerer MUST apply th= e answerer procedures for moving an "m=3D" line out of a BUNDLE group to each bundled= "m=3D" line in the offer when creating the answer.=94 This basically means that, if the =93m=3D=94 line had a shared address, or = a bundle-only attribute, it will be rejected. If the =93m=3D=94 line had a = unique address, the answerer will assign a unique address in the answer. Comments? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D5FCB49ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Sorry - wrong= list. Please discard and continue with your codec discussion :)

Regards,

Christet

Sent from my Windows Phone
From: Christer Holmberg Sent: =FD17= /=FD12/=FD2014 15:15
To: rtcweb@ietf.org
Subject: [rtcw= eb] BUNDLE: How to process bundled m- lines when no address fulfills the cr= iteria for being selected as the offerer BUNDLE address?

Hi,

 

We currently have the following text in BUNDLE, when= the answerer selects the offerer BUNDLE address:

 

        &nbs= p;       =93If one or more of the criteria ar= e not fulfilled, the answerer MUST select the next

        &nbs= p;       identification-tag in the identifica= tion-tag list, and perform the same criteria

        &nbs= p;       check for the "m=3D" line = associated with that identification-tag. If there are no

        &nbs= p;       more identification-tags in the iden= tification-tag list, the answerer MUST NOT

        &nbs= p;       create the BUNDLE group.=94

 

Now, as the text says, if there is no bundled =93m= =3D=94 line address in the offer which fulfills the criteria for being sele= cted as the offerer BUNDLE address, the answer MUST NOT create the offerer = BUNDLE group. So far so good.

 

However, I think it would be good to have some text = on what the answerer DOES with the =93m=3D=94 lines (in case the answerer d= oesn=92t reject the whole offer, that is).

 

So, I suggested to append the following text to the = paragraph:

 

=93Unless the answerer = rejects the whole offer, the answerer  MUST apply the answerer

procedures for moving a= n "m=3D" line out of a BUNDLE group to each  bundled "m= =3D" line

in the offer when creat= ing the answer.=94

 

This basically means that, if the =93m=3D=94 line ha= d a shared address, or a bundle-only attribute, it will be rejected. If the= =93m=3D=94 line had a unique address, the answerer will assign a unique ad= dress in the answer.

 

Comments?

 

Regards,

 

Christer

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D5FCB49ESESSMB209erics_-- From nobody Wed Dec 17 07:24:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AEC1A1AEB for ; Wed, 17 Dec 2014 07:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmAR2K18YPNp for ; Wed, 17 Dec 2014 07:24:43 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 3AACA1A1A5B for ; Wed, 17 Dec 2014 07:24:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 7DE1E7C3776 for ; Wed, 17 Dec 2014 16:24:42 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qruOInKsXCco for ; Wed, 17 Dec 2014 16:24:41 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:ed33:64f:45c0:8aa8]) by mork.alvestrand.no (Postfix) with ESMTPSA id F35057C064D for ; Wed, 17 Dec 2014 16:24:40 +0100 (CET) Message-ID: <5491A038.503@alvestrand.no> Date: Wed, 17 Dec 2014 16:24:40 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <54905132.40105@alvestrand.no> <5B1166AB-A2EA-4F83-ABB2-8947D044B159@apple.com> <54909198.7040409@nostrum.com> <228CCD7E-143B-4ACA-9730-D3D6BB07694A@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000503020004090603040008" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XcL80Cja76Iztqg4Deh_JUf2c5U Subject: Re: [rtcweb] revisiting why WebRTC is succeeding everywhere but the Web X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 15:24:47 -0000 This is a multi-part message in MIME format. --------------000503020004090603040008 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/17/2014 12:32 AM, Bernard Aboba wrote: > It is possible to write a single stream audio/video app that runs on > any browser. But if you include the video features that enable > collaborative Web apps like Skype for Web, Hangouts, Jitsi Meet, etc. > then yes there are no polyfills today. So these Web apps need to be > written for a particular browser. By now people are getting used to > installing a browser to run their favorite WebRTC web app. That's not > the IETF's problem really (WebRTC protocols and open source SDKs > implementing same are in much better shape, and are being widely > used). But it is indicative of the mountain that WebRTC needs to be > climb to be a successful Web standard. Isn't it rather indicative of the fact that a couple of Web browser vendors haven't chosen to ship WebRTC support yet? We'll get the differences between Firefox and Chrome/Opera ironed out eventually. But it's hard to emulate "deep" functionality like this on top of a browser that refuses to support it. > > On Dec 16, 2014, at 5:43 PM, Ted Hardie > wrote: > >> On Tue, Dec 16, 2014 at 2:30 PM, Bernard Aboba >> > wrote: >> >> On Dec 16, 2014, at 3:18 PM, David Singer > > wrote: >> >> However the browser model is very different. The browser app >> developer typically cannot compile their own browser or fix >> browser bugs so they have to live with what is there. Today's >> polyfills typically only work for audio so writing a >> multi-browser video app that supports multiple video streams is a >> nightmare even without a codec problem. >> >> >> ​ So, can I confirm here that you mean polyfill in the same way ​Remy >> Sharp did? That is, a piece of Javascript that replicates an API and >> functionality that the browser lacks? >> >> And so you are asserting that there are downloadable Javascript bits >> that replicate both the audio functionality and relevant API, but >> there are no downloadable Javascript bits that replicate the video >> functionality and relevant API? >> >> Have I gotten your meaning? >> >> Ted >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------000503020004090603040008 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/17/2014 12:32 AM, Bernard Aboba wrote:
It is possible to write a single stream audio/video app that runs on any browser.  But if you include the video features that enable collaborative Web apps like Skype for Web, Hangouts, Jitsi Meet, etc. then yes there are no polyfills today.  So these Web apps need to be written for a particular browser.  By now people are getting used to installing a browser to run their favorite WebRTC web app. That's not the IETF's problem really (WebRTC protocols and open source SDKs implementing same are in much better shape, and are being widely used). But it is indicative of the mountain that WebRTC needs to be climb to be a successful Web standard.

Isn't it rather indicative of the fact that a couple of Web browser vendors haven't chosen to ship WebRTC support yet?

We'll get the differences between Firefox and Chrome/Opera ironed out eventually. But it's hard to emulate "deep" functionality like this on top of a browser that refuses to support it.


On Dec 16, 2014, at 5:43 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

On Tue, Dec 16, 2014 at 2:30 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
On Dec 16, 2014, at 3:18 PM, David Singer <singer@apple.com> wrote:

However the browser model is very different. The browser app developer typically cannot compile their own browser or fix browser bugs so they have to live with what is there. Today's polyfills typically only work for audio so writing a multi-browser video app that supports multiple video streams is a nightmare even without a codec problem.

 
​ So, can I confirm here that you mean polyfill in the same way ​Remy Sharp did?  That is, a piece of Javascript that replicates an API and functionality that the browser lacks?

And so you are asserting that there are downloadable Javascript bits that replicate both the audio functionality and relevant API, but there are no downloadable Javascript bits that replicate the video functionality and relevant API?

Have I gotten your meaning?

Ted



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------000503020004090603040008-- From nobody Wed Dec 17 08:11:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0FB1A1B76 for ; Wed, 17 Dec 2014 08:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNLW-jFCC4nE for ; Wed, 17 Dec 2014 08:11:33 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF971A1B06 for ; Wed, 17 Dec 2014 08:11:33 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 7059E23F0599; Wed, 17 Dec 2014 17:11:32 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.192]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 17:11:32 +0100 From: "Hutton, Andrew" To: "Pal Martinsen (palmarti)" , "Dan Wing (dwing)" Thread-Topic: [rtcweb] rtcweb-transports reference to TRAM discovery Thread-Index: AdAYdVah0SPsel0ORrys7Zw+IDeNbwAAFj2AAAAnpIAAAkCNAAA2BlGhAAFD04AAIj4OgAALKX4w Date: Wed, 17 Dec 2014 16:11:31 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E643CFD@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E63FD67@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/j1xNHUKIRjZZI7n_7b8AVpBJOh8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 16:11:35 -0000 T246IDE3IERlY2VtYmVyIDIwMTQgMTE6MzcgUGFsIE1hcnRpbnNlbiBXcm90ZToNCj4gDQo+IE1v cmUgaW1wb3J0YW50bHkgd2hhdCBpcyBtaXNzaW5nIGlzIHRleHQgc3RhdGluZyB0aGF0IGRlcGxv eWVkIFdlYlJUQw0KPiB0dXJuIHNlcnZlcnMgc2hvdWxkIGFsc28gc2VuZCBhcHByb3ByaWF0ZSBy ZXNwb25zZXMgdG8gQmluZGluZw0KPiBSZXF1ZXN0czsgaW4gb3RoZXIgd29yZHMgYWN0IGFzIGEg U1RVTiBzZXJ2ZXIuIE5vdCBzdXJlIGFib3V0IHRoZQ0KPiBhcHByb3ByaWF0ZSBzcGVjLCBidXQg aXQgY2FuIGdvIGludG8gVFVSTmJpcyBvciBzb21lIFdlYlJUQyBvdmVydmlldw0KPiBkb2N1bWVu dC4NCj4gDQo+IC4tLg0KDQpXZSBjb3VsZCBzYXkgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMtMDcjc2VjdGlvbi0zLjQgdGhhdCBXZWJS VEMgZW5kcG9pbnRzIFNIT1VMRCBtYWtlIHVzZSBvZiB0aGUgYWRkcmVzcyByZXR1cm5lZCBmcm9t IGEgVFVSTiBzZXJ2ZXIgcmF0aGVyIHRoYW4gZG9pbmcgYSBzZXBhcmF0ZSBTVFVOIGJpbmRpbmcu DQoNCkFuZHkNCg== From nobody Wed Dec 17 08:19:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E96D1A8914 for ; Wed, 17 Dec 2014 08:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBI5Am1IcYJx for ; Wed, 17 Dec 2014 08:19:48 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id D694A1A1B7A for ; Wed, 17 Dec 2014 08:19:47 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 47E5623F055F; Wed, 17 Dec 2014 17:19:47 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.192]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 17:19:47 +0100 From: "Hutton, Andrew" To: Justin Uberti Thread-Topic: [rtcweb] rtcweb-transports reference to TRAM discovery Thread-Index: AdAYdVah0SPsel0ORrys7Zw+IDeNbwAAFj2AAAAnpIAAAkCNAAAMNtUAAFkUwwA= Date: Wed, 17 Dec 2014 16:19:45 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E643D2C@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E63FD67@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8xWQGNGiBDX9koSALBVGteuQfJM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 16:19:49 -0000 T1A6IDE1IERlY2VtYmVyIDIwMTQgMjI6NDQgSnVzdGluIFViZXJ0aSBXcm90ZToNCj4gDQo+IEkg dGhpbmsgbWFraW5nIGl0IGEgcmVxdWlyZW1lbnQgaXMgcHJvYmFibHkgcHJlbWF0dXJlIHVudGls IHdlIGhhdmUgYQ0KPiBXRyBkb2N1bWVudCB0aGF0IGV4cGxhaW5zIHdoYXQgc2hvdWxkIGhhcHBl biB3aGVuIHlvdSBkaXNjb3ZlciBvbmUgb2YNCj4gdGhlc2UgbmV0d29yay1wcm92aWRlZCBUVVJO IHNlcnZlcnMuDQo+IE9uY2XCoGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2h3 YXJ0ei1ydGN3ZWItcmV0dXJuLTA0IGlzDQo+IGFjY2VwdGVkIGFzIGEgV0cgZG9jLCB3ZSBjYW4g YWRkIGEgcmVxdWlyZW1lbnQgZm9yIHN1cHBvcnQgZm9yIFJFVFVSTg0KPiBhbmQgc2VydmVyIGRp c2NvdmVyeS4NCj4gDQo+IFVuY2xlYXIgd2hldGhlciBpdCBuZWVkcyB0byBiZSBNVVNULXN0cmVu Z3RoIHVudGlsIHdlIGdldCBzb21lDQo+IGltcGxlbWVudGF0aW9uIGZlZWRiYWNrIHRob3VnaC4N Cj4gDQoNCi10cmFuc3BvcnRzIGFscmVhZHkgc3RhdGVzICIgV2ViUlRDIGJyb3dzZXJzIE1VU1Qg c3VwcG9ydCBjb25maWd1cmF0aW9uIG9mIFNUVU4gYW5kIFRVUk4gc2VydmVycywgYm90aCBmcm9t IGJyb3dzZXIgY29uZmlndXJhdGlvbiBhbmQgZnJvbSBhbiBhcHBsaWNhdGlvbiIuDQoNClNvIGl0 IGxvb2tzIGxpa2Ugd2UgYWxyZWFkeSBoYXZlIGEgcmVxdWlyZW1lbnQgYnV0IG5vIGV4cGxhbmF0 aW9uIG9mIHdoYXQgc2hvdWxkIGhhcHBlbiB3aGVuIGJvdGggYXJlIGF2YWlsYWJsZS4NCg0KTG9v a3MgbGlrZSB3ZSBuZWVkIHRvIGFkb3B0IGRyYWZ0LXNjaHdhcnR6LXJ0Y3dlYi1yZXR1cm4gYW5k IGV4cGxhaW4gdGhpcyBzdHVmZi4gSSB3b3VsZCBjZXJ0YWlubHkgc3VwcG9ydCB0aGF0IGFuZCBw dXQgc29tZSBlZmZvcnQgaW50byBnZXR0aW5nIHRoaXMgZG9uZS4NCg0KQW5keSANCg== From nobody Wed Dec 17 08:39:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FB61A8AF5 for ; Wed, 17 Dec 2014 08:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FJwY2pqwbgG for ; Wed, 17 Dec 2014 08:39:45 -0800 (PST) Received: from brc1.unina.it (brc1.unina.it [192.132.34.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70D21A8AD8 for ; Wed, 17 Dec 2014 08:39:44 -0800 (PST) X-ASG-Debug-ID: 1418834381-05ce37732643c4b0001-4f8tJD Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id C22jRtda5zwoUORz (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2014 17:39:41 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [192.168.1.104] ([151.77.231.24]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id sBHGdee6000383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2014 17:39:41 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_B949B37F-4C15-482E-BF82-3B80EB9DE39A" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [rtcweb] revisiting why WebRTC is succeeding everywhere but the Web In-Reply-To: Date: Wed, 17 Dec 2014 17:39:39 +0100 Message-Id: <554C8171-7804-4887-AE19-407C5DF816C8@unina.it> References: <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <54905132.40105@alvestrand.no> <5B1166AB-A2EA-4F83-ABB2-8947D044B159@apple.com> <54909198.7040409@nostrum.com> <228CCD7E-143B-4ACA-9730-D3D6BB07694A@gmail.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1993) X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1418834381 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.50:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.13015 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NE18tHIK-PY9nhKy9J8bPIEvBzo Cc: "" Subject: Re: [rtcweb] revisiting why WebRTC is succeeding everywhere but the Web X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 16:39:48 -0000 --Apple-Mail=_B949B37F-4C15-482E-BF82-3B80EB9DE39A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > It is possible to write a single stream audio/video app that runs on = any browser. But if you include the video features that enable = collaborative Web apps like Skype for Web, Hangouts, Jitsi Meet, etc. = then yes there are no polyfills today. So these Web apps need to be = written for a particular browser. By now people are getting used to = installing a browser to run their favorite WebRTC web app. Based on my experience, if you stick to the Maximum Common Divisor = (e.g., by avoiding SSRC multiplexing, on hold, some forms of bundling, = etc) you can still offer a rich end-user experience on a wide set of = browsers (Chrome, Firefox, Opera at least). This is indeed what we try = and do with the 'stable' version of Meetecho (which you probably forgot = to mention). BTW, I think this is unavoidable as long as the = standardization process has not yet reached the steady state. Simon > That's not the IETF's problem really (WebRTC protocols and open source = SDKs implementing same are in much better shape, and are being widely = used). But it is indicative of the mountain that WebRTC needs to be = climb to be a successful Web standard.=20 >=20 > On Dec 16, 2014, at 5:43 PM, Ted Hardie > wrote: >=20 >> On Tue, Dec 16, 2014 at 2:30 PM, Bernard Aboba = > wrote: >> On Dec 16, 2014, at 3:18 PM, David Singer > wrote: >>=20 >> However the browser model is very different. The browser app = developer typically cannot compile their own browser or fix browser bugs = so they have to live with what is there. Today's polyfills typically = only work for audio so writing a multi-browser video app that supports = multiple video streams is a nightmare even without a codec problem. >>=20 >> =20 >> =E2=80=8BSo, can I confirm here that you mean polyfill in the same = way =E2=80=8BRemy Sharp did? That is, a piece of Javascript that = replicates an API and functionality that the browser lacks? >>=20 >> And so you are asserting that there are downloadable Javascript bits = that replicate both the audio functionality and relevant API, but there = are no downloadable Javascript bits that replicate the video = functionality and relevant API? >>=20 >> Have I gotten your meaning? >>=20 >> Ted >>=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_B949B37F-4C15-482E-BF82-3B80EB9DE39A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
It is possible to = write a single stream audio/video app that runs on any browser. =  But if you include the video features that enable collaborative = Web apps like Skype for Web, Hangouts, Jitsi Meet, etc. then yes there = are no polyfills today.  So these Web apps need to be written for a = particular browser.  By now people are getting used to installing a = browser to run their favorite WebRTC web app.

Based on my experience, if you stick to the = Maximum Common Divisor (e.g., by avoiding SSRC multiplexing, on hold, = some forms of bundling, etc) you can still offer a rich end-user = experience on a wide set of browsers (Chrome, Firefox, Opera at least). = This is indeed what we try and do with the 'stable' version of Meetecho = (which you probably forgot to mention). BTW, I think this is unavoidable = as long as the standardization process has not yet reached the steady = state.

Simon

That's not the IETF's = problem really (WebRTC protocols and open source SDKs implementing same = are in much better shape, and are being widely used). But it is = indicative of the mountain that WebRTC needs to be climb to be a = successful Web standard. 

On Dec 16, 2014, = at 5:43 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

On Tue, Dec 16, 2014 = at 2:30 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
On Dec 16, 2014, = at 3:18 PM, David Singer <singer@apple.com> wrote:

However the browser model is very different. The browser app developer = typically cannot compile their own browser or fix browser bugs so they = have to live with what is there. Today's polyfills typically only work = for audio so writing a multi-browser video app that supports multiple = video streams is a nightmare even without a codec problem.

 
=E2=80=8BSo, can = I confirm here that you mean polyfill in the same way =E2=80=8BRemy = Sharp did?  That is, a piece of Javascript that replicates an API = and functionality that the browser lacks?

And so you are = asserting that there are downloadable Javascript bits that replicate = both the audio functionality and relevant API, but there are no = downloadable Javascript bits that replicate the video functionality and = relevant API?

Have I gotten = your meaning?

Ted

=
_______________________________________________rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

  =                   =   =        = _\\|//_
            =                 =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                =      = Simon Pietro Romano
      =          Universita' di Napoli = Federico II
          =            =  Computer Engineering Department 
  =            Phone: +39 081 7683823 -- Fax: = +39 081 7683816
          =                     =              e-mail: spromano@unina.it

    = <<Molti mi dicono che lo scoraggiamento =C3=A8 l'alibi = degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
           =      =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~( =   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   )
=                 =                   \_) =          ) /
    =                     =                     =                     =        (_/






= --Apple-Mail=_B949B37F-4C15-482E-BF82-3B80EB9DE39A-- From nobody Wed Dec 17 08:56:38 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921161A8F4C for ; Wed, 17 Dec 2014 08:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxDLXp6PU2vd for ; Wed, 17 Dec 2014 08:56:31 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C681A8F50 for ; Wed, 17 Dec 2014 08:56:30 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so20858808wgg.19 for ; Wed, 17 Dec 2014 08:56:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fZSXhTaMOLy6UJsvqpXnhxV/r0VKFfnEnarUcKIgGjQ=; b=Qbu4cfxtlANJc9078KNLkjqPwLwTYdxXcP1nRZAB9uFzBqFUqEhTV6WOxYDO7e5WSL inpYDV57rtPudseYfA3EOXRCaKTEdzdkMyyxD3t89/fTEVq/w830sx2dpMBZY6hXGFMI ALePrbZUzGRw91s2k5x4MF9WrFlp+UuIHphhbyeI6oBWK3Utv7F/+QRWvyqy7CHwpRHh TxS3UiWMW4ryRNFDP0gI7KGGo6TO0vrEq0WmI+FRT9rvT1R6OHrGDRFUVJ6W0kE0gUDS rlX0R14+P+5xialbDxThqeG9da4/ySzF7eM9JYSuJ8nwDluo7Y2bcqRQW7NbPCOzN51X socA== X-Gm-Message-State: ALoCoQlcO1GdcwG0fgbHtmZqvdIYnqP7bELI1CELWGa12XDpe8MAHEMBl6pl/6/kFTV3qPOwuZmR X-Received: by 10.180.19.193 with SMTP id h1mr16277892wie.10.1418835389240; Wed, 17 Dec 2014 08:56:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Wed, 17 Dec 2014 08:55:49 -0800 (PST) In-Reply-To: <554C8171-7804-4887-AE19-407C5DF816C8@unina.it> References: <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <54905132.40105@alvestrand.no> <5B1166AB-A2EA-4F83-ABB2-8947D044B159@apple.com> <54909198.7040409@nostrum.com> <228CCD7E-143B-4ACA-9730-D3D6BB07694A@gmail.com> <554C8171-7804-4887-AE19-407C5DF816C8@unina.it> From: Eric Rescorla Date: Wed, 17 Dec 2014 08:55:49 -0800 Message-ID: To: Simon Pietro Romano Content-Type: multipart/alternative; boundary=bcaec53d526f5ef7de050a6c5b52 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/h3MG4QggZSJ2Nunn9yZXWKFhh6c Cc: "" Subject: Re: [rtcweb] revisiting why WebRTC is succeeding everywhere but the Web X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 16:56:34 -0000 --bcaec53d526f5ef7de050a6c5b52 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's also worth observing that a lot of the problem with multiple stream polyfills isn't a result of the state of standardization but just that Firefox doesn't do it yet, so you have to simulate with multiple PCs. We're working on it now, though. -Ekr On Wed, Dec 17, 2014 at 8:39 AM, Simon Pietro Romano wrote: > > It is possible to write a single stream audio/video app that runs on any > browser. But if you include the video features that enable collaborative > Web apps like Skype for Web, Hangouts, Jitsi Meet, etc. then yes there ar= e > no polyfills today. So these Web apps need to be written for a particula= r > browser. By now people are getting used to installing a browser to run > their favorite WebRTC web app. > > > Based on my experience, if you stick to the Maximum Common Divisor (e.g., > by avoiding SSRC multiplexing, on hold, some forms of bundling, etc) you > can still offer a rich end-user experience on a wide set of browsers > (Chrome, Firefox, Opera at least). This is indeed what we try and do with > the 'stable' version of Meetecho (which you probably forgot to mention). > BTW, I think this is unavoidable as long as the standardization process h= as > not yet reached the steady state. > > Simon > > That's not the IETF's problem really (WebRTC protocols and open source > SDKs implementing same are in much better shape, and are being widely > used). But it is indicative of the mountain that WebRTC needs to be climb > to be a successful Web standard. > > On Dec 16, 2014, at 5:43 PM, Ted Hardie wrote: > > On Tue, Dec 16, 2014 at 2:30 PM, Bernard Aboba > wrote: > >> On Dec 16, 2014, at 3:18 PM, David Singer wrote: >> >> However the browser model is very different. The browser app developer >> typically cannot compile their own browser or fix browser bugs so they h= ave >> to live with what is there. Today's polyfills typically only work for au= dio >> so writing a multi-browser video app that supports multiple video stream= s >> is a nightmare even without a codec problem. >> >> > =E2=80=8BSo, can I confirm here that you mean polyfill in the same way = =E2=80=8BRemy Sharp > did? That is, a piece of Javascript that replicates an API and > functionality that the browser lacks? > > And so you are asserting that there are downloadable Javascript bits that > replicate both the audio functionality and relevant API, but there are no > downloadable Javascript bits that replicate the video functionality and > relevant API? > > Have I gotten your meaning? > > Ted > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_= / > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --bcaec53d526f5ef7de050a6c5b52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's also worth observing that a lot of the problem wi= th multiple stream polyfills
isn't a result of the state of standar= dization but just that Firefox doesn't do
it yet, so you have= to simulate with multiple PCs. We're working on it now,=C2=A0
though.

-Ekr


=


On Wed, Dec 17, 2014 at 8:39 AM, Simon Pietro Romano = <spromano@unina.i= t> wrote:
It is possib= le to write a single stream audio/video app that runs on any browser.=C2=A0= But if you include the video features that enable collaborative Web apps l= ike Skype for Web, Hangouts, Jitsi Meet, etc. then yes there are no polyfil= ls today.=C2=A0 So these Web apps need to be written for a particular brows= er.=C2=A0 By now people are getting used to installing a browser to run the= ir favorite WebRTC web app.

Based o= n my experience, if you stick to the Maximum Common Divisor (e.g., by avoid= ing SSRC multiplexing, on hold, some forms of bundling, etc) you can still = offer a rich end-user experience on a wide set of browsers (Chrome, Firefox= , Opera at least). This is indeed what we try and do with the 'stable&#= 39; version of Meetecho (which you probably forgot to mention). BTW, I thin= k this is unavoidable as long as the standardization process has not yet re= ached the steady state.

Simon

That's not the IETF's problem reall= y (WebRTC protocols and open source SDKs implementing same are in much bett= er shape, and are being widely used). But it is indicative of the mountain = that WebRTC needs to be climb to be a successful Web standard.=C2=A0

On Dec 16, 2014, at 5:= 43 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

On Tue, Dec 16, 2014 at 2= :30 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:=
On Dec 16, 2014, = at 3:18 PM, David Singer <singer@apple.com> wrote:

However the browser model is very different. The browser app developer typi= cally cannot compile their own browser or fix browser bugs so they have to = live with what is there. Today's polyfills typically only work for audi= o so writing a multi-browser video app that supports multiple video streams= is a nightmare even without a codec problem.

=C2=A0
=E2=80=8BSo, can I confirm here t= hat you mean polyfill in the same way =E2=80=8BRemy Sharp did?=C2=A0 That i= s, a piece of Javascript that replicates an API and functionality that the = browser lacks?

And so you are asserting that there a= re downloadable Javascript bits that replicate both the audio functionality= and relevant API, but there are no downloadable Javascript bits that repli= cate the video functionality and relevant API?

Have = I gotten your meaning?

Ted

=
__________________________= _____________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailm= an/listinfo/rtcweb

=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=A0 =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=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0( O-O )
=C2=A0 =C2=A0~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o= ~~~~~~~~~~~~~~~~~~~~~~~~
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Simon Pietro Romano
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Universita' di Napoli Federico II
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0Computer Engineering Departmen= t=C2=A0
=C2=A0 =C2= =A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: +39 081 7683823 -- Fa= x: +39 081 7683816
=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=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e-mail: spromano@unina.it

=
=C2=A0 =C2=A0 <<Mo= lti mi dicono che lo scoraggiamento =C3=A8 l'alibi degli=C2=A0
=C2=A0=C2=A0 =C2=A0idioti. = Ci rifletto un istante; e mi scoraggio>>. Magritte.
=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=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0oooO
=C2=A0 ~~~~~~~~~~~~= ~~~~~~~~~~~( =C2=A0 )~~~=C2=A0Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=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=A0 =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=A0 =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=A0 =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=A0 =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=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(_/







_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--bcaec53d526f5ef7de050a6c5b52-- From nobody Wed Dec 17 09:09:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909381A902D for ; Wed, 17 Dec 2014 09:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMgooRd2OQIe for ; Wed, 17 Dec 2014 09:09:37 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 2374A1A902B for ; Wed, 17 Dec 2014 09:07:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 669E37C378D for ; Wed, 17 Dec 2014 18:07:03 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6xt_KPbTZ16 for ; Wed, 17 Dec 2014 18:06:59 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:ed33:64f:45c0:8aa8]) by mork.alvestrand.no (Postfix) with ESMTPSA id 326867C3797 for ; Wed, 17 Dec 2014 18:06:59 +0100 (CET) Message-ID: <5491B831.70704@alvestrand.no> Date: Wed, 17 Dec 2014 18:06:57 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E63FD67@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E643D2C@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E643D2C@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6FXyLnd8nyYR0pdCl7xCLsITYzo Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 17:09:43 -0000 On 12/17/2014 05:19 PM, Hutton, Andrew wrote: > OP: 15 December 2014 22:44 Justin Uberti Wrote: >> I think making it a requirement is probably premature until we have a >> WG document that explains what should happen when you discover one of >> these network-provided TURN servers. >> Once https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04 is >> accepted as a WG doc, we can add a requirement for support for RETURN >> and server discovery. >> >> Unclear whether it needs to be MUST-strength until we get some >> implementation feedback though. >> > -transports already states " WebRTC browsers MUST support configuration of STUN and TURN servers, both from browser configuration and from an application". > > So it looks like we already have a requirement but no explanation of what should happen when both are available. The last times we've talked about this, people have imagined configuring this via the same mechanism as configuring HTTP proxies (nonstandard script at a nonstandard URL). Autodiscovery may be preferable, but it's not clear that it removes the need for the script-like things. > > Looks like we need to adopt draft-schwartz-rtcweb-return and explain this stuff. I would certainly support that and put some effort into getting this done. > > Andy > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Dec 17 13:59:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45591A876F for ; Wed, 17 Dec 2014 13:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25mkcwXRAWMV for ; Wed, 17 Dec 2014 13:59:01 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383801A8781 for ; Wed, 17 Dec 2014 13:59:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2005; q=dns/txt; s=iport; t=1418853541; x=1420063141; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=WHlJiyMh7LbZdLXPGxDO3hP3Cqu8kTfcATqcfOXVLEk=; b=gt0plfopVxxDRWBSum3jO66vvVxSXvZKiGhqvA+h0HG/vXId6RFj85Du 7O264GOIhMMUhwJ0nPfwO2p/cWgaG7MFwfh+0icPqHNg6ubOhP2TOYL86 8LMmwFl++XUF2ZaMHRg4EogVbYqUBaNJIBchvS9UCqROmLW2pWEyauI+2 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcFAEn7kVStJA2B/2dsb2JhbABagwZSWMV3CoUoSgKBIhYBAQEBAX2EDAEBAQMBAQEBNzQLBQsLGC4nMAYTiCQIDdUPAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSPPzMHgxaBEwWJQ4gDhTKFfItEIoQNHTGCQwEBAQ X-IronPort-AV: E=Sophos;i="5.07,596,1413244800"; d="scan'208";a="380897432" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-5.cisco.com with ESMTP; 17 Dec 2014 21:59:01 +0000 Received: from [10.24.109.157] ([10.24.109.157]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sBHLwxpT012996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Dec 2014 21:58:59 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: <5491B831.70704@alvestrand.no> Date: Wed, 17 Dec 2014 13:58:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E63FD67@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E643D2C@MCHP04MSX.global-ad.net> <5491B831.70704@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5e8T5s6bg6OlM4XXcumZlDsNedA Cc: Mark Nottingham , RTCWEB Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2014 21:59:03 -0000 On Dec 17, 2014, at 9:06 AM, Harald Alvestrand = wrote: > On 12/17/2014 05:19 PM, Hutton, Andrew wrote: >> OP: 15 December 2014 22:44 Justin Uberti Wrote: >>> I think making it a requirement is probably premature until we have = a >>> WG document that explains what should happen when you discover one = of >>> these network-provided TURN servers. >>> Once https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04 is >>> accepted as a WG doc, we can add a requirement for support for = RETURN >>> and server discovery. >>>=20 >>> Unclear whether it needs to be MUST-strength until we get some >>> implementation feedback though. >>>=20 >> -transports already states " WebRTC browsers MUST support = configuration of STUN and TURN servers, both from browser configuration = and from an application". >>=20 >> So it looks like we already have a requirement but no explanation of = what should happen when both are available. >=20 > The last times we've talked about this, people have imagined = configuring this via the same mechanism as configuring HTTP proxies = (nonstandard script at a nonstandard URL). >=20 > Autodiscovery may be preferable, but it's not clear that it removes = the need for the script-like things. If there is, gathering that requirement seems important. Mark = Nottingham was beginning an effort around WPAD standardization (or = something that resembled it). CC'ing him in case there is useful status = on that front. -d >=20 >>=20 >> Looks like we need to adopt draft-schwartz-rtcweb-return and explain = this stuff. I would certainly support that and put some effort into = getting this done. >>=20 >> Andy >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Dec 18 00:27:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C241A6EE4; Thu, 18 Dec 2014 00:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8g-4sNV2eCx; Thu, 18 Dec 2014 00:27:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE961A0E10; Thu, 18 Dec 2014 00:27:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141218082700.31211.58161.idtracker@ietfa.amsl.com> Date: Thu, 18 Dec 2014 00:27:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hBrg3j5fb3XbHhyy8KVoMolcmSk Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-11.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 08:27:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : STUN Usage for Consent Freshness Authors : Muthu Arul Mozhi Perumal Dan Wing Ram Mohan Ravindranath Tirumaleswar Reddy Martin Thomson Filename : draft-ietf-rtcweb-stun-consent-freshness-11.txt Pages : 9 Date : 2014-12-18 Abstract: To prevent sending excessive traffic to an endpoint, periodic consent needs to be obtained from that remote endpoint. This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 18 00:30:00 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB60C1A6F39 for ; Thu, 18 Dec 2014 00:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJU4h6cp5JTG for ; Thu, 18 Dec 2014 00:29:56 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688B81A6EE4 for ; Thu, 18 Dec 2014 00:29:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2116; q=dns/txt; s=iport; t=1418891396; x=1420100996; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1O2V43xyOdSpwgz3TFgrJqcxfAtybwJJaJKvpNmqXvA=; b=NhZWzdPf3RmCdymDL69IM2LAkYM4RFcmTdol/5fjCRzOuudjLOKecYmj V0WQSFTQgKXviFZcmYjqV9sIKPaqDqGRYrx5o6/Cg0LGGPlXA3300VzpI 5aFaljFG91lQf0IVY7eLEcyfzIx3f5aIcQ47AqxEOLjCyMmv7fwUIduxd E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAKOPklStJA2D/2dsb2JhbABagwZSUwUExg4MhSZKAoEdFgEBAQEBfYQMAQEBBAEBATc0FwQCAQgRAwECHxAnCx0IAgQTCYgjCAXUbQEBAQEBAQQBAQEBAQEBG48hAQEcNQUGhCMFjgeDPoUxgQswgjGNVCKDbG8BgQs5fgEBAQ X-IronPort-AV: E=Sophos;i="5.07,599,1413244800"; d="scan'208";a="106496795" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP; 18 Dec 2014 08:29:55 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sBI8Ttd4023578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Dec 2014 08:29:55 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.28]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 02:29:55 -0600 From: "Ram Mohan R (rmohanr)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-11.txt Thread-Index: AQHQGpzMuP9VmEp6mEWxp90ME2ybeA== Date: Thu, 18 Dec 2014 08:29:54 +0000 Message-ID: References: <20141218082700.31211.58161.idtracker@ietfa.amsl.com> In-Reply-To: <20141218082700.31211.58161.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.196.64.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <91582879D308F04EA005A05DC8ECAEDA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/l-NQYlgipRtCpU038aWN9XZ6Rfw Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-11.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 08:29:58 -0000 The version fixes the nits discussed in the mailing list - http://www.ietf.org/mail-archive/web/rtcweb/current/msg14024.html Ram -----Original Message----- From: "internet-drafts@ietf.org" Date: Thursday, 18 December 2014 1:57 pm To: "i-d-announce@ietf.org" Cc: "rtcweb@ietf.org" Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-11.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Real-Time Communication in WEB-browsers >Working Group of the IETF. > > Title : STUN Usage for Consent Freshness > Authors : Muthu Arul Mozhi Perumal > Dan Wing > Ram Mohan Ravindranath > Tirumaleswar Reddy > Martin Thomson > Filename : draft-ietf-rtcweb-stun-consent-freshness-11.txt > Pages : 9 > Date : 2014-12-18 > >Abstract: > To prevent sending excessive traffic to an endpoint, periodic consent > needs to be obtained from that remote endpoint. > > This document describes a consent mechanism using a new Session > Traversal Utilities for NAT (STUN) usage. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-11 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshnes= s- >11 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Dec 18 09:23:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684E11A87A4 for ; Thu, 18 Dec 2014 09:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8M7mS5dHqY7S for ; Thu, 18 Dec 2014 09:23:40 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22451A8AE0 for ; Thu, 18 Dec 2014 09:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=831; q=dns/txt; s=iport; t=1418923419; x=1420133019; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1otFeCbmIy4n4qkKimpmdFotSiTUcWPowd44a6sZNTs=; b=CDtgjisyx0AaaxbIQYBnaF1sHL3ET7y1skgShZQEXMY7r+NOpkRCPNOw xwedYZKRnJjPPlIpWSjNo8AALV+NCW8xzMxn5qOs8mTtUBcGTFj3g/dT/ +2d0ui4dsdQYjtlj66FltDIKP7KbVGXB2FKo5cZ85iG0XRMWhBTiyS6Qo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFABANk1StJV2S/2dsb2JhbABagmQiUlgExhIKhShKAoEiFgEBAQEBfYQMAQEBAwEBAQE3NAsFCwIBCBgeECcLJQIEDgWIJAgBDNUiAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSPPzMHgxaBEwEEjgqDPoUykUIig2xvAYFEfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,601,1413244800"; d="scan'208";a="106648921" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP; 18 Dec 2014 17:23:39 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sBIHNcPu019106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Dec 2014 17:23:39 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 11:23:38 -0600 From: "Cullen Jennings (fluffy)" To: "Hutton, Andrew" Thread-Topic: [rtcweb] rtcweb-transports reference to TRAM discovery Thread-Index: AQHQGudcsQQgzLcHBE28skFLAtCSOQ== Date: Thu, 18 Dec 2014 17:23:37 +0000 Message-ID: <6946D534-CBE7-4D1A-8C26-4D2FE07136D1@cisco.com> References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/__mhiJ0RyiMmYT5JpF7eF-ijt-c Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 17:23:42 -0000 It seems that in the mobile case and many residential cases, doing that dra= ft would allow a service provider to force all the traffic through a TURN s= erver of the service providers choosing. Am I reading this correctly becaus= e I am pretty sure I would not be in favor of that. > On Dec 15, 2014, at 7:42 AM, Hutton, Andrew wro= te: >=20 > I am thinking that https://tools.ietf.org/html/draft-ietf-rtcweb-transpor= ts-07#section-3.4 should include a requirement that a WebRTC Browser MUST s= upport the TURN server discovery as described in https://tools.ietf.org/htm= l/draft-ietf-tram-turn-server-discovery-00. > =20 > =20 > Andy > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Dec 18 10:39:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C261A1A1B23 for ; Thu, 18 Dec 2014 10:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOXrhMKF_S11 for ; Thu, 18 Dec 2014 10:39:21 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3F31A6FB5 for ; Thu, 18 Dec 2014 10:39:20 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 3CBFE1EB8430; Thu, 18 Dec 2014 19:39:19 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.192]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 19:39:18 +0100 From: "Hutton, Andrew" To: "Cullen Jennings (fluffy)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] rtcweb-transports reference to TRAM discovery Thread-Index: AdAYdVah0SPsel0ORrys7Zw+IDeNbwCaaMuAAASJeqA= Date: Thu, 18 Dec 2014 18:39:18 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E645482@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <6946D534-CBE7-4D1A-8C26-4D2FE07136D1@cisco.com> In-Reply-To: <6946D534-CBE7-4D1A-8C26-4D2FE07136D1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/86NRSyqs2jm3iKxg71xatNNblZk Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 18:39:22 -0000 https://tools.ietf.org/id/draft-ietf-tram-turn-server-discovery-00.txt make= s the claim that it is needed for "WebRTC usage" and in fact claims that it= is needed by WebRTC "immediately". I was just pointing out that if this is the case then it should be referenc= ed from a RTCWEB draft. If you think the discovery mechanism is not suitable for WebRTC usage then = please make that comment to the TRAM WG list. Andy =20 > -----Original Message----- > From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com] > Sent: 18 December 2014 17:24 > To: Hutton, Andrew > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery >=20 >=20 > It seems that in the mobile case and many residential cases, doing that > draft would allow a service provider to force all the traffic through a > TURN server of the service providers choosing. Am I reading this > correctly because I am pretty sure I would not be in favor of that. >=20 >=20 > > On Dec 15, 2014, at 7:42 AM, Hutton, Andrew > wrote: > > > > I am thinking that https://tools.ietf.org/html/draft-ietf-rtcweb- > transports-07#section-3.4 should include a requirement that a WebRTC > Browser MUST support the TURN server discovery as described in > https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00. > > > > > > Andy > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Dec 18 12:40:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BA51A875B for ; Thu, 18 Dec 2014 12:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A50tvUKf6bsA for ; Thu, 18 Dec 2014 12:40:08 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147581A86EE for ; Thu, 18 Dec 2014 12:40:07 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBIKe3eA045723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2014 14:40:04 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54933BA3.9040209@nostrum.com> Date: Thu, 18 Dec 2014 14:40:03 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" , "Hutton, Andrew" References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <6946D534-CBE7-4D1A-8C26-4D2FE07136D1@cisco.com> In-Reply-To: <6946D534-CBE7-4D1A-8C26-4D2FE07136D1@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/feMlseu4GTD55l0ITeWhDsK3Ig4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 20:40:10 -0000 So, I think it's important that we have some way to encourage deployment of TURN servers both in the ISPs, and as part of firewalls (both residential and enterprise). By putting TURN in paths that are already going to bear the traffic in question, the overall cost associated with calls goes down, and call quality (latency, loss) improves. I'm sympathetic to the position that we don't want to give these entities specific hooks to force specific servers to be inserted into the flow. We need to find a balance here: something that allows the relevant entities to deploy and advertise such servers; something that allows WebRTC applications to discover and use them; and something that puts the ultimate decision in the hands of the users. Off the top of my head, adding a browser API that allows applications to to retrieve these servers and elect to use them if it wants to would serve part of the purpose; giving users a means by which they can instruct the browser not to return such a list would serve the remainder. But that's all kind of orthogonal to the IETF issues: if we're going to do *anything* in this space, we need the discovery mechanisms. /a On 12/18/14 11:23, Cullen Jennings (fluffy) wrote: > It seems that in the mobile case and many residential cases, doing that draft would allow a service provider to force all the traffic through a TURN server of the service providers choosing. Am I reading this correctly because I am pretty sure I would not be in favor of that. > > >> On Dec 15, 2014, at 7:42 AM, Hutton, Andrew wrote: >> >> I am thinking that https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section-3.4 should include a requirement that a WebRTC Browser MUST support the TURN server discovery as described in https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00. >> >> >> Andy >> >> _______________________________________________ >> 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 From nobody Thu Dec 18 13:19:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E47A1A6FF0 for ; Thu, 18 Dec 2014 13:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EH7Z9NbNjhag for ; Thu, 18 Dec 2014 13:19:41 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAF571A86F7 for ; Thu, 18 Dec 2014 13:19:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2923; q=dns/txt; s=iport; t=1418937581; x=1420147181; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cu0SvxyV25erUsDaRpLJCfhomNmVeARAgt46hPvwX0g=; b=iMxvsn7fmqd1kqGbkpg5HreCBEnsSKiKvlW9ja8e+y/xjSdzLryaCFz3 wurR9k7uw2aA809phUtlmn5fXwVui7p3JnRx6I/MqicdmqK6mt74xSuc6 lPr1C3i314YCkw8eQQXUlE9mp6dedOTh129bEJYHhhSjOFn19UFluHu12 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FAKVDk1StJA2L/2dsb2JhbABbgwZSWATGFAqFKEoCgSYWAQEBAQF9hA0BAQQBAQELLCsJCxACAQgYHhAnCyUCBAENBYgsDc8AAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSPcgeEKQWOCoM+gT8+gzWRQiKDbG8BgUR+AQEB X-IronPort-AV: E=Sophos;i="5.07,602,1413244800"; d="scan'208";a="381176171" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-3.cisco.com with ESMTP; 18 Dec 2014 21:19:40 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sBILJckr005183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Dec 2014 21:19:38 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.83]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 15:19:38 -0600 From: "Mo Zanaty (mzanaty)" To: Adam Roach , "Cullen Jennings (fluffy)" , "Hutton, Andrew" Thread-Topic: [rtcweb] rtcweb-transports reference to TRAM discovery Thread-Index: AQHQGwhTFJHl4UEJ8EuMGhMMTLb7dw== Date: Thu, 18 Dec 2014 21:19:37 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <6946D534-CBE7-4D1A-8C26-4D2FE07136D1@cisco.com> <54933BA3.9040209@nostrum.com> In-Reply-To: <54933BA3.9040209@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.81.3.61] Content-Type: text/plain; charset="us-ascii" Content-ID: <9057F6E2379D004D81262B56250CA2DC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LgJohJ3p2Xe7CzSeeRIIaPhGOiI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2014 21:19:43 -0000 The priority order that makes most sense to me is: 1. user override 2. app override 3. auto discovery 4. app fallback 5. user fallback If any override is configured by the user or app, do not perform auto discovery, stop here. If auto discovery fails, use a fallback configured by the app or user. There is a big difference between an override and a fallback, so both seem necessary. Obviously, we need some mechanism for 3 as Adam said, in case it needs to be invoked. Mo On 12/18/14, 3:40 PM, Adam Roach wrote: So, I think it's important that we have some way to encourage deployment of TURN servers both in the ISPs, and as part of firewalls (both residential and enterprise). By putting TURN in paths that are already going to bear the traffic in question, the overall cost associated with calls goes down, and call quality (latency, loss) improves. I'm sympathetic to the position that we don't want to give these entities specific hooks to force specific servers to be inserted into the flow. We need to find a balance here: something that allows the relevant entities to deploy and advertise such servers; something that allows WebRTC applications to discover and use them; and something that puts the ultimate decision in the hands of the users. Off the top of my head, adding a browser API that allows applications to to retrieve these servers and elect to use them if it wants to would serve part of the purpose; giving users a means by which they can instruct the browser not to return such a list would serve the remainder. But that's all kind of orthogonal to the IETF issues: if we're going to do *anything* in this space, we need the discovery mechanisms. /a On 12/18/14 11:23, Cullen Jennings (fluffy) wrote: > It seems that in the mobile case and many residential cases, doing that >draft would allow a service provider to force all the traffic through a >TURN server of the service providers choosing. Am I reading this >correctly because I am pretty sure I would not be in favor of that. > > >> On Dec 15, 2014, at 7:42 AM, Hutton, Andrew >>wrote: >> >> I am thinking that >>https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section-3.4 >>should include a requirement that a WebRTC Browser MUST support the TURN >>server discovery as described in >>https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00. >> =20 >> =20 >> Andy >> =20 >> _______________________________________________ >> 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 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Dec 18 15:55:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827AD1A89BB for ; Thu, 18 Dec 2014 15:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nc6zE7S3hr3j for ; Thu, 18 Dec 2014 15:55:31 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F7C1A8715 for ; Thu, 18 Dec 2014 15:55:31 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id b13so2989421wgh.32 for ; Thu, 18 Dec 2014 15:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=CCCZQM7niyX2CTh1ej4ykqM7bFb7XTOXhhfj6PMfZNY=; b=feVr59DDulEQvx+xFnIEjEZ6OaIoW9bBffyso6jhlntCdJ7uH9RC0fn1joMcwTmbhW t4YruKooMVPp9lyZi1Wh1/N4TYXqd7R5nLDwryxndp9DAQVMyyouLzqviP6uNuZ8YSuK 1p0ZNpJtELNjqxRKfSnoj5KwoXeR0KCKvWocKQ0H30PYmY79XA+PBjZ2KTp1i7igOnF+ 6bzpN8307lB2y63GFEBPtK+ydcfenSfNS23EuASyKTWL5TMUSRDWhLq3hkC25EobD8rm NAM42GKWQhsUxWNbzEGhfJlQq08MT++lD3bAco8YAiL+RnGORttOb6ChrFAMe85Z9OnG +4nA== X-Received: by 10.194.23.202 with SMTP id o10mr9144987wjf.73.1418946930118; Thu, 18 Dec 2014 15:55:30 -0800 (PST) Received: from Saturns-MBP.fritz.box ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id ex9sm355852wib.14.2014.12.18.15.55.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Dec 2014 15:55:29 -0800 (PST) Message-ID: <5493696F.3090701@gmail.com> Date: Fri, 19 Dec 2014 00:55:27 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sean Turner References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070709090307050704090308" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/O0XINDqa5C_dfXtangiFtIvGcT0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.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: Thu, 18 Dec 2014 23:55:35 -0000 This is a multi-part message in MIME format. --------------070709090307050704090308 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit I am not supporting the proposal. The licensing around H264 is a mess, blocking safe usage in open source software (which had really big impact in the evolution of open web & internet) that cannot control its distribution. Moreover, it is imposing unnecessary costs, or in other words, even worse, a revenue to a particular group of interests, and exposing new players to unknown risks. These are serious impediments for innovation and not something I would expect from an open specification from IETF. On some of the bits of the proposal: mandating that the two codecs stay mandatory is odd and somehow overruling IETF system where a new RFC can obsolete a new RFC. Different requirements for different entities will create a mess of terminologies (e.g., how an app implementing JS API and one codec is going to be presented: a *web browser* but not a *webrtc browser*, just a *webrtc device*). Ending up now with an bad solution for present and the future, just to close the door on this topic, is not appropriate for how open Internet communications are supposed to evolve. Better let time to come with a better solution and applications negotiate what they like meanwhile (even with no MTI video codec so far, there are successful webrtc services). Daniel Ps. I reiterate my opinions on this thread, because I expressed them on other threads of recent discussions, which may count or not. On 09/12/14 21:31, Bernard Aboba wrote: > Setting aside my reservations about the dual-MTI requirement for > browsers, I also oppose the other elements of the proposal. > > Mandating that applications support both codecs makes no sense - they > should only be required to support one of them (their choice). If > this change were made the trigger clause would serve no purpose, other > than to keep this discussion going ad-infinitum. So I oppose that as > well. > > Allowing an endpoint that implements video to call itself "WebRTC > compliant" without implementing either of the MTI codecs is so > wrong-headed that I am at a loss for words. > > > > On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway > wrote: > > Thanks Sean, > > We can not support this draft at this time. > > As RTC SDK vendors we very likely will support both codecs, but we > can not stand by a decision that will "impose" dual MTI on our > developer community. > > According to this, every dev must use both codecs for every app > that is built using our tools. Codec selection should be their > choice and not be forced upon them. This seems to be a rather > unreasonable expectation. > > > **Erik Lagerway | **Hookflash > ** | 1 (855)* *Hookflash ext. 2 | Twitter > | WebRTC.is Blog ** > ******** > > On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner > wrote: > > All, > > At the 2nd RTCweb WG session @ IETF 91, we had a lively > discussion about codecs, which I dubbed "the great codec > compromise." The compromise text that was discussed appears > in slides 12-14 at [4] (which is a slight editorial variation > of the text proposed at [2]). > > This message serves to confirm the sense of the room. > > In the room, I heard the following objections and responses > (and I’m paraphrasing here), which I’ll take the liberty of > categorizing as IPR, Time, and Trigger: > > 1) IPR: > > Objections: There are still IPR concerns which may restrict > what a particular organization feels comfortable with > including in their browser implementations. > > Response: IPR concerns on this topic are well known. There > is even a draft summarizing the current IPR status for VP8: > draft-benham-rtcweb-vp8litigation. The sense of the room was > still that adopting the compromise text was appropriate. > > 2) Time: > > 2.1) Time to consider decision: > > Objection: The decision to consider the compromise proposal at > this meeting was provided on short notice and did not provide > some the opportunity to attend in person. > > Response: Six months ago the chairs made it clear discussion > would be revisited @ IETF 91 [0]. The first agenda proposal > for the WG included this topic [1], and the topic was never > removed by the chairs. More importantly, all decisions are > confirmed on list; in person attendance is not required to be > part of the process. > > 2.2) Time to consider text: > > Objection: The proposed text [2] is too new to be considered. > > Response: The requirement for browsers to support both VP8 and > H.264 was among the options in the straw poll conducted more > than six months ago. All decisions are confirmed on list so > there will be ample time to discuss the proposal. > > 3) Trigger: > > Objection: The “trigger” sentence [3] is all kinds of wrong > because it’s promising that the future IETF will update this > specification. > > Response: Like any IETF proposal, an RFC that documents the > current proposal can be changed through the consensus process > at any other time. > > > After the discussion, some clarifying questions about the > hums, and typing the hum questions on the screen, there was > rough consensus in the room to add (aka “shove”) the proposed > text into draft-ietf-rtcweb-video. In keeping with IETF > process, I am confirming this consensus call on the list. > > If anyone has any other issues that they would like to raise > please do by December 19th. > > Cheers, > spt (as chair) > > [0] > http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html > [1] > http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html > [2] > http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html > [3] The one that begins with "If compelling evidence ..." > [4] > http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf > _______________________________________________ > 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 > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda --------------070709090307050704090308 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I am not supporting the proposal.

The licensing around H264 is a mess, blocking safe usage in open source software (which had really big impact in the evolution of open web & internet) that cannot control its distribution. Moreover, it is imposing unnecessary costs, or in other words, even worse, a revenue to a particular group of interests, and exposing new players to unknown risks. These are serious impediments for innovation and not something I would expect from an open specification from IETF.

On some of the bits of the proposal: mandating that the two codecs stay mandatory is odd and somehow overruling IETF system where a new RFC can obsolete a new RFC. Different requirements for different entities will create a mess of terminologies (e.g., how an app implementing JS API and one codec is going to be presented: a *web browser* but not a *webrtc browser*, just a *webrtc device*).

Ending up now with an bad solution for present and the future, just to close the door on this topic, is not appropriate for how open Internet communications are supposed to evolve. Better let time to come with a better solution and applications negotiate what they like meanwhile (even with no MTI video codec so far, there are successful webrtc services).

Daniel

Ps. I reiterate my opinions on this thread, because I expressed them on other threads of recent discussions, which may count or not.

On 09/12/14 21:31, Bernard Aboba wrote:
Setting aside my reservations about the dual-MTI requirement for browsers, I also oppose the other elements of the proposal. 

Mandating that applications support both codecs makes no sense - they should only be required to support one of them (their choice).   If this change were made the trigger clause would serve no purpose, other than to keep this discussion going ad-infinitum.  So I oppose that as well. 

Allowing an endpoint that implements video to call itself "WebRTC compliant" without implementing either of the MTI codecs is so wrong-headed that I am at a loss for words.



On Tue, Dec 9, 2014 at 12:16 PM, Erik Lagerway <erik@hookflash.com> wrote:
Thanks Sean,

We can not support this draft at this time.

As RTC SDK vendors we very likely will support both codecs, but we can not stand by a decision that will "impose" dual MTI on our developer community.

According to this, every dev must use both codecs for every app that is built using our tools. Codec selection should be their choice and not be forced upon them. This seems to be a rather unreasonable expectation.


Erik Lagerway | Hookflash | 1 (855) Hookflash ext. 2 | Twitter | WebRTC.is Blog 
On Fri, Dec 5, 2014 at 5:36 AM, Sean Turner <turners@ieca.com> wrote:
All,

At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion about codecs, which I dubbed "the great codec compromise."  The compromise text that was discussed appears in slides 12-14 at [4] (which is a slight editorial variation of the text proposed at [2]).

This message serves to confirm the sense of the room.

In the room, I heard the following objections and responses (and I’m paraphrasing here), which I’ll take the liberty of categorizing as IPR, Time, and Trigger:

1) IPR:

Objections: There are still IPR concerns which may restrict what a particular organization feels comfortable with including in their browser implementations.

Response:  IPR concerns on this topic are well known.  There is even a draft summarizing the current IPR status for VP8: draft-benham-rtcweb-vp8litigation.  The sense of the room was still that adopting the compromise text was appropriate.

2) Time:

2.1) Time to consider decision:

Objection: The decision to consider the compromise proposal at this meeting was provided on short notice and did not provide some the opportunity to attend in person.

Response:  Six months ago the chairs made it clear discussion would be revisited @ IETF 91 [0]. The first agenda proposal for the WG included this topic [1], and the topic was never removed by the chairs.    More importantly, all decisions are confirmed on list; in person attendance is not required to be part of the process.

2.2) Time to consider text:

Objection: The proposed text [2] is too new to be considered.

Response: The requirement for browsers to support both VP8 and H.264 was among the options in the straw poll conducted more than six months ago.  All decisions are confirmed on list so there will be ample time to discuss the proposal.

3) Trigger:

Objection: The “trigger” sentence [3] is all kinds of wrong because it’s promising that the future IETF will update this specification.

Response: Like any IETF proposal, an RFC that documents the current proposal can be changed through the consensus process at any other time.


After the discussion, some clarifying questions about the hums, and typing the hum questions on the screen, there was rough consensus in the room to add (aka “shove”) the proposed text into draft-ietf-rtcweb-video.  In keeping with IETF process, I am confirming this consensus call on the list.

If anyone has any other issues that they would like to raise please do by December 19th.

Cheers,
spt (as chair)

[0] http://www.ietf.org/mail-archive/web/rtcweb/current/msg11194.html
[1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13150.html
[2] http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html
[3] The one that begins with "If compelling evidence ..."
[4] http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf
_______________________________________________
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




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
--------------070709090307050704090308-- From nobody Thu Dec 18 17:20:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0871A00C2 for ; Thu, 18 Dec 2014 17:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjP1EOeNwaZy for ; Thu, 18 Dec 2014 17:20:18 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C1F1A0092 for ; Thu, 18 Dec 2014 17:20:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3707; q=dns/txt; s=iport; t=1418952018; x=1420161618; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Q0TQxvtiMehlIjVvG7OTkGnvZjggB9UW0IPXFFqvl9Y=; b=IR9KMcnoNVlRE8tg+o30rCRO1SJDfHsHaB9LwaDkAwu4euOsf0OVcmLY rmo9uIIygFrSzl1FoLnnXdaGUP4UOdNxjmbOW/QW/EHpC0RY9eJRORzmJ 99KQwwtnUBykQEoXm8Pzu/IToa3JuHOYqusM9DdJ2i6pfw+P1MbTGuuXa I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAGl8k1StJA2N/2dsb2JhbABbgwZSWATDeYIbCoUoSgKBIRYBAQEBAX2EDAEBAQMBAQEBCywrCQsMBAIBCBEEAQEBChQJBycLFAkIAQEEAQ0FCIgcCA3PUAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEj0ExBwaDEIETBY4Kgz6BPz6UdyKDbG+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,604,1413244800"; d="scan'208";a="106773104" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP; 19 Dec 2014 01:20:17 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sBJ1KHKU003783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Dec 2014 01:20:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.58]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 19:20:17 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Mo Zanaty (mzanaty)" , Adam Roach , "Cullen Jennings (fluffy)" , "Hutton, Andrew" Thread-Topic: [rtcweb] rtcweb-transports reference to TRAM discovery Thread-Index: AdAYdVah0SPsel0ORrys7Zw+IDeNbwCpE+OAAAbcQIAAAWHBgAAEPqYQ Date: Fri, 19 Dec 2014 01:20:16 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A35521B46@xmb-rcd-x10.cisco.com> References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <6946D534-CBE7-4D1A-8C26-4D2FE07136D1@cisco.com> <54933BA3.9040209@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.32.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WTQ0Vyg-lzGr4cYaLqrKOVHlKe8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 01:20:20 -0000 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Mo Zanaty > (mzanaty) > Sent: Friday, December 19, 2014 2:50 AM > To: Adam Roach; Cullen Jennings (fluffy); Hutton, Andrew > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery >=20 > The priority order that makes most sense to me is: >=20 > 1. user override > 2. app override > 3. auto discovery > 4. app fallback > 5. user fallback >=20 > If any override is configured by the user or app, do not perform auto > discovery, stop here. >=20 > If auto discovery fails, use a fallback configured by the app or user. >=20 > There is a big difference between an override and a fallback, so both see= m > necessary. >=20 > Obviously, we need some mechanism for 3 as Adam said, in case it needs to > be invoked. TURN server selection is discussed in https://tools.ietf.org/html/draft-pat= il-tram-turn-serv-selection-00 -Tiru >=20 > Mo >=20 > On 12/18/14, 3:40 PM, Adam Roach wrote: >=20 > So, I think it's important that we have some way to encourage deployment = of > TURN servers both in the ISPs, and as part of firewalls (both residential= and > enterprise). By putting TURN in paths that are already going to bear the > traffic in question, the overall cost associated with calls goes down, an= d call > quality (latency, loss) improves. >=20 > I'm sympathetic to the position that we don't want to give these entities > specific hooks to force specific servers to be inserted into the flow. We= need > to find a balance here: something that allows the relevant entities to de= ploy > and advertise such servers; something that allows WebRTC applications to > discover and use them; and something that puts the ultimate decision in t= he > hands of the users. Off the top of my head, adding a browser API that all= ows > applications to to retrieve these servers and elect to use them if it wa= nts to > would serve part of the purpose; giving users a means by which they can > instruct the browser not to return such a list would serve the remainder. >=20 > But that's all kind of orthogonal to the IETF issues: if we're going to d= o > *anything* in this space, we need the discovery mechanisms. >=20 > /a >=20 > On 12/18/14 11:23, Cullen Jennings (fluffy) wrote: > > It seems that in the mobile case and many residential cases, doing > >that draft would allow a service provider to force all the traffic > >through a TURN server of the service providers choosing. Am I reading > >this correctly because I am pretty sure I would not be in favor of that. > > > > > >> On Dec 15, 2014, at 7:42 AM, Hutton, Andrew > > >>wrote: > >> > >> I am thinking that > >>https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section-3. > >>4 should include a requirement that a WebRTC Browser MUST support the > >>TURN server discovery as described in > >>https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00. > >> > >> > >> Andy > >> > >> _______________________________________________ > >> 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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Dec 19 02:15:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4461A6F97 for ; Fri, 19 Dec 2014 02:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4k2KgAYrThFd for ; Fri, 19 Dec 2014 02:15:11 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id CB1E71A6F59 for ; Fri, 19 Dec 2014 02:15:10 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id DEA911EB84F3 for ; Fri, 19 Dec 2014 11:15:09 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.192]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 11:15:09 +0100 From: "Hutton, Andrew" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] rtcweb-transports reference to TRAM discovery Thread-Index: AdAYdVah0SPsel0ORrys7Zw+IDeNbwCjXsFl///6QID//xuyUA== Date: Fri, 19 Dec 2014 10:15:09 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E645DA3@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <6946D534-CBE7-4D1A-8C26-4D2FE07136D1@cisco.com> <54933BA3.9040209@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Q66ePc3Gh6FCZfAWIHDq1T07prg Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 10:15:17 -0000 +1 to Adam and Mo's comments which make a lot of sense to me. I agree we need to enable the use of TURN servers which provide the best us= er experience so enabling the use of TURN servers close to the clients make= s sense. At the same time there are some security considerations which we = can provide some guidance on so would it make sense to do the following? 1. Add a reference to draft-ietf-tram-turn-server-discovery in -transports-= and make it a SHOULD/MAY/MUST implement (I prefer MUST but I know others p= robably don't).=20 2. Add some text either inline or in the security considerations about the = concerns and the need for user/app override.=20 By the way I am not sure we need the app override if we consider draft-schw= artz-rtcweb-return part of the solution. Andy > -----Original Message----- > From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] > Sent: 18 December 2014 21:20 > To: Adam Roach; Cullen Jennings (fluffy); Hutton, Andrew > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery >=20 > The priority order that makes most sense to me is: >=20 > 1. user override > 2. app override > 3. auto discovery > 4. app fallback > 5. user fallback >=20 > If any override is configured by the user or app, do not perform auto > discovery, stop here. >=20 > If auto discovery fails, use a fallback configured by the app or user. >=20 > There is a big difference between an override and a fallback, so both > seem > necessary. >=20 > Obviously, we need some mechanism for 3 as Adam said, in case it needs > to > be invoked. >=20 > Mo >=20 > On 12/18/14, 3:40 PM, Adam Roach wrote: >=20 > So, I think it's important that we have some way to encourage > deployment > of TURN servers both in the ISPs, and as part of firewalls (both > residential and enterprise). By putting TURN in paths that are already > going to bear the traffic in question, the overall cost associated with > calls goes down, and call quality (latency, loss) improves. >=20 > I'm sympathetic to the position that we don't want to give these > entities specific hooks to force specific servers to be inserted into > the flow. We need to find a balance here: something that allows the > relevant entities to deploy and advertise such servers; something that > allows WebRTC applications to discover and use them; and something that > puts the ultimate decision in the hands of the users. Off the top of my > head, adding a browser API that allows applications to to retrieve > these servers and elect to use them if it wants to would serve part of > the purpose; giving users a means by which they can instruct the > browser > not to return such a list would serve the remainder. >=20 > But that's all kind of orthogonal to the IETF issues: if we're going to > do *anything* in this space, we need the discovery mechanisms. >=20 > /a >=20 > On 12/18/14 11:23, Cullen Jennings (fluffy) wrote: > > It seems that in the mobile case and many residential cases, doing > that > >draft would allow a service provider to force all the traffic through > a > >TURN server of the service providers choosing. Am I reading this > >correctly because I am pretty sure I would not be in favor of that. > > > > > >> On Dec 15, 2014, at 7:42 AM, Hutton, Andrew > > >>wrote: > >> > >> I am thinking that > >>https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section- > 3.4 > >>should include a requirement that a WebRTC Browser MUST support the > TURN > >>server discovery as described in > >>https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00. > >> > >> > >> Andy > >> > >> _______________________________________________ > >> 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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Dec 19 07:25:40 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0441A89B9 for ; Fri, 19 Dec 2014 07:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYFLCMnbW3hi for ; Fri, 19 Dec 2014 07:25:35 -0800 (PST) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC251A89F0 for ; Fri, 19 Dec 2014 07:25:35 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id kv19so393817vcb.18 for ; Fri, 19 Dec 2014 07:25:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gNtfFcFYq8s0GRC3gLqV9OpZumdNn5z1OHQkrcBzd7o=; b=Hv6epePgP4JE5+tBOFFeHjPOBA4w//995zCMwhQmK6uvMawKOQmtwAwl1VT4CydU78 YdSbsBKu4o1pSU7Pjx5hIJB7rrcKCivcWiRgfD5YxANEMV1I9dij1OCB14ixSWel6wYw otyFgJ7sh9nffxsVkbX/0aPmbt4EEIvXrKIcUocoO6hiRSxSdLszlXP7aToST9M59KeD AN4jifTxKiPBWaUHyAjR/vgKieIelNkFUcBckdLyNP+iIgpaVyr3704f7f726m/1pXwP YyXC58q5XwtQeBgC96xFwRfXrVhXFJ4R+ihC+WmNrrng2DfXs+fRDprFYkENaq5ooISD QKlA== X-Gm-Message-State: ALoCoQle7TP43mKFzum/jT5ceq3ZcfV1D5LcZgQeuMKV0OzV7YXPC2y5hwRz0WzzCt/GfZzvrIC7 X-Received: by 10.220.102.20 with SMTP id e20mr2795076vco.12.1419002734606; Fri, 19 Dec 2014 07:25:34 -0800 (PST) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com. [209.85.220.175]) by mx.google.com with ESMTPSA id oh11sm1731279vdb.9.2014.12.19.07.25.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Dec 2014 07:25:33 -0800 (PST) Received: by mail-vc0-f175.google.com with SMTP id hy10so393576vcb.34 for ; Fri, 19 Dec 2014 07:25:33 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.220.205.2 with SMTP id fo2mr2785319vcb.8.1419002733481; Fri, 19 Dec 2014 07:25:33 -0800 (PST) Received: by 10.52.54.194 with HTTP; Fri, 19 Dec 2014 07:25:33 -0800 (PST) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E645DA3@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <6946D534-CBE7-4D1A-8C26-4D2FE07136D1@cisco.com> <54933BA3.9040209@nostrum.com> <9F33F40F6F2CD847824537F3C4E37DDF1E645DA3@MCHP04MSX.global-ad.net> Date: Fri, 19 Dec 2014 10:25:33 -0500 Message-ID: From: Benjamin Schwartz To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=001a11c3dfd0dd6930050a9351aa Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/B9h2vvNeQ0dFPWeYO9fY7f-8BP4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 15:25:39 -0000 --001a11c3dfd0dd6930050a9351aa Content-Type: text/plain; charset=UTF-8 To reiterate, the TRAM draft doesn't specify what WebRTC should actually do with the discovered TURN server(s). RETURN ( https://datatracker.ietf.org/doc/draft-schwartz-rtcweb-return/) attempts to fill in the details, and also resolve questions about priority of different settings, etc. Comments on the RETURN draft are appreciated, of couse. On Fri, Dec 19, 2014 at 5:15 AM, Hutton, Andrew wrote: > +1 to Adam and Mo's comments which make a lot of sense to me. > > I agree we need to enable the use of TURN servers which provide the best > user experience so enabling the use of TURN servers close to the clients > makes sense. At the same time there are some security considerations which > we can provide some guidance on so would it make sense to do the following? > > 1. Add a reference to draft-ietf-tram-turn-server-discovery in > -transports- and make it a SHOULD/MAY/MUST implement (I prefer MUST but I > know others probably don't). > > 2. Add some text either inline or in the security considerations about the > concerns and the need for user/app override. > > By the way I am not sure we need the app override if we consider > draft-schwartz-rtcweb-return part of the solution. > > Andy > > > > -----Original Message----- > > From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] > > Sent: 18 December 2014 21:20 > > To: Adam Roach; Cullen Jennings (fluffy); Hutton, Andrew > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery > > > > The priority order that makes most sense to me is: > > > > 1. user override > > 2. app override > > 3. auto discovery > > 4. app fallback > > 5. user fallback > > > > If any override is configured by the user or app, do not perform auto > > discovery, stop here. > > > > If auto discovery fails, use a fallback configured by the app or user. > > > > There is a big difference between an override and a fallback, so both > > seem > > necessary. > > > > Obviously, we need some mechanism for 3 as Adam said, in case it needs > > to > > be invoked. > > > > Mo > > > > On 12/18/14, 3:40 PM, Adam Roach wrote: > > > > So, I think it's important that we have some way to encourage > > deployment > > of TURN servers both in the ISPs, and as part of firewalls (both > > residential and enterprise). By putting TURN in paths that are already > > going to bear the traffic in question, the overall cost associated with > > calls goes down, and call quality (latency, loss) improves. > > > > I'm sympathetic to the position that we don't want to give these > > entities specific hooks to force specific servers to be inserted into > > the flow. We need to find a balance here: something that allows the > > relevant entities to deploy and advertise such servers; something that > > allows WebRTC applications to discover and use them; and something that > > puts the ultimate decision in the hands of the users. Off the top of my > > head, adding a browser API that allows applications to to retrieve > > these servers and elect to use them if it wants to would serve part of > > the purpose; giving users a means by which they can instruct the > > browser > > not to return such a list would serve the remainder. > > > > But that's all kind of orthogonal to the IETF issues: if we're going to > > do *anything* in this space, we need the discovery mechanisms. > > > > /a > > > > On 12/18/14 11:23, Cullen Jennings (fluffy) wrote: > > > It seems that in the mobile case and many residential cases, doing > > that > > >draft would allow a service provider to force all the traffic through > > a > > >TURN server of the service providers choosing. Am I reading this > > >correctly because I am pretty sure I would not be in favor of that. > > > > > > > > >> On Dec 15, 2014, at 7:42 AM, Hutton, Andrew > > > > >>wrote: > > >> > > >> I am thinking that > > >>https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section- > > 3.4 > > >>should include a requirement that a WebRTC Browser MUST support the > > TURN > > >>server discovery as described in > > >>https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00. > > >> > > >> > > >> Andy > > >> > > >> _______________________________________________ > > >> 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 > > > > _______________________________________________ > > 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 > --001a11c3dfd0dd6930050a9351aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To reiterate, the TRAM draft doesn't specify what WebR= TC should actually do with the discovered TURN server(s).=C2=A0 RETURN (htt= ps://datatracker.ietf.org/doc/draft-schwartz-rtcweb-return/) attempts t= o fill in the details, and also resolve questions about priority of differe= nt settings, etc.

Comments on the RETURN draft are appre= ciated, of couse.

On Fri, Dec 19, 2014 at 5:15 AM, Hutton, Andrew <andrew.= hutton@unify.com> wrote:
+1= to Adam and Mo's comments which make a lot of sense to me.

I agree we need to enable the use of TURN servers which provide the best us= er experience so enabling the use of TURN servers close to the clients make= s sense.=C2=A0 At the same time there are some security considerations whic= h we can provide some guidance on so would it make sense to do the followin= g?

1. Add a reference to draft-ietf-tram-turn-server-discovery in -transports-= and make it a SHOULD/MAY/MUST implement (I prefer MUST but I know others p= robably don't).

2. Add some text either inline or in the security considerations about the = concerns and the need for user/app override.

By the way I am not sure we need the app override if we consider draft-schw= artz-rtcweb-return part of the solution.

Andy


> -----Original Message-----
> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> Sent: 18 December 2014 21:20
> To: Adam Roach; Cullen Jennings (fluffy); Hutton, Andrew
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery >
> The priority order that= makes most sense to me is:
>
> 1. user override
> 2. app override
> 3. auto discovery
> 4. app fallback
> 5. user fallback
>
> If any override is configured by the user or app, do not perform auto<= br> > discovery, stop here.
>
> If auto discovery fails, use a fallback configured by the app or user.=
>
> There is a big difference between an override and a fallback, so both<= br> > seem
> necessary.
>
> Obviously, we need some mechanism for 3 as Adam said, in case it needs=
> to
> be invoked.
>
> Mo
>
> On 12/18/14, 3:40 PM, Adam Roach <adam@nostrum.com> wrote:
>
> So, I think it's important that we have some way to encourage
> deployment
> of TURN servers both in the ISPs, and as part of firewalls (both
> residential and enterprise). By putting TURN in paths that are already=
> going to bear the traffic in question, the overall cost associated wit= h
> calls goes down, and call quality (latency, loss) improves.
>
> I'm sympathetic to the position that we don't want to give the= se
> entities specific hooks to force specific servers to be inserted into<= br> > the flow. We need to find a balance here: something that allows the > relevant entities to deploy and advertise such servers; something that=
> allows WebRTC applications to discover and use them; and something tha= t
> puts the ultimate decision in the hands of the users. Off the top of m= y
> head, adding a browser API that allows applications to=C2=A0 to retrie= ve
> these servers and elect to use them if it wants to would serve part of=
> the purpose; giving users a means by which they can instruct the
> browser
> not to return such a list would serve the remainder.
>
> But that's all kind of orthogonal to the IETF issues: if we're= going to
> do *anything* in this space, we need the discovery mechanisms.
>
> /a
>
> On 12/18/14 11:23, Cullen Jennings (fluffy) wrote:
> > It seems that in the mobile case and many residential cases, doin= g
> that
> >draft would allow a service provider to force all the traffic thro= ugh
> a
> >TURN server of the service providers choosing. Am I reading this > >correctly because I am pretty sure I would not be in favor of that= .
> >
> >
> >> On Dec 15, 2014, at 7:42 AM, Hutton, Andrew
> <andrew.hutton@unify.com= >
> >>wrote:
> >>
> >> I am thinking that
> >>https://tools.ietf.org/html/draft-ietf= -rtcweb-transports-07#section-
> 3.4
> >>should include a requirement that a WebRTC Browser MUST suppor= t the
> TURN
> >>server discovery as described in
> >>https://tools.ietf.org/html/draft-ietf= -tram-turn-server-discovery-00.
> >>
> >>
> >> Andy
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> 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

--001a11c3dfd0dd6930050a9351aa-- From nobody Fri Dec 19 08:58:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94AB1A89A0 for ; Fri, 19 Dec 2014 08:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxk6fX2UpZpm for ; Fri, 19 Dec 2014 08:58:20 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2FD1A88EF for ; Fri, 19 Dec 2014 08:58:20 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id et14so1561564pad.3 for ; Fri, 19 Dec 2014 08:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wqvKCxouxkNoSLmnq3JpDGe8ozOkI/i9M5LsP4DczgY=; b=uclj5f3mHX0vEwvLgprkwci3aRX0iT/iVzrwV6suFGxIfJGYr1KzqMMXbq5+rxWlD0 yQpydWmtHk9ikDRwLRiXnFeSfkVk+CQ9xDo7dgydvS4nRfw26QTTmfHsUbe5bWJq0uoh eniLbhUC2tJdRYvRqHPhy2fEIeycejj5bIAjVEeivZ/EFlgfnvvrCIjfHRB4RfJo2gNK dUtFk5wW1BbbWH7BA/1Iku6HkCh5cT1CjLzkcTsXLAQqzrbUdbrcKLrhPqgbbGTQLE4x 5AyDRyLVPtmLtHiLsiikls0hjj/+uvWVLaWKwLV+GOlkkim+x3Hsifg9thDZHct0sp9E H2nA== MIME-Version: 1.0 X-Received: by 10.68.167.36 with SMTP id zl4mr13806209pbb.83.1419008299349; Fri, 19 Dec 2014 08:58:19 -0800 (PST) Received: by 10.70.60.201 with HTTP; Fri, 19 Dec 2014 08:58:19 -0800 (PST) In-Reply-To: References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <6946D534-CBE7-4D1A-8C26-4D2FE07136D1@cisco.com> <54933BA3.9040209@nostrum.com> <9F33F40F6F2CD847824537F3C4E37DDF1E645DA3@MCHP04MSX.global-ad.net> Date: Fri, 19 Dec 2014 22:28:19 +0530 Message-ID: From: Suhas Nandakumar To: Benjamin Schwartz Content-Type: multipart/alternative; boundary=047d7bd6c74e9dbcc1050a949d39 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ekHt89v3ITovcdWMy5C7ZZHwTJc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 16:58:24 -0000 --047d7bd6c74e9dbcc1050a949d39 Content-Type: text/plain; charset=UTF-8 Few cents .. I tend to agree with Cullen's sentiment since as a end user I don't want to end up with service provider lock-in when using a TURN server. Such lock-ins might not be a bad option but It need not be enforced by design. OTOH I am not sure how effective will be a typical not-so-technical end-user's decision making in choosing one turn server over the other. But having flexibility is not a bad idea , thus i feel the spec needs to just say the plausible options but mandating with MUST might not be what we need here. Cheers Suhas On Fri, Dec 19, 2014 at 8:55 PM, Benjamin Schwartz wrote: > To reiterate, the TRAM draft doesn't specify what WebRTC should actually > do with the discovered TURN server(s). RETURN ( > https://datatracker.ietf.org/doc/draft-schwartz-rtcweb-return/) attempts > to fill in the details, and also resolve questions about priority of > different settings, etc. > > Comments on the RETURN draft are appreciated, of couse. > > On Fri, Dec 19, 2014 at 5:15 AM, Hutton, Andrew > wrote: > >> +1 to Adam and Mo's comments which make a lot of sense to me. >> >> I agree we need to enable the use of TURN servers which provide the best >> user experience so enabling the use of TURN servers close to the clients >> makes sense. At the same time there are some security considerations which >> we can provide some guidance on so would it make sense to do the following? >> >> 1. Add a reference to draft-ietf-tram-turn-server-discovery in >> -transports- and make it a SHOULD/MAY/MUST implement (I prefer MUST but I >> know others probably don't). >> >> 2. Add some text either inline or in the security considerations about >> the concerns and the need for user/app override. >> >> By the way I am not sure we need the app override if we consider >> draft-schwartz-rtcweb-return part of the solution. >> >> Andy >> >> >> > -----Original Message----- >> > From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] >> > Sent: 18 December 2014 21:20 >> > To: Adam Roach; Cullen Jennings (fluffy); Hutton, Andrew >> > Cc: rtcweb@ietf.org >> > Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery >> > >> > The priority order that makes most sense to me is: >> > >> > 1. user override >> > 2. app override >> > 3. auto discovery >> > 4. app fallback >> > 5. user fallback >> > >> > If any override is configured by the user or app, do not perform auto >> > discovery, stop here. >> > >> > If auto discovery fails, use a fallback configured by the app or user. >> > >> > There is a big difference between an override and a fallback, so both >> > seem >> > necessary. >> > >> > Obviously, we need some mechanism for 3 as Adam said, in case it needs >> > to >> > be invoked. >> > >> > Mo >> > >> > On 12/18/14, 3:40 PM, Adam Roach wrote: >> > >> > So, I think it's important that we have some way to encourage >> > deployment >> > of TURN servers both in the ISPs, and as part of firewalls (both >> > residential and enterprise). By putting TURN in paths that are already >> > going to bear the traffic in question, the overall cost associated with >> > calls goes down, and call quality (latency, loss) improves. >> > >> > I'm sympathetic to the position that we don't want to give these >> > entities specific hooks to force specific servers to be inserted into >> > the flow. We need to find a balance here: something that allows the >> > relevant entities to deploy and advertise such servers; something that >> > allows WebRTC applications to discover and use them; and something that >> > puts the ultimate decision in the hands of the users. Off the top of my >> > head, adding a browser API that allows applications to to retrieve >> > these servers and elect to use them if it wants to would serve part of >> > the purpose; giving users a means by which they can instruct the >> > browser >> > not to return such a list would serve the remainder. >> > >> > But that's all kind of orthogonal to the IETF issues: if we're going to >> > do *anything* in this space, we need the discovery mechanisms. >> > >> > /a >> > >> > On 12/18/14 11:23, Cullen Jennings (fluffy) wrote: >> > > It seems that in the mobile case and many residential cases, doing >> > that >> > >draft would allow a service provider to force all the traffic through >> > a >> > >TURN server of the service providers choosing. Am I reading this >> > >correctly because I am pretty sure I would not be in favor of that. >> > > >> > > >> > >> On Dec 15, 2014, at 7:42 AM, Hutton, Andrew >> > >> > >>wrote: >> > >> >> > >> I am thinking that >> > >>https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section- >> > 3.4 >> > >>should include a requirement that a WebRTC Browser MUST support the >> > TURN >> > >>server discovery as described in >> > >>https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00. >> > >> >> > >> >> > >> Andy >> > >> >> > >> _______________________________________________ >> > >> 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 >> > >> > _______________________________________________ >> > 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 >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7bd6c74e9dbcc1050a949d39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Few cents ..

I tend to agree with= Cullen's sentiment since as a end user I don't want to end up with= service provider lock-in when using a TURN server.=C2=A0

Such lock-ins might not be a bad option but It need not be enforced by de= sign.

OTOH =C2=A0I am not sure how effective will b= e a typical not-so-technical end-user's decision making in choosing one= turn server over the other.

But having flex= ibility is not a bad idea , thus i feel the spec needs to just say the plau= sible options but mandating with MUST might not be what we need here.
=



Cheers
Suhas


On Fri, Dec 19, 2014 at 8:55 PM, Benjamin Schwartz <bemasc@= webrtc.org> wrote:
To reiterate, the TRAM draft doesn't specify what WebRTC shoul= d actually do with the discovered TURN server(s).=C2=A0 RETURN (https://datatracker.ietf.org/doc/draft-schwartz-rtcweb-return/) = attempts to fill in the details, and also resolve questions about priority = of different settings, etc.

Comments on the RETURN draft= are appreciated, of couse.

On Fri, Dec 1= 9, 2014 at 5:15 AM, Hutton, Andrew <andrew.hutton@unify.com><= /span> wrote:
+1 to Adam and Mo's com= ments which make a lot of sense to me.

I agree we need to enable the use of TURN servers which provide the best us= er experience so enabling the use of TURN servers close to the clients make= s sense.=C2=A0 At the same time there are some security considerations whic= h we can provide some guidance on so would it make sense to do the followin= g?

1. Add a reference to draft-ietf-tram-turn-server-discovery in -transports-= and make it a SHOULD/MAY/MUST implement (I prefer MUST but I know others p= robably don't).

2. Add some text either inline or in the security considerations about the = concerns and the need for user/app override.

By the way I am not sure we need the app override if we consider draft-schw= artz-rtcweb-return part of the solution.

Andy


> -----Original Message-----
> From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
> Sent: 18 December 2014 21:20
> To: Adam Roach; Cullen Jennings (fluffy); Hutton, Andrew
> Cc: rtcweb@ietf.o= rg
> Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery >
> The priority order that makes most sense to me is: >
> 1. user override
> 2. app override
> 3. auto discovery
> 4. app fallback
> 5. user fallback
>
> If any override is configured by the user or app, do not perform auto<= br> > discovery, stop here.
>
> If auto discovery fails, use a fallback configured by the app or user.=
>
> There is a big difference between an override and a fallback, so both<= br> > seem
> necessary.
>
> Obviously, we need some mechanism for 3 as Adam said, in case it needs=
> to
> be invoked.
>
> Mo
>
> On 12/18/14, 3:40 PM, Adam Roach <adam@nostrum.com> wrote:
>
> So, I think it's important that we have some way to encourage
> deployment
> of TURN servers both in the ISPs, and as part of firewalls (both
> residential and enterprise). By putting TURN in paths that are already=
> going to bear the traffic in question, the overall cost associated wit= h
> calls goes down, and call quality (latency, loss) improves.
>
> I'm sympathetic to the position that we don't want to give the= se
> entities specific hooks to force specific servers to be inserted into<= br> > the flow. We need to find a balance here: something that allows the > relevant entities to deploy and advertise such servers; something that=
> allows WebRTC applications to discover and use them; and something tha= t
> puts the ultimate decision in the hands of the users. Off the top of m= y
> head, adding a browser API that allows applications to=C2=A0 to retrie= ve
> these servers and elect to use them if it wants to would serve part of=
> the purpose; giving users a means by which they can instruct the
> browser
> not to return such a list would serve the remainder.
>
> But that's all kind of orthogonal to the IETF issues: if we're= going to
> do *anything* in this space, we need the discovery mechanisms.
>
> /a
>
> On 12/18/14 11:23, Cullen Jennings (fluffy) wrote:
> > It seems that in the mobile case and many residential cases, doin= g
> that
> >draft would allow a service provider to force all the traffic thro= ugh
> a
> >TURN server of the service providers choosing. Am I reading this > >correctly because I am pretty sure I would not be in favor of that= .
> >
> >
> >> On Dec 15, 2014, at 7:42 AM, Hutton, Andrew
> <andre= w.hutton@unify.com>
> >>wrote:
> >>
> >> I am thinking that
> >>https://tools.ietf.org/html/draft-ietf= -rtcweb-transports-07#section-
> 3.4
> >>should include a requirement that a WebRTC Browser MUST suppor= t the
> TURN
> >>server discovery as described in
> >>https://tools.ietf.org/html/draft-ietf= -tram-turn-server-discovery-00.
> >>
> >>
> >> Andy
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@i= etf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> > _______________________________________________
> > 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

_______________________________________________
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


--047d7bd6c74e9dbcc1050a949d39-- From nobody Fri Dec 19 09:06:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A0B1A89B0 for ; Fri, 19 Dec 2014 09:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQWzbU8ZWTf6 for ; Fri, 19 Dec 2014 09:06:19 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A05D1A8A66 for ; Fri, 19 Dec 2014 09:06:15 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBJH6BfE053685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Dec 2014 11:06:12 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54945B03.409@nostrum.com> Date: Fri, 19 Dec 2014 11:06:11 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Suhas Nandakumar , Benjamin Schwartz References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <6946D534-CBE7-4D1A-8C26-4D2FE07136D1@cisco.com> <54933BA3.9040209@nostrum.com> <9F33F40F6F2CD847824537F3C4E37DDF1E645DA3@MCHP04MSX.global-ad.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/h-DQD8mHv11ErfVOYPOdn5K3rAE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 17:06:21 -0000 On 12/19/14 10:58, Suhas Nandakumar wrote: > But having flexibility is not a bad idea , thus i feel the spec needs > to just say the plausible options but mandating with MUST might not be > what we need here. I think you're falling into the trap of not distinguishing between "MUST implement" and "MUST use". I'm not necessarily arguing that this is a "MUST implement" requirement on browsers[1], but if we're going to figure out what makes sense, we need to think about this properly. /a ____ [1] I'd love to see this kind of discovery deployed universally, since I believe it contributes to the long-term success of WebRTC, but I'd like to hear other people's arguments for/against doing so before taking a concrete position. From nobody Fri Dec 19 11:18:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9A91A8AD4 for ; Fri, 19 Dec 2014 11:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13TqQTfvL6w8 for ; Fri, 19 Dec 2014 11:18:51 -0800 (PST) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [67.18.80.17]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65CE71A892A for ; Fri, 19 Dec 2014 11:18:51 -0800 (PST) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 6D194B8C5A4B0; Fri, 19 Dec 2014 13:18:50 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 52BA4B8C5A482 for ; Fri, 19 Dec 2014 13:18:50 -0600 (CST) Received: from [96.231.218.201] (port=57023 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Y234b-0005A3-M2 for rtcweb@ietf.org; Fri, 19 Dec 2014 13:18:49 -0600 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <054DA5A7-815B-4588-AE48-FDDA3E236C78@ieca.com> Date: Fri, 19 Dec 2014 14:18:48 -0500 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.218.201 X-Exim-ID: 1Y234b-0005A3-M2 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [96.231.218.201]:57023 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 11 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3spQQhkGR5nbjhGVP3cPj4Uk7CE Subject: [rtcweb] WG consensus call on mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 19:18:55 -0000 All, After reviewing the messages posted to the mailing list related to the = MTI (Mandatory To Implement) codec discussion since Hawaii (~300+), it = is my judgement as chair that no unaddressed issues remain, so the call = of rough consensus for the proposed =93compromise=94 text made during = the 2nd session of the RTCweb WG in Hawaii is confirmed. Note that the = text currently in section 5 of draft-ietf-rtcweb-video-03 reflects this = consensus. Thanks to everyone for the robust discussion. Hopefully this will clear = the way for us to make progress on our remaining milestones. spt= From nobody Fri Dec 19 12:28:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CC91ACDA3 for ; Fri, 19 Dec 2014 12:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psUcQ-F0heUX for ; Fri, 19 Dec 2014 12:28:43 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92061AC3DC for ; Fri, 19 Dec 2014 12:28:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4625; q=dns/txt; s=iport; t=1419020923; x=1420230523; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0mmAVcjS8R9nRDHjQWH2DBNDlQi8yvEXKH6bEouB3vU=; b=CoXIXa+R8eLe0YLJQqd+BnlyYDQ2AcTgllhM2r8KEb+AHiiXmDqqBHgr 8QDJxZ3+gJGkYq3vVzdbPh1jyYzoK9pwgbUV1osca5xiWa98uGVVRjgU9 17hakAVqrYf1nsLP6hTcAO++f2Rcws7VZARmXZ5YYP1S4AerDKy8tVoFi s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQFADmJlFStJV2T/2dsb2JhbABagmQiUlgExhwKhSdKAoEXFgEBAQEBfYQMAQEBAwEBAQELLCsJBAcFCwIBCBgeECcLJQIEDgUbiAkIAQzRCwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjz8zB4MWgRMFjg2DPoFBg3ORSCKDbm8BgUR+AQEB X-IronPort-AV: E=Sophos;i="5.07,608,1413244800"; d="scan'208";a="107039372" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP; 19 Dec 2014 20:28:42 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sBJKSgRV011958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Dec 2014 20:28:42 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 14:28:42 -0600 From: "Cullen Jennings (fluffy)" To: Adam Roach Thread-Topic: [rtcweb] rtcweb-transports reference to TRAM discovery Thread-Index: AQHQGwLM0SPsel0ORrys7Zw+IDeNb5yXw08A Date: Fri, 19 Dec 2014 20:28:41 +0000 Message-ID: <86247826-DF91-43AE-90C2-C1D07F4BB676@cisco.com> References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <6946D534-CBE7-4D1A-8C26-4D2FE07136D1@cisco.com> <54933BA3.9040209@nostrum.com> In-Reply-To: <54933BA3.9040209@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <576872D73FE59644AA7CE69330B0AC86@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Y0AOYZ03PmuNTJXsisAlMQJX9WA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 19 Dec 2014 20:28:46 -0000 Adam, I think you are I are mostly saying the same thing. Things like there= need to be incentives to deploy, the browser should tell the applications = about available servers, and so on ... There are probably a bunch of ways to do this - for example all the argumen= ts being made about TURN server same equally true of HTTP socks servers yet= my SP can't force all my traffic via a HTTP proxy of it's choosing. So I d= on't think claiming the privacy problems is orthogonal to the the IETF iss= ues is really OK. The privacy issues are pretty important. As you suggest, = I'm OK with browser tells applications about servers that are available but= I would not be keen on browser automatically choosing to use those. That c= reates the type of incentives that it's fine for the SP to block traffic th= at does not go through the approved (and inherently quality reducing) TURN = server.=20 It's also important to have solutions that makes business sense. Running TU= RN server is often sort of expensive from the bandwidth point of view so ty= pically the TURN servers have a relation with the actual application to ena= ble them - it's not just that someone is going to provide TURN servers for = for all webrtc applications in all networks. It's going to be a bit more c= omplicated than that and that in helps drive some of the requirements for t= his. A way where applications can discover TURN servers that they are autho= rized to use if far more appealing to me.=20 The privacy implications and bandwidth usage implications are very differen= t for STUN and TURN and thus I think the appropriate discovery mechanics fo= r them are likely different. At least the requirements for the mechanisms a= re different even if there is one mechanism that meets all the requirements= .=20 As tempting as is sounds to leave the selection up to the user, I don't thi= nk that will work. I think it needs to be up to the application running on = the browser with perhaps the possibility to be overridden by user.=20 There is a lot of ways to do discovery and some of them are already suppor= ted so I think we should figure out what we want then work on which of vari= ous discovery approaches help with that.=20 > On Dec 18, 2014, at 1:40 PM, Adam Roach wrote: >=20 > So, I think it's important that we have some way to encourage deployment = of TURN servers both in the ISPs, and as part of firewalls (both residentia= l and enterprise). By putting TURN in paths that are already going to bear = the traffic in question, the overall cost associated with calls goes down, = and call quality (latency, loss) improves. >=20 > I'm sympathetic to the position that we don't want to give these entities= specific hooks to force specific servers to be inserted into the flow. We = need to find a balance here: something that allows the relevant entities to= deploy and advertise such servers; something that allows WebRTC applicatio= ns to discover and use them; and something that puts the ultimate decision = in the hands of the users. Off the top of my head, adding a browser API tha= t allows applications to to retrieve these servers and elect to use them i= f it wants to would serve part of the purpose; giving users a means by whic= h they can instruct the browser not to return such a list would serve the r= emainder. >=20 > But that's all kind of orthogonal to the IETF issues: if we're going to d= o *anything* in this space, we need the discovery mechanisms. >=20 > /a >=20 > On 12/18/14 11:23, Cullen Jennings (fluffy) wrote: >> It seems that in the mobile case and many residential cases, doing that = draft would allow a service provider to force all the traffic through a TUR= N server of the service providers choosing. Am I reading this correctly bec= ause I am pretty sure I would not be in favor of that. >>=20 >>=20 >>> On Dec 15, 2014, at 7:42 AM, Hutton, Andrew w= rote: >>>=20 >>> I am thinking that https://tools.ietf.org/html/draft-ietf-rtcweb-transp= orts-07#section-3.4 should include a requirement that a WebRTC Browser MUST= support the TURN server discovery as described in https://tools.ietf.org/h= tml/draft-ietf-tram-turn-server-discovery-00. >>> Andy >>> _______________________________________________ >>> 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 >=20 From nobody Sat Dec 20 08:55:29 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27E91A8A14 for ; Sat, 20 Dec 2014 08:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qso5gCaKRXcb for ; Sat, 20 Dec 2014 08:55:26 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9E61A89FD for ; Sat, 20 Dec 2014 08:55:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1541; q=dns/txt; s=iport; t=1419094526; x=1420304126; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=w5Rm20tsowQdaBpTRr3swsF/b3Ti+dzRGw10VOQ2aPA=; b=ZXIaFw9IUSswqsTyOY224v8QKU1gVgrt8PXVjrlUk0MS/tWNzz4ZKoUo wJkhXzy9q4GMZmlbOXKLOdMZbWMCcScu/IXwXkYf1IBfy/WquiCoRnvy7 FuF6R+Wz86BPK1e3tA+d4bh6HoE1xeaRjz+9pm1g6RULpEvvd69HnMg8s c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFAESplVStJV2Z/2dsb2JhbABbgmQiUlgExiEKhSZKAoERFgEBAQEBfYQMAQEBAwEBAQEaHTQQCwIBCBgeECcLJQIEExqICggBDM98AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSPEBEBHTqDFoETBY4PiHKBDYJjgjOLJyKDbm+BDDl+AQEB X-IronPort-AV: E=Sophos;i="5.07,613,1413244800"; d="scan'208";a="378488554" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 20 Dec 2014 16:55:25 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBKGtPpc024769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 20 Dec 2014 16:55:25 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Sat, 20 Dec 2014 10:55:25 -0600 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways Thread-Index: AQHQHHW+iYzetcmKMkeKgNux1SlSHg== Date: Sat, 20 Dec 2014 16:55:22 +0000 Message-ID: <40AA08ED-CC50-42FA-B83D-49430AED5B8E@cisco.com> References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> In-Reply-To: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <4C2E9AFD403EE84E9E8392D15F18E108@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gYjmh5Pu429Oxj1UzfcY1A3np0w Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 20 Dec 2014 16:55:28 -0000 Thanks you to everyone that provided input.=20 The chairs are calling that there is consensus to adopt this draft as a WG = draft. We will start discussions with the AD to see about adding a milestone. The = chairs are mostly on vacation till the new year so this may not move much t= ill then.=20 Thanks, The Chairs (Cullen, Sean, Ted) > On Dec 4, 2014, at 12:29 PM, Cullen Jennings (fluffy) = wrote: >=20 > Having reviewed the fine technical comments on this draft since we asked = for comments, the chairs have noted that multiple people seem to have read = the draft. Given this great news we are going make a call for adoption.=20 >=20 > If you have an opinion, please email the list by Dec 19 and let us know i= f you either: >=20 > A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG docume= nt now >=20 > B) no, not right now=20 >=20 > If we get consensus around A we will work with ADs on milestone. Otherwis= e we will encourage the authors to keep working on this draft and continue = using this email list. We may adopt it later or include the text in other d= rafts.=20 >=20 > Thanks,=20 > The Chairs (Cullen, Sean, Ted) >=20 > PS - if you want to send an email that says more than A or B, feel free t= o change the subject, start a new thread etc.=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Mon Dec 22 12:31:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5524A1A6F10 for ; Mon, 22 Dec 2014 12:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JHQP-3nzIcz for ; Mon, 22 Dec 2014 12:31:38 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCA0F1A6FFB for ; Mon, 22 Dec 2014 12:31:37 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id i13so1655124qae.27 for ; Mon, 22 Dec 2014 12:31:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=PzDtJdFTp5HLhtkm0NIwFzgK1eCiSmADP0xWhxXQFQo=; b=aGiDv6tgCJCCRyXQnqIlnWYlNhDZOKpzMl1zV/kg2WLwX8OrQ9/dy8RJpa6Kn1WwvO wbx3EAadksJn8s7CJSmziPt4K623ucA+pDtV0HCh4PW+bGkwPqx1IevsOFo0eeipPPD5 pDxeRbXIA6S7jeotrNtuy3NyE35WHURRqtBTBu8qRBSqGYDLk45anGceXrOcJuP8/RNm ShqqfjBRDz2HWSGc0sCMYd9aLn9n5qC8OvFHe5UP6ievgWmmjPamKCP4pHC7rSQonZbj /wkIHax7jULGx9g1NZs+HHM8AzsRvkONIKz26OnJ539lKuyt6a2cVwasCbiCpziDBu8m aghQ== X-Gm-Message-State: ALoCoQkleywjtYOi79QA9Z0b+Wjb8VlWySep1vq1Ck+tClIo1r4qZ3PVn49U/HUsjmLNqoTfLTxm X-Received: by 10.140.98.33 with SMTP id n30mr37792330qge.62.1419280297095; Mon, 22 Dec 2014 12:31:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Mon, 22 Dec 2014 12:31:16 -0800 (PST) In-Reply-To: <5493696F.3090701@gmail.com> References: <5493696F.3090701@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 22 Dec 2014 21:31:16 +0100 Message-ID: To: Daniel-Constantin Mierla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZMMHD2_Jgp9oQ_EJBGhNULiv3zI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 22 Dec 2014 20:31:39 -0000 2014-12-19 0:55 GMT+01:00 Daniel-Constantin Mierla : > The licensing around H264 is a mess, blocking safe usage in open source > software (which had really big impact in the evolution of open web & > internet) that cannot control its distribution. Moreover, it is imposing > unnecessary costs, or in other words, even worse, a revenue to a particul= ar > group of interests, and exposing new players to unknown risks. These are > serious impediments for innovation and not something I would expect from = an > open specification from IETF. +1, but WONTFIX. It seems that there is already consensus and "there are not open issues to address", which makes sense given than the open source related issue that you mention hasn't been ever discussed here so it cannot be an open issue. --=20 I=C3=B1aki Baz Castillo
Temasys supports the dual codec proposal.

We = will support at least vp8 and H.264 in most of our products (BE, plugin, SD= Ks) and of course more codecs where it makes sense (AVC high profile is a g= ood example, VP8 with temporal scalability is another).

We plan to provide support for at least VP8 and H.264 (with hardware = acc when possible i.e. iOS 8+) when porting webrtc to webkit. What will be = supported in the ports/browsers using webkit as a rendering engine (*cough*= safari*cough*) will be up to those ports maintainers.

On Wed, Dec 10= , 2014 at 8:54 PM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote= :
2014-12-09 20:11 GMT+01:00 Cavigioli, C= hris <chris.cavigioli@intel= .com>:
> Paying for codecs pays for research labs to continue = their research to
> invent new things

Please, don't go there. The business model of research labs is n= ot the
subject here, and I assume you agree that the W3C's goal is not to
satisfy any business model.

Said that, there are some "minor" examples in the world that may<= br> contradict what you said, such as the Linux and open source whole
ecosystem. Anyhow, that is not the subject.


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

____________________________= ___________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb



--
=
Alex. Gouaillard, PhD, PhD,= MBA
------------------------------------------------------------------= ------------------
CTO - Temasys Communications, S'pore / Mou= ntain View
President - CoSMo Software, Cambridge, MA
--= ---------------------------------------------------------------------------= -------

<= /div>
--001a113ce1b08234020509e0fdae-- From nobody Wed Dec 10 11:16:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBFB1A8AA5 for ; Wed, 10 Dec 2014 11:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMp6uzkzNf7U for ; Wed, 10 Dec 2014 11:16:28 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1BE1A8AA9 for ; Wed, 10 Dec 2014 11:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418238949; x=2282152549; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ckz0vMHdqPuLX2pKs3xguNFPifuPCIR5i75/hzIAjco=; b=XGETKk+OSdc3yAjFK170kDRPnG8d5WpZlS3u2yPI+AfzTjlsxyZtYKxMO5sj/3u5 p1sstOo437OkhuafEvjU6ewf10kKRWUGHHJchm/6+9icbCoEocCG0C+J5QWizTfW 7N+wxml8wCqRHCr7lqnbcTy/jC3TZeHMHtfg3ZoX1tFWDtQoQF2jjINRMUfIlX5v fLVNfpBSijt/qTgCFqsS+EshYIjWSSiGXqPOMSbKWYpKAMpkbU+w3HIuMHMNjcVH tETp7ZQcYqaDpaAulHVVqtZPj7uToYKAbXioNJQbLo2uSNrJRIH/ugBtunh4Jl0I IQfydDdFhfpA+7hgo/MF6Q==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 55.89.18524.5EB98845; Wed, 10 Dec 2014 11:15:49 -0800 (PST) X-AuditID: 11973e15-f79476d00000485c-71-54889be59175 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 52.77.05858.EDB98845; Wed, 10 Dec 2014 11:15:42 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGD008G5S6CWS50@marigold.apple.com> for rtcweb@ietf.org; Wed, 10 Dec 2014 11:15:49 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <20141210012208.GK19538@hex.shelbyville.oz> Date: Wed, 10 Dec 2014 11:15:48 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <20141210012208.GK19538@hex.shelbyville.oz> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FDorPt0dkeIwalHohZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEro/vNZeaCDq6KWXNfsjcwNnF0MXJySAiYSEz4/Z0JwhaTuHBv PVsXIxeHkMBeRoljL/vZYIoun1oHlZjEJNH2vZsRwpnPJPHtUjdQOwcHs4C6xJQpuSANvAJ6 Ek1PHoOFhQVsJbZeDwIJswmoSjyYc4wRJMwpYCHR/xBsLwtQeOG8NawgNrOAtsSTdxdYIabY SOz6epAJYlMrs8THjZ+ZQRIiAsISW1/1Qh0tK/Hv4hl2kCIJgaesEhNfNbNOYBSahXDRLCQX zUKyYwEj8ypGodzEzBzdzDwzvcSCgpxUveT83E2MoGCdbie6g/HMKqtDjAIcjEo8vCuutocI sSaWFVfmHmKU5mBREuc9shsoJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbFnTXqjmMy1U396 fb7c/rKxInoR27lLvjVVyYHp52b/2LiV4c8Zz5x697dV6wJyTmf+suLYw/jHPylqi+mvnLrP dU8cC88dleTdfJV7jXV13yP7/VZ7a13qOWoaArIMf+5euMgj6tPvQ94/z51oa+pc5inhfeNG 4QY/xWfL75d97yuP9trILq/EUpyRaKjFXFScCAD740rVNwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUi2FDcontvdkeIwceZ5hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEro/vNZeaCDq6KWXNfsjcwNnF0MXJySAiYSFw+tY4NwhaTuHBv PZDNxSEkMIlJou17NyOEM59J4tulbqYuRg4OZgF1iSlTckEaeAX0JJqePAYLCwvYSmy9HgQS ZhNQlXgw5xgjSJhTwEKi/yETSJgFKLxw3hpWEJtZQFviybsLrBBTbCR2fT3IBLGplVni48bP zCAJEQFhia2vepkgbpOV+HfxDPsERv5ZCEfMQnLELCRjFzAyr2IUKErNSaw00kssKMhJ1UvO z93ECA6uQucdjMeWWR1iFOBgVOLhXXG1PUSINbGsuDL3EKMEB7OSCG/I9I4QId6UxMqq1KL8 +KLSnNTiQ4zSHCxK4rw57xpDhATSE0tSs1NTC1KLYLJMHJxSDYzTNLSsCm/NOc+ouHoXX1N2 RqL0kY0/NwZEF95f0ztp2t4TmqXrGdm9TSS0/PLNcuU0rhwqu3mJP+vBA+P16RWakR/1m7UU ql8syPJk/p29WLVAdp1fGdOGvKlzNNjvs97w11vCl7rmy9lHIle9mDcsmd2df8XOcItOV7DQ 9Hv3X2RuvWH7jEGJpTgj0VCLuag4EQD4bufoKgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gMlJkZUUtZYvg8w2mtqc80FYjQM Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 19:16:37 -0000 > On Dec 9, 2014, at 17:22 , Ron wrote: >=20 > On Tue, Dec 09, 2014 at 05:03:34PM -0800, Bernard Aboba wrote: >> My bad. >>=20 >> New question: How can an endpoint that implements video but none of = the >> MTI codecs be construed as "WebRTC Compatible"? >=20 > And what about an endpoint that implements coffee making, but not = audio? ah, that=E2=80=99s different. =E2=80=9CI do video=E2=80=9D =E2=80=94 but I chose a strange codec and = I don=E2=80=99t interoperate with anyone else who does, only myself and =E2=80=9CI don=E2=80=99t do video at all=E2=80=9D are very different places to be. If I build a web app that is a baby monitor (relays just the sound of = the baby=E2=80=99s room) and doesn=E2=80=99t do video, I would hope that = it could claim to be a webRTC endpoint, no? Similarly for a silent = surveillance camera =E2=80=94 audio codec requirements are irrelevant = because it doesn=E2=80=99t do audio at all. The codec requirements are effectively conditional on supporting the = media. I suppose we could state that, and suggest that a webRTC endpoint = that does neither video nor audio is at best an odd duck, but I thought = it was fairly obvious. David Singer Manager, Software Standards, Apple Inc. From nobody Wed Dec 10 12:00:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988871A8BBE for ; Wed, 10 Dec 2014 12:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGbstwl08t-t for ; Wed, 10 Dec 2014 12:00:36 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by ietfa.amsl.com (Postfix) with ESMTP id 12BC51A89D3 for ; Wed, 10 Dec 2014 12:00:29 -0800 (PST) Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail06.adl2.internode.on.net with ESMTP; 11 Dec 2014 06:30:29 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id E85B1FFCCA for ; Thu, 11 Dec 2014 06:30:27 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ku65XhuI_tub for ; Thu, 11 Dec 2014 06:30:27 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 54469FF841 for ; Thu, 11 Dec 2014 06:30:27 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 4090680470; Thu, 11 Dec 2014 06:30:27 +1030 (ACDT) Date: Thu, 11 Dec 2014 06:30:27 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141210200027.GM19538@hex.shelbyville.oz> References: <20141210012208.GK19538@hex.shelbyville.oz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/oSyVZXmsjbXP8sZd8ahQplwsUqU Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 20:00:38 -0000 On Wed, Dec 10, 2014 at 11:15:48AM -0800, David Singer wrote: > > > On Dec 9, 2014, at 17:22 , Ron wrote: > > > > On Tue, Dec 09, 2014 at 05:03:34PM -0800, Bernard Aboba wrote: > >> My bad. > >> > >> New question: How can an endpoint that implements video but none of the > >> MTI codecs be construed as "WebRTC Compatible"? > > > > And what about an endpoint that implements coffee making, but not audio? > > ah, that’s different. > > “I do video†— but I chose a strange codec and I don’t interoperate > with anyone else who does, only myself > and > “I don’t do video at all†> > are very different places to be. > > If I build a web app that is a baby monitor (relays just the sound of > the baby’s room) and doesn’t do video, I would hope that it could > claim to be a webRTC endpoint, no? Similarly for a silent > surveillance camera — audio codec requirements are irrelevant because > it doesn’t do audio at all. I'm not really sure these are all that different in the sense of the categories of devices that the spec needs to differentiate between (which is the purpose of the definitions that we have about this). In all of the cases above, the device is not a WebRTC endpoint, since it can't be relied upon to do everything that the baseline WebRTC spec requires. If a real WebRTC endpoint could nonetheless still interact with it in some more limited way, then it falls into the catch-all category Which May Need A Better Name. I think it's correct to say these aren't WebRTC endpoints, and to say as little about them as we absolutely need to beyond acknowledging they will exist, and will likely do things we can't exhaustively enumerate. Even the case of "I can do video but none of the MTI codecs" could include things like future devices which do Daala in hardware, but don't have sufficient resources to do any other codec. A device like that could interop with a wide variety of other things, including WebRTC endpoints that support negotiating that codec, but it wouldn't itself be a card carrying WebRTC endpoint that provides the guaranteed interop and full functionality which being one does. It's not clear to me how this poses any sort of problem that we need to address beyond what is currently proposed for them? Ron From nobody Wed Dec 10 13:25:18 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277711A1A39 for ; Wed, 10 Dec 2014 13:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VnUlilrZc4u for ; Wed, 10 Dec 2014 13:25:09 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id A84B61A802A for ; Wed, 10 Dec 2014 13:25:08 -0800 (PST) Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 10 Dec 2014 16:25:02 -0500 Received: from XCT114CNC.rim.net (10.65.161.214) by XCT108CNC.rim.net (10.65.161.208) with Microsoft SMTP Server (TLS) id 14.3.210.2; Wed, 10 Dec 2014 16:25:01 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT114CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Wed, 10 Dec 2014 16:25:01 -0500 From: Gaelle Martin-Cocher To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of the room: mti codec) Thread-Index: AQHQFInbVBWK6YoLoEyBNpmZ4G+pQ5yJZckA//+unHCAAF82AP//2K7w Date: Wed, 10 Dec 2014 21:25:01 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF35EA81@XMB111CNC.rim.net> References: <92D0D52F3A63344CA478CF12DB0648AADF35E2BB@XMB111CNC.rim.net>, <54885FA3.3060602@gmail.com> <7594FB04B1934943A5C02806D1A2204B1D58C9A8@ESESSMB209.ericsson.se> <92D0D52F3A63344CA478CF12DB0648AADF35E6EF@XMB111CNC.rim.net> <54888C56.2060009@alvestrand.no> In-Reply-To: <54888C56.2060009@alvestrand.no> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KE59jXiiWI0U7HwzczuM4bP8k8s Subject: Re: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of the room: mti codec) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 21:25:13 -0000 Inline with [gmc] -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestran= d Sent: Wednesday, December 10, 2014 1:09 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of= the room: mti codec) Den 10. des. 2014 18:59, skrev Gaelle Martin-Cocher: > The main problem is with what the terminology covers and its=20 > inconsistent usage. >=20 > =20 >=20 > The WebRTC gateway in > https://tools.ietf.org/id/draft-alvestrand-rtcweb-gateways-01.txt is=20 > defined as a WebRTC-compatible endpoint with some requirements being=20 > applied to it. >=20 > I am not sure how the last sentence in the WebRTC-compatible endpoint=20 > definition "It is not constrained by this specification." applies to=20 > the gateway. Renaming the term is certainly possible. And this thread has certainly made the point that the -gateways draft needs= to be informative, not standards-track. [gmc] what does it change to be on the informative or standard track? VP8 i= s on the informative track too, right? Though VP8 or gateway would be "well= defined". I don't see why it should not be the same for legitimate other W= ebRTC-to-be-renamed endpoints, that makes them easier to market.=20 > =20 >=20 > If a mobile app is centered around text or text and audio, it should=20 > not be relegated in the WebRTC-compatible endpoint category and should=20 > be able to benefit from the WebRTC non browser/endpoint terminology . >=20 > =20 >=20 > If a WebRTC-compatible endpoint supports everything but a subset of=20 > functions (e.g. does not support bundle) there could be requirements=20 > applied to it; in IETF or in other standardization groups that are=20 > referring to the IETF terminology. I see absolutely no reason to go down this path. If you want a standard that specifies conformance to a spec that is part of= the WebRTC spec, you are of course free to try to do so. But I see no reason to join in on that journey. [GMC] conformance is only one reason. =20 Let's take 3 sensor based hardware devices that do not need one feature (sa= y audio for simplicity) and are used in home automation. Both indicate they= are WebRTC-compatible devices on their packaging. =20 Though they are different, one would have all the other WebRTC features inc= luding all security mechanisms, the second would have less security mechani= sms, and the third, well, hard to say what it does.=20 Tthe first device should benefit of the WebRTC enpoint terminology (as audi= o is not needed for that device), the second from the WebRTC-compatible ter= minology, the third maybe should not have any WebRTC related label. How do a user know which one to pick and if each of them will work with my = WebRTC mobile home automation apps with full protection or not if they are = all called a WebRTC-compatible endpoint? Basically that WebRTC-compatible label becomes irrelevant, though one produ= ct offers all of what is needed and not the other ones.=20 How is it clear to the user that the Mobile home automation WebRTC endpoint= is not the failing point when trying to interact with the second or third = device? Ga=EBlle _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Dec 10 13:35:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5836C1A802A for ; Wed, 10 Dec 2014 13:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhSO_K1DPPSa for ; Wed, 10 Dec 2014 13:34:56 -0800 (PST) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6FF1A1BF2 for ; Wed, 10 Dec 2014 13:34:50 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id le20so1891749vcb.38 for ; Wed, 10 Dec 2014 13:34:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zcJ42A9uGqCpaeQMftzoGwl58BrpShblU779gGY5pOc=; b=Jkih/msjOS9d8EOroma+bZ3o1WC3f6D5faZWKprMQFy/ot83VbtWVGvGXiRNcrdxln oE/ZSQREKmQOu3kjKs+1BC2u1lo3kmCBJcJI9x95W06uZzOtbHoICtW3P8RryxsrcO10 2CPwKUZKK4jmv1XVywHfs6yFPLwAFnf//X6IBpADwhIuhzTw60jKVSGyMbBkEiP9FuvJ eOrRNu5JLIjD+IvylC/fc5i+YY3t23WVRIFld+BhAoLAzQNREArs0d/S4tcQtkfHz0a5 BelNVmHxl/bJ+R5h3Mur0hrzXrpfPU05zJ9gxx5fEzZN7T1vSVT78LrsaZNh2Te6vJkX y8pQ== X-Gm-Message-State: ALoCoQlFW9Bb3//H7DId45/exAk8rzORUNEfZEIWe8kiCWRNGaEsBnshA1eUdSjGRr12daxl+Bq7 MIME-Version: 1.0 X-Received: by 10.52.10.198 with SMTP id k6mr3756440vdb.38.1418247289836; Wed, 10 Dec 2014 13:34:49 -0800 (PST) Received: by 10.31.139.9 with HTTP; Wed, 10 Dec 2014 13:34:49 -0800 (PST) In-Reply-To: References: <5486C48D.8040602@alvestrand.no> Date: Wed, 10 Dec 2014 16:34:49 -0500 Message-ID: From: Richard Barnes To: David Singer Content-Type: multipart/alternative; boundary=20cf30334e25ea2b290509e36dbf Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WDVI-U5CFdOQ5RqrxEH-ErpMf4Y Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 21:35:04 -0000 --20cf30334e25ea2b290509e36dbf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 9, 2014 at 12:32 PM, David Singer wrote: > > > On Dec 9, 2014, at 1:44 , Harald Alvestrand > wrote: > > > > I note that the "confirming sense of the room" thread has gotten a lot > > of messages that are not declaring a position on the question. > > > > I also note that from the messages on the thread, I can't figure out if > > Keith Drage, Gili, Monty Montgomery or Peter Saint-Andre have taken a > > position (I could guess, but I don't want to - besides, they might not > > want to take a position, which is perfectly OK). > > > > It would be nice for me as a reader if people could: > > > > - state their position on the "confirming sense of the room" thread > > - change the subject line when they want to say anything else > > > > That's my preference - of course, people who have "mute thread" in thei= r > > email readers might want the whole discussion to stay on thread, and > > will hate me for the last suggestion.... > > > > Harald > > Thanks, Harald, that would help. > > I would also like to know from those confirming the sense of the room, > whether THEY THEMSELVES intend to implement both codecs, or whether they > conveniently think they don=E2=80=99t need to, and it=E2=80=99s just a pr= oblem for other > people to handle. > > Honestly, a +1 for =E2=80=9Cthose other people should do it=E2=80=9D is m= eaningless. > This is a reminder that in IETF discussions, participants are individuals, and entitled to come to their technical positions however they want. I'd like to ask folks to refrain from calling the opinions of others "meaningless" or otherwise using derogatory language. In the IETF, every individual is entitled to put forward opinions and we debate those opinions on their own merits, not based on the putative motivations of the proponent. That is standard practice in the IETF, and this WG is no exception. Thanks, --Richard > > David Singer > Manager, Software Standards, Apple Inc. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf30334e25ea2b290509e36dbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 9, 2014 at 12:32 PM, David Singer <singer@apple.com>= wrote:

> On Dec 9, 2014, at 1:44 , Harald Alvestrand <harald@alvestrand.no> wrote:
>
> I note that the "confirming sense of the room" thread has go= tten a lot
> of messages that are not declaring a position on the question.
>
> I also note that from the messages on the thread, I can't figure o= ut if
> Keith Drage, Gili, Monty Montgomery or Peter Saint-Andre have taken a<= br> > position (I could guess, but I don't want to - besides, they might= not
> want to take a position, which is perfectly OK).
>
> It would be nice for me as a reader if people could:
>
> - state their position on the "confirming sense of the room"= thread
> - change the subject line when they want to say anything else
>
> That's my preference - of course, people who have "mute threa= d" in their
> email readers might want the whole discussion to stay on thread, and > will hate me for the last suggestion....
>
> Harald

Thanks, Harald, that would help.

I would also like to know from those confirming the sense of the room, whet= her THEY THEMSELVES intend to implement both codecs, or whether they conven= iently think they don=E2=80=99t need to, and it=E2=80=99s just a problem fo= r other people to handle.

Honestly, a +1 for =E2=80=9Cthose other people should do it=E2=80=9D is mea= ningless.


This is a remi= nder that in IETF discussions, participants are individuals, and entitled t= o come to their technical positions however they want.=C2=A0 I'd like t= o ask folks to refrain from calling the opinions of others "meaningles= s" or otherwise using derogatory language. In the IETF, every individu= al is entitled to put forward opinions and we debate those opinions on thei= r own merits, not based on the putative motivations of the proponent.=C2=A0= That is standard practice in the IETF, and this WG is no exception.

Thanks,
--Richard

= =C2=A0

David Singer
Manager, Software Standards, Apple Inc.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--20cf30334e25ea2b290509e36dbf-- From nobody Wed Dec 10 13:46:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BBF1A8973 for ; Wed, 10 Dec 2014 13:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_ckU4JYgsLh for ; Wed, 10 Dec 2014 13:46:39 -0800 (PST) Received: from albireo.enyo.de (albireo.enyo.de [46.237.207.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E804A1A8A95 for ; Wed, 10 Dec 2014 13:46:35 -0800 (PST) Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) id 1Xyp5Z-0004jr-HE; Wed, 10 Dec 2014 22:46:29 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1Xyp5Z-0002UL-7t; Wed, 10 Dec 2014 22:46:29 +0100 From: Florian Weimer To: Andrew Allen References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> Date: Wed, 10 Dec 2014 22:46:29 +0100 In-Reply-To: (Andrew Allen's message of "Tue, 9 Dec 2014 00:45:03 +0000") Message-ID: <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VhU8y3rR2uLiAo3SlyRFzqEwMiM Cc: "rtcweb@ietf.org" Subject: [rtcweb] H.264 patent licensing options (was: Re: confirming sense of the room: mti codec) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 21:46:41 -0000 * Andrew Allen: > Our preference is for H.264 to be the single MTI. We believe that > Cisco's open source royalty free code offer goes a long long way to > address the concerns of many related to IPR on H.264 Cisco is required to say this about the patent license they allegedly confer: =E2=80=9CTHIS PRODUCT IS LICENSED UNDER THE AVC PATENT PORTFOLIO LICENSE FOR THE PERSONAL USE OF A CONSUMER OR OTHER USES IN WHICH IT DOES NOT RECEIVE REMUNERATION TO (i) ENCODE VIDEO IN COMPLIANCE WITH THE AVC STANDARD (=E2=80=9CAVC VIDEO=E2=80=9D) AND/OR (ii) DECODE AVC VIDEO THAT WA= S ENCODED BY A CONSUMER ENGAGED IN A PERSONAL ACTIVITY AND/OR WAS OBTAINED FROM A VIDEO PROVIDER LICENSED TO PROVIDE AVC VIDEO. NO LICENSE IS GRANTED OR SHALL BE IMPLIED FOR ANY OTHER USE. ADDITIONAL INFORMATION MAY BE OBTAINED FROM MPEG LA, L.L.C. SEE HTTP://WWW.MPEGLA.COM=E2=80=9D This rules out commercial use. Doesn't this fail the =E2=80=9Creasonable= =E2=80=9D part of RAND because it is expected that commercial end users obtain a separate patent license of their own (which is not part of a product that can be purchased)? If this is still considered =E2=80=9Creasonable=E2= =80=9D, is the fact relevant that all published MPEG-LA material about H.264 refers to patent licensing in a broadcasting context (either the production side, or the receiver side)? This strongly suggests to me that they may lack the rights to license H.264 for use in video conferencing applications. Furthermore, a service using WebRTC is not a =E2=80=9Cconsumer=E2=80=9D, so= this patent license does not extend to the service provider. From nobody Wed Dec 10 13:50:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1EF1A89AF for ; Wed, 10 Dec 2014 13:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RySi_j8FxRj for ; Wed, 10 Dec 2014 13:50:51 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D511A89A3 for ; Wed, 10 Dec 2014 13:50:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418248251; x=2282161851; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HeUIuIaY/o1e+v4TgpB+p8ceshCvdov5g5FgUvCmDLA=; b=ILG9gvl8w9Wi4w1qqRREbj7AbzPrgDXwD36UU2bZAWNpulzJ9NA3iLylCU5cn3V9 WKBJ3I4SYIGthwtolIs1HcKgdYksNtBUoJY6Diu8upwhZnA3SYf6bdL94gF0sw5s 7ckK28XpGBZsBkqwi4UYQnvSukHm/zRDdwgSPYjqc+Iqn/iwiIC+bRkxdc/TgsMf pBJb7ra4mvghL/KFqaWun69laZT8j6fMlmDRU24/vnBcT4/VgBFnMQUbyJL31URd ghj/3i9Lg8wGaDMckBmIyS7n/YTAgk31ocXB0OBXJLXMIQN5o6G6j5T2m6UHlIOK OYHD2i6klQVGf9IGvvW/ZA==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 3B.FC.06819.B30C8845; Wed, 10 Dec 2014 13:50:51 -0800 (PST) X-AuditID: 11973e13-f79656d000001aa3-be-5488c03b3432 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id BA.4D.05998.C40C8845; Wed, 10 Dec 2014 13:51:08 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGD002JPZCQNK10@marigold.apple.com> for rtcweb@ietf.org; Wed, 10 Dec 2014 13:50:51 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <20141210200027.GM19538@hex.shelbyville.oz> Date: Wed, 10 Dec 2014 13:50:50 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <20141210012208.GK19538@hex.shelbyville.oz> <20141210200027.GM19538@hex.shelbyville.oz> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUi2FAYrmt9oCPEYM4OaYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVseHeBPaCNrmKWf+3MzcwTpXoYuTgkBAwkdj3WKiLkRPIFJO4 cG89WxcjF4eQwF5GiQdLP7NDJEwkfq3/zwyRmMQk0b1lH5Qzn0niwMbjjCCTmAXUJaZMyQVp 4BXQk2h68pgJJCwsYCux9XoQSJhNQFXiwZxjYNWcAhYSh/qDQcIsQOFve1Yxg9jMAtoST95d YIWYYiPRcH8aWFxI4BmzxI4f8SC2iICwxNZXvUwQp8lK/Lt4hh3kGgmBp6wS5/uWM09gFJqF cNAsJAfNQrJiASPzKkah3MTMHN3MPFO9xIKCnFS95PzcTYygQJ1uJ7yD8fQqq0OMAhyMSjy8 K662hwixJpYVV+YeYpTmYFES5z2yGygkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMTLV6OXJ /+K33t6rVru0WniS1pL7L69nv1m4UDz5GO/lFxMnlx14W3uh+UXyC5n/ApHVVmf++66SXDYn 76lX15mS2yseRSWn3rJfvfnEpAtVHBbvr0f4MvvaGUmu0ZFQ5C76vKWJ92Dkz6tTomsmxMa/ /idXXpt66ex5zcNRe8VanHv0T7V8KFFiKc5INNRiLipOBABp7O/LNQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUi2FDcoutzoCPEYMF/G4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVseHeBPaCNrmKWf+3MzcwTpXoYuTkkBAwkfi1/j8zhC0mceHe erYuRi4OIYFJTBLdW/YxQzjzmSQObDzO2MXIwcEsoC4xZUouSAOvgJ5E05PHTCBhYQFbia3X g0DCbAKqEg/mHAOr5hSwkDjUHwwSZgEKf9uzCmwVs4C2xJN3F1ghpthINNyfBhYXEnjGLLHj RzyILSIgLLH1VS8TxGmyEv8unmGfwMg/C+GGWUhumIVk6gJG5lWMAkWpOYmVJnqJBQU5qXrJ +bmbGMGhVRi+g/HfMqtDjAIcjEo8vCuutocIsSaWFVfmHmKU4GBWEuH9sq0jRIg3JbGyKrUo P76oNCe1+BCjNAeLkjhv87vGECGB9MSS1OzU1ILUIpgsEwenVAOj2AebB0Wdmx9zJMSxPnn4 9iO/57I/Wr//1yfnR7zYqXIrmsOd9cC/DcJh0oUKohx+kSyX/vLP+5LSkufJlCBz4dTM36zL 8oK/LRMXdLXd83iNRJ7QO98bhusulR1SOjX5fOW8gy/S6gpPTHLP3696a+fGmevFDW94/9kl 9fLe0my+G0JZIXH6SizFGYmGWsxFxYkAwc5slSkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Jgaz5Wy1Fv9RBh3Z57YSEwqZCsM Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 21:50:53 -0000 Hi Ron I don=E2=80=99t think we need to change definitions. In some specs, = there is an explicit =E2=80=9Cif the device supports the audio media = type, it must=E2=80=A6=E2=80=9D and I took it as implicit that that was = the case for the codecs for a given media type here. Users would not = expect a device that states it doesn=E2=80=99t do audio to interop on = audio. But if a device claims to be a general-purpose device that = supports audio and video in webRTC, I think we=E2=80=99d all like it if = it actually interoperated, right? Isn=E2=80=99t that the main thrust of = looking for MTI codecs? Yes, of course there is always room for experimental devices, or devices = intended for more controlled environments (=E2=80=98we use the webrtc = protocols but only the theora codec=E2=80=99 etc.), but they are then = rather qualified in their claims. =E2=80=9COnly suitable for use = in=E2=80=A6=E2=80=9D, =E2=80=9Cexperimental, not general purpose=E2=80=A6=E2= =80=9D and so on. > On Dec 10, 2014, at 12:00 , Ron wrote: >=20 > On Wed, Dec 10, 2014 at 11:15:48AM -0800, David Singer wrote: >>=20 >>> On Dec 9, 2014, at 17:22 , Ron wrote: >>>=20 >>> On Tue, Dec 09, 2014 at 05:03:34PM -0800, Bernard Aboba wrote: >>>> My bad. >>>>=20 >>>> New question: How can an endpoint that implements video but none = of the >>>> MTI codecs be construed as "WebRTC Compatible"? >>>=20 >>> And what about an endpoint that implements coffee making, but not = audio? >>=20 >> ah, that=E2=80=99s different. >>=20 >> =E2=80=9CI do video=E2=80=9D =E2=80=94 but I chose a strange codec = and I don=E2=80=99t interoperate >> with anyone else who does, only myself >> and >> =E2=80=9CI don=E2=80=99t do video at all=E2=80=9D >>=20 >> are very different places to be. >>=20 >> If I build a web app that is a baby monitor (relays just the sound of >> the baby=E2=80=99s room) and doesn=E2=80=99t do video, I would hope = that it could >> claim to be a webRTC endpoint, no? Similarly for a silent >> surveillance camera =E2=80=94 audio codec requirements are irrelevant = because >> it doesn=E2=80=99t do audio at all. >=20 > I'm not really sure these are all that different in the sense of the > categories of devices that the spec needs to differentiate between > (which is the purpose of the definitions that we have about this). >=20 > In all of the cases above, the device is not a WebRTC endpoint, since > it can't be relied upon to do everything that the baseline WebRTC spec > requires. If a real WebRTC endpoint could nonetheless still interact > with it in some more limited way, then it falls into the catch-all > category Which May Need A Better Name. >=20 > I think it's correct to say these aren't WebRTC endpoints, and to say > as little about them as we absolutely need to beyond acknowledging = they > will exist, and will likely do things we can't exhaustively enumerate. >=20 >=20 > Even the case of "I can do video but none of the MTI codecs" could > include things like future devices which do Daala in hardware, but > don't have sufficient resources to do any other codec. A device > like that could interop with a wide variety of other things, > including WebRTC endpoints that support negotiating that codec, but > it wouldn't itself be a card carrying WebRTC endpoint that provides > the guaranteed interop and full functionality which being one does. >=20 > It's not clear to me how this poses any sort of problem that we > need to address beyond what is currently proposed for them? >=20 > Ron >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb David Singer Manager, Software Standards, Apple Inc. From nobody Wed Dec 10 13:58:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292571A887B for ; Wed, 10 Dec 2014 13:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2UWCQvh4J4K for ; Wed, 10 Dec 2014 13:58:03 -0800 (PST) Received: from relay.mailchannels.net (si-002-i157.relay.mailchannels.net [108.178.49.169]) by ietfa.amsl.com (Postfix) with ESMTP id D4FBC1A0025 for ; Wed, 10 Dec 2014 13:58:02 -0800 (PST) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-204-4-183.us-west-2.compute.internal [10.204.4.183]) by relay.mailchannels.net (Postfix) with ESMTPA id 81667420C for ; Wed, 10 Dec 2014 21:58:00 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.216.27.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.2); Wed, 10 Dec 2014 21:58:01 GMT X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1418248680830:1735061409 X-MC-Ingress-Time: 1418248680829 Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:54749 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XypGg-0005qx-5y for rtcweb@ietf.org; Wed, 10 Dec 2014 15:57:58 -0600 Message-ID: <5488C1E4.3060206@jesup.org> Date: Wed, 10 Dec 2014 16:57:56 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5486C48D.8040602@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080605030301040703010309" X-AuthUser: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NPA_fHUZC190pxPgNDUsUklXGMk Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 21:58:05 -0000 This is a multi-part message in MIME format. --------------080605030301040703010309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/9/2014 3:10 PM, Bernard Aboba wrote: > David Singer said: > > "I am trying to find out a simple answer: how many endpoints would, > in fact, expect to support both codecs?" > > [BA] The proposal has built-in incentives for implementers in each > category to either ignore the recommendations or ignore > interoperability (or both). > > As it stands, the proposal doesn't require that "WebRTC-compatible > endpoints" support either H.264 or VP8. I understand why an endpoint > not supporting video shouldn't have to, but if the WebRTC-compatible > endpoint does support video, why shouldn't it support at least one of > the MTI codecs? The way it is written a WebRTC-compatible endpoint > that supported only H.261 would be compliant while being able to > communicate with either browsers or non-browsers, which seems silly. I've seen a device that supports webrtc but can't reasonably handle VP8 or H.264, but can run an implementation of H.261, so this really exists. I wouldn't call it great, but it's not non-sensical. As mentioned, Firefox as shipping (for months now) in release supports H.264 and VP8 (and perhaps more soon). -- Randell Jesup -- rjesup a t mozilla d o t com --------------080605030301040703010309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/9/2014 3:10 PM, Bernard Aboba wrote:
David Singer said: 

"I am trying to find out a simple answer:  how many endpoints would, in fact, expect to support both codecs?"

[BA]  The proposal has built-in incentives for implementers in each category to either ignore the recommendations or ignore interoperability (or both).   

As it stands, the proposal doesn't require that "WebRTC-compatible endpoints" support either H.264 or VP8.  I understand why an endpoint not supporting video shouldn't have to, but if the WebRTC-compatible endpoint does support video, why shouldn't it support at least one of the MTI codecs?   The way it is written a WebRTC-compatible endpoint that supported only H.261 would be compliant while being able to communicate with either browsers or non-browsers, which seems silly.

I've seen a device that supports webrtc but can't reasonably handle VP8 or H.264, but can run an implementation of H.261, so this really exists.  I wouldn't call it great, but it's not non-sensical.

As mentioned, Firefox as shipping (for months now) in release supports H.264 and VP8 (and perhaps more soon).

-- 
Randell Jesup -- rjesup a t mozilla d o t com
--------------080605030301040703010309-- From nobody Wed Dec 10 13:59:14 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC901A0155 for ; Wed, 10 Dec 2014 13:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEWGJ30oaLJd for ; Wed, 10 Dec 2014 13:59:11 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6237B1A1B13 for ; Wed, 10 Dec 2014 13:59:06 -0800 (PST) Received: by mail-oi0-f48.google.com with SMTP id u20so2778383oif.35 for ; Wed, 10 Dec 2014 13:59:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AiEvxgTFpFougtEHLDAG4+Wqi1i1rB+e8qFIJh8wL0k=; b=ZtKkFlsmuYwULnJvY0mV+P4Yd3Elv1pTJOGiSMws7e+tWB/3vBi7khP7EayZjgOJKJ BDeW4kdN9C/fiTcvBtr2n0jMtkFeuWpRCOIxl/XzTHgHyjV1Cw1NfcAk6X5/2Ng/sTsZ zfP38tKO24kRjepMJ6wNSkt5pY487Bn9H3PiLGu7TCMTA+Mgg0A6wlrfumnW461jTf2n MqgcMSLjTXQBJm3eXTuSH0lD5Aw75XunrqmVlZ3kTNNtf8lIsOQZgg3/japKjUhib07C gv8i+dkIaKuS+Wcsiqs0yZjBxS56ZpVIVmg/KelwaP949UxrL0op0/PdsXD/xByoHXgO GCJA== MIME-Version: 1.0 X-Received: by 10.202.111.3 with SMTP id m3mr3986313oic.16.1418248745674; Wed, 10 Dec 2014 13:59:05 -0800 (PST) Received: by 10.202.107.19 with HTTP; Wed, 10 Dec 2014 13:59:05 -0800 (PST) In-Reply-To: <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> Date: Wed, 10 Dec 2014 13:59:05 -0800 Message-ID: From: Martin Thomson To: Florian Weimer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/48E--nAsTgnZjd6oCBDr7O-GPOQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 patent licensing options (was: Re: confirming sense of the room: mti codec) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 21:59:12 -0000 On 10 December 2014 at 13:46, Florian Weimer wrote: > This rules out commercial use. Doesn't this fail the =E2=80=9Creasonable= =E2=80=9D > part of RAND because it is expected that commercial end users obtain a > separate patent license of their own (which is not part of a product > that can be purchased)? If this is still considered =E2=80=9Creasonable= =E2=80=9D, is > the fact relevant that all published MPEG-LA material about H.264 > refers to patent licensing in a broadcasting context (either the > production side, or the receiver side)? This strongly suggests to me > that they may lack the rights to license H.264 for use in video > conferencing applications. I recommend that you consult counsel on these sorts of questions. Seeking legal opinion on an internet mailing list might not produce the best results. From nobody Wed Dec 10 14:33:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03F41AC3A7 for ; Wed, 10 Dec 2014 14:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qp1bA9PPpsow for ; Wed, 10 Dec 2014 14:32:52 -0800 (PST) Received: from relay.mailchannels.net (aso-006-i440.relay.mailchannels.net [23.91.64.121]) by ietfa.amsl.com (Postfix) with ESMTP id 405611AC3A5 for ; Wed, 10 Dec 2014 14:32:40 -0800 (PST) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (ip-10-237-13-110.us-west-2.compute.internal [10.237.13.110]) by relay.mailchannels.net (Postfix) with ESMTPA id D1A65604A4 for ; Wed, 10 Dec 2014 22:32:38 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [10.248.11.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.2); Wed, 10 Dec 2014 22:32:39 GMT X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1418250759168:4047187328 X-MC-Ingress-Time: 1418250759167 Received: from pool-71-175-4-200.phlapa.fios.verizon.net ([71.175.4.200]:54937 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XypoD-000Aip-NS for rtcweb@ietf.org; Wed, 10 Dec 2014 16:32:37 -0600 Message-ID: <5488CA03.6060805@jesup.org> Date: Wed, 10 Dec 2014 17:32:35 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20141210012208.GK19538@hex.shelbyville.oz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed X-AuthUser: randell@jesup.org Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZT13ozdHwSlz5501alE7s9RHQRQ Subject: Re: [rtcweb] WebRTC compatible endpoints (WAS: confirming sense of the room: mti codec) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 22:32:56 -0000 Moving to the other thread for clarity... On 12/10/2014 2:15 PM, David Singer wrote: > If I build a web app that is a baby monitor (relays just the sound of t= he baby=E2=80=99s room) and doesn=E2=80=99t do video, I would hope that i= t could claim to be a webRTC endpoint, no? Similarly for a silent survei= llance camera =E2=80=94 audio codec requirements are irrelevant because i= t doesn=E2=80=99t do audio at all. Or one that does decode only (monitor viewer) or encode only (monitor=20 sender). These wouldn't full WebRTC endpoint, but could be=20 webrtc-compatible. > The codec requirements are effectively conditional on supporting the me= dia. I suppose we could state that, and suggest that a webRTC endpoint th= at does neither video nor audio is at best an odd duck, but I thought it = was fairly obvious. A WebRTC-compatible endpoint that implements DataChannels but neither=20 audio nor video could certainly exist. (And might to do p2p data stuff=20 leveraging all the NAT-traversal/encryption/etc infra we've defined.) I wanted/want VP8 only. But I think this compromise (which is imperfect=20 from everyone's definition) fits the meaning of compromise well. No one=20 will leave really "happy"; some may leave upset, but I think it's the=20 best we can get and better than status quo. And I agree with Adam on=20 one point: Ron@debian has made some very good arguments (that I largely=20 agreed with) over this years-long discussion, in a very principled way. =20 If he can bring himself to accept this, what's stopping others? I=20 realize some companies have stakes (financial, code, etc) in one side or=20 the other, but this is the IETF and people participate as individuals. =20 The people participating from Mozilla have definitely not all "voted"=20 the same way during this process, for example. --=20 Randell Jesup -- rjesup a t mozilla d o t com From nobody Wed Dec 10 15:00:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6E11A1A4B for ; Wed, 10 Dec 2014 15:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAkNZnn3FUwr for ; Wed, 10 Dec 2014 15:00:28 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF311A19FA for ; Wed, 10 Dec 2014 15:00:28 -0800 (PST) Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail06.adl2.internode.on.net with ESMTP; 11 Dec 2014 09:30:15 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id CACD4FFCCA for ; Thu, 11 Dec 2014 09:30:13 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id I63X415FXQwp for ; Thu, 11 Dec 2014 09:30:13 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 2A1D9FF82E for ; Thu, 11 Dec 2014 09:30:13 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 168D780470; Thu, 11 Dec 2014 09:30:13 +1030 (ACDT) Date: Thu, 11 Dec 2014 09:30:13 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141210230012.GN19538@hex.shelbyville.oz> References: <20141210012208.GK19538@hex.shelbyville.oz> <20141210200027.GM19538@hex.shelbyville.oz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GhQmkemwyKmInrL8fTlj5Gzvohg Subject: [rtcweb] WebRTC endpoint categories X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 23:00:30 -0000 [Changing the subject of this thread as requested earlier] On Wed, Dec 10, 2014 at 01:50:50PM -0800, David Singer wrote: > > I don’t think we need to change definitions. In some specs, there is > an explicit “if the device supports the audio media type, it must…†> and I took it as implicit that that was the case for the codecs for a > given media type here. Users would not expect a device that states it > doesn’t do audio to interop on audio. But if a device claims to be a > general-purpose device that supports audio and video in webRTC, I > think we’d all like it if it actually interoperated, right? Isn’t that > the main thrust of looking for MTI codecs? I'm afraid I'm missing the crux of the distinction you see if you think we're not just agreeing with each other now :) A device is a WebRTC endpoint (browser or not) if it implements the mandatory requirements of the WebRTC protocol (which includes MTI codecs). Anything which doesn't do that, but can otherwise do some subset of WebRTC to operate with WebRTC endpoints, in some unspecified here way, is in the WebRTC-compatible class of devices. Whatever we end up calling those, if the definition remains the same, they can do anything they please, however they please, which obviously video and audio is a subset of. I don't see how we could sensibly say they must not do either of those things at all, when the definition says they are not constrained by, or defined in, or implementations of, this spec. There's no confusion about the expectations for interop though, because they are "non-WebRTC" devices, so nothing at all can be expected except what the device itself says it is actually capable of. They might implement some melange of various standards or they might be an entirely proprietary thing. The IETF isn't really concerned with marketing appellations, these classes are just language to use in the spec itself when we need to say something referring to these categories of things. A device which doesn't implement the WebRTC protocol, doesn't implement the WebRTC protocol. It doesn't really matter what its reasons for that might be, or what other things it does implement. Does it? If I implement a protocol that shares the same first 8 octets with an IPv4 header, that doesn't mean I have implemented RFC 791. Ron From nobody Wed Dec 10 15:05:01 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4701A1AB3 for ; Wed, 10 Dec 2014 15:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0o1AiLi3lY-x for ; Wed, 10 Dec 2014 15:04:57 -0800 (PST) Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com [209.85.160.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BF5C1A1AE3 for ; Wed, 10 Dec 2014 15:04:47 -0800 (PST) Received: by mail-yk0-f177.google.com with SMTP id 9so1689590ykp.22 for ; Wed, 10 Dec 2014 15:04:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qQ4RTVwBrYei+1U12szxN8TqZ2jO1duKtNeCYV41XT0=; b=Zv0S09UKrDyqbmovJ1HD+JoQNoRnjJB5GzftZzjvfbFdXC1fCJv7RhSYg/m2zhjI3t 9KosKY9cCClOlUEMI3Vm0Ap5oGMfFvBSTvzUm2zAgpT7b1QBAaA0Pk3u2fw0+xDBFE0Y ++fuAPt+7c6aK4npbjpui3nzOZYqdsDvYKh9v6OG2l3qRruqQ2GdaagBE7RGbFQtn1SR yo/nXkKH6tQbl9/2Ll3rbuJDn29/TigXgJ2vp5KB0HW9JDNWj1SHtLHU2mgQ6pjqZMIs juOqBTZ9rXFvRxFYGNJLu3Zoci5uU+ZKwhKVIbpEzyjBzWYibJMbx7rva17HbPkf5M8d vljw== X-Gm-Message-State: ALoCoQlPiPq/VUxmLkWu7fwvhktdP2Wl7bVJzri1F1Ui3HpfAJaM9ck+I++h/OSXN7Sw1v3m978Z MIME-Version: 1.0 X-Received: by 10.170.150.213 with SMTP id r204mr5876171ykc.48.1418252686810; Wed, 10 Dec 2014 15:04:46 -0800 (PST) Received: by 10.170.38.200 with HTTP; Wed, 10 Dec 2014 15:04:46 -0800 (PST) In-Reply-To: References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> Date: Wed, 10 Dec 2014 18:04:46 -0500 Message-ID: From: Richard Barnes To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113a57d29976890509e4af97 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Sj7qR22hjxWQQ6VeVXUStxuxRow Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 patent licensing options (was: Re: confirming sense of the room: mti codec) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 23:04:59 -0000 --001a113a57d29976890509e4af97 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 This conversation is out of scope for this mailing list. On Wed, Dec 10, 2014 at 4:59 PM, Martin Thomson wrote: > On 10 December 2014 at 13:46, Florian Weimer wrote: > > This rules out commercial use. Doesn't this fail the =E2=80=9Creasonab= le=E2=80=9D > > part of RAND because it is expected that commercial end users obtain a > > separate patent license of their own (which is not part of a product > > that can be purchased)? If this is still considered =E2=80=9Creasonabl= e=E2=80=9D, is > > the fact relevant that all published MPEG-LA material about H.264 > > refers to patent licensing in a broadcasting context (either the > > production side, or the receiver side)? This strongly suggests to me > > that they may lack the rights to license H.264 for use in video > > conferencing applications. > > I recommend that you consult counsel on these sorts of questions. > Seeking legal opinion on an internet mailing list might not produce > the best results. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a113a57d29976890509e4af97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1=C2=A0

This conversation is out of sc= ope for this mailing list.

On Wed, Dec 10, 2014 at 4:59 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 10 December 2014 at 13:46, Florian Weimer <= fw@deneb.enyo.de> wrote:
> This rules out commercial use.=C2=A0 Doesn't this fail the =E2=80= =9Creasonable=E2=80=9D
> part of RAND because it is expected that commercial end users obtain a=
> separate patent license of their own (which is not part of a product > that can be purchased)?=C2=A0 If this is still considered =E2=80=9Crea= sonable=E2=80=9D, is
> the fact relevant that all published MPEG-LA material about H.264
> refers to patent licensing in a broadcasting context (either the
> production side, or the receiver side)?=C2=A0 This strongly suggests t= o me
> that they may lack the rights to license H.264 for use in video
> conferencing applications.

I recommend that you consult counsel on these sorts of questions. Seeking legal opinion on an internet mailing list might not produce
the best results.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--001a113a57d29976890509e4af97-- From nobody Wed Dec 10 15:13:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923691A001B for ; Wed, 10 Dec 2014 15:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awH_VtxnN0dz for ; Wed, 10 Dec 2014 15:13:23 -0800 (PST) Received: from smtpdg5.aruba.it (smtpdg95.aruba.it [62.149.158.95]) by ietfa.amsl.com (Postfix) with ESMTP id BBCF11A1A12 for ; Wed, 10 Dec 2014 15:13:22 -0800 (PST) Received: from rainpc ([82.61.122.170]) by smtpcmd05.ad.aruba.it with bizsmtp id RzDH1p00N3ghNjW01zDJNZ; Thu, 11 Dec 2014 00:13:20 +0100 Date: Thu, 11 Dec 2014 00:13:17 +0100 From: Lorenzo Miniero To: Richard Barnes Message-ID: <20141211001317.0f8760c8@rainpc> In-Reply-To: References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> Organization: Meetecho X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/iB0WG4CLPGAuwMx4M4ebFNIHbJ4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 patent licensing options (was: Re: confirming sense of the room: mti codec) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 23:13:25 -0000 On Wed, 10 Dec 2014 18:04:46 -0500 Richard Barnes wrote: > +1 >=20 > This conversation is out of scope for this mailing list. >=20 And yet it does raise some flags, though. Had I blindly trusted the claims = that have been made on this ML (not out of scope at the time, apparently) a= bout what the infamous plugin allegedly provided, I could have ended up off= ering services based on openH264 and hopefully try and make some money out = of it: only to find myself suitable in the process, and in perfectly good f= aith. I don't think raising awareness on such a delicate issue that matters= to the discussion is so out of scope. Lorenzo > On Wed, Dec 10, 2014 at 4:59 PM, Martin Thomson > wrote: >=20 > > On 10 December 2014 at 13:46, Florian Weimer wrote: > > > This rules out commercial use. Doesn't this fail the =E2=80=9Creason= able=E2=80=9D > > > part of RAND because it is expected that commercial end users obtain a > > > separate patent license of their own (which is not part of a product > > > that can be purchased)? If this is still considered =E2=80=9Creasona= ble=E2=80=9D, is > > > the fact relevant that all published MPEG-LA material about H.264 > > > refers to patent licensing in a broadcasting context (either the > > > production side, or the receiver side)? This strongly suggests to me > > > that they may lack the rights to license H.264 for use in video > > > conferencing applications. > > > > I recommend that you consult counsel on these sorts of questions. > > Seeking legal opinion on an internet mailing list might not produce > > the best results. > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > --=20 Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From nobody Wed Dec 10 15:15:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20E21A0105 for ; Wed, 10 Dec 2014 15:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUpGU-h3gYDZ for ; Wed, 10 Dec 2014 15:15:31 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD001A001B for ; Wed, 10 Dec 2014 15:15:31 -0800 (PST) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 10 Dec 2014 18:15:13 -0500 Received: from XCT114CNC.rim.net (10.65.161.214) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.210.2; Wed, 10 Dec 2014 18:15:13 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT114CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Wed, 10 Dec 2014 18:15:12 -0500 From: Andrew Allen To: David Singer , "rtcweb@ietf.org" Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEJCKEBti1FXXNkmH1ALOez9gJ5yIDJ6AgAAEMgCAABkhAIAAMv0AgAAFMACAASv7AP//0R/A Date: Wed, 10 Dec 2014 23:15:12 +0000 Message-ID: References: <20141210012208.GK19538@hex.shelbyville.oz> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Vj1vP-hBIBheDN3a3lnc_WTd8Vc Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 23:15:34 -0000 SXQgY291bGQgYmUgYSB0ZWxlbWV0cnkgZGV2aWNlIHN1cHBvcnRpbmcgb25seSB0aGUgZGF0YSBj aGFubmVsIHNvIG5vIGF1ZGlvIG9yIHZpZGVvIChub3Qgc3VjaCBhbiBvZGQgZHVjayBJIHRoaW5r KS4NCg0KQW5kcmV3DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBydGN3ZWIg W21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhdmlkIFNpbmdl cg0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxMCwgMjAxNCAyOjE2IFBNDQpUbzogcnRjd2Vi QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gY29uZmlybWluZyBzZW5zZSBvZiB0aGUg cm9vbTogbXRpIGNvZGVjDQoNCg0KPiBPbiBEZWMgOSwgMjAxNCwgYXQgMTc6MjIgLCBSb24gPHJv bkBkZWJpYW4ub3JnPiB3cm90ZToNCj4gDQo+IE9uIFR1ZSwgRGVjIDA5LCAyMDE0IGF0IDA1OjAz OjM0UE0gLTA4MDAsIEJlcm5hcmQgQWJvYmEgd3JvdGU6DQo+PiBNeSBiYWQuDQo+PiANCj4+IE5l dyBxdWVzdGlvbjogIEhvdyBjYW4gYW4gZW5kcG9pbnQgdGhhdCBpbXBsZW1lbnRzIHZpZGVvIGJ1 dCBub25lIG9mIA0KPj4gdGhlIE1USSBjb2RlY3MgYmUgY29uc3RydWVkIGFzICJXZWJSVEMgQ29t cGF0aWJsZSI/DQo+IA0KPiBBbmQgd2hhdCBhYm91dCBhbiBlbmRwb2ludCB0aGF0IGltcGxlbWVu dHMgY29mZmVlIG1ha2luZywgYnV0IG5vdCBhdWRpbz8NCg0KYWgsIHRoYXTigJlzIGRpZmZlcmVu dC4NCg0K4oCcSSBkbyB2aWRlb+KAnSDigJQgIGJ1dCBJIGNob3NlIGEgc3RyYW5nZSBjb2RlYyBh bmQgSSBkb27igJl0IGludGVyb3BlcmF0ZSB3aXRoIGFueW9uZSBlbHNlIHdobyBkb2VzLCBvbmx5 IG15c2VsZg0KICAgYW5kDQrigJxJIGRvbuKAmXQgZG8gdmlkZW8gYXQgYWxs4oCdDQoNCmFyZSB2 ZXJ5IGRpZmZlcmVudCBwbGFjZXMgdG8gYmUuDQoNCklmIEkgYnVpbGQgYSB3ZWIgYXBwIHRoYXQg aXMgYSBiYWJ5IG1vbml0b3IgKHJlbGF5cyBqdXN0IHRoZSBzb3VuZCBvZiB0aGUgYmFieeKAmXMg cm9vbSkgYW5kIGRvZXNu4oCZdCBkbyB2aWRlbywgSSB3b3VsZCBob3BlIHRoYXQgaXQgY291bGQg Y2xhaW0gdG8gYmUgYSB3ZWJSVEMgZW5kcG9pbnQsIG5vPyAgU2ltaWxhcmx5IGZvciBhIHNpbGVu dCBzdXJ2ZWlsbGFuY2UgY2FtZXJhIOKAlCBhdWRpbyBjb2RlYyByZXF1aXJlbWVudHMgYXJlIGly cmVsZXZhbnQgYmVjYXVzZSBpdCBkb2VzbuKAmXQgZG8gYXVkaW8gYXQgYWxsLg0KDQpUaGUgY29k ZWMgcmVxdWlyZW1lbnRzIGFyZSBlZmZlY3RpdmVseSBjb25kaXRpb25hbCBvbiBzdXBwb3J0aW5n IHRoZSBtZWRpYS4gSSBzdXBwb3NlIHdlIGNvdWxkIHN0YXRlIHRoYXQsIGFuZCBzdWdnZXN0IHRo YXQgYSB3ZWJSVEMgZW5kcG9pbnQgdGhhdCBkb2VzIG5laXRoZXIgdmlkZW8gbm9yIGF1ZGlvIGlz IGF0IGJlc3QgYW4gb2RkIGR1Y2ssIGJ1dCBJIHRob3VnaHQgaXQgd2FzIGZhaXJseSBvYnZpb3Vz Lg0KDQpEYXZpZCBTaW5nZXINCk1hbmFnZXIsIFNvZnR3YXJlIFN0YW5kYXJkcywgQXBwbGUgSW5j Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRj d2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K From nobody Wed Dec 10 15:17:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B581D1A001B for ; Wed, 10 Dec 2014 15:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k1gUwTA49JC for ; Wed, 10 Dec 2014 15:17:52 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A991A0105 for ; Wed, 10 Dec 2014 15:17:52 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex7so12860276wid.9 for ; Wed, 10 Dec 2014 15:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=fdK1w6bYDcrNyJaTUrQRqLqR5JcM3rDXnuNbgREfGRw=; b=dHiA+UdoWcPgakos6RvnlWwzGtYKphM87yrR15fjqU89qHAJ2aJerTjEnBDNd44xoj hwrQE8QH55U778j88WxPaiHZSu2SYmv4AW5nrStSzADMOI9V9mesIyYX/2rc8r9C/OZ9 3N19rU+LpeYvM1gM2UXaU/dIPbu563NBFoeHOCmM63icRRI3yE/iC8CdwlkJb74pJafv 1/91YYGXcBv/eZ/JmXVyiGx4sOfJVlzZtsIuSsoD7wBshAg/cbRldVUPVw/ZhKhcR9sL w5Z0T0eiwN4uZT9vq5lfSGFkxF+2vzLDr/PqGuhL5hQLvQrCx7bmXuFeNygz3BDoja7s FByg== X-Received: by 10.180.211.2 with SMTP id my2mr10163972wic.3.1418253471072; Wed, 10 Dec 2014 15:17:51 -0800 (PST) Received: from [192.168.0.194] ([95.61.111.78]) by mx.google.com with ESMTPSA id n5sm569533wic.6.2014.12.10.15.17.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 15:17:50 -0800 (PST) Message-ID: <5488D49D.5040307@gmail.com> Date: Thu, 11 Dec 2014 00:17:49 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000606050706070205060403" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FZSygSDLnuzaSvU27owveZ1hBHE Subject: Re: [rtcweb] H.264 patent licensing options X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 23:17:54 -0000 This is a multi-part message in MIME format. --------------000606050706070205060403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit No it is not. The availability of OpenH264 was proposed here in this list as one argument in favor of adopting H264, so IMHO, this should be explained. Best regards Sergio On 11/12/2014 0:04, Richard Barnes wrote: > +1 > > This conversation is out of scope for this mailing list. > > On Wed, Dec 10, 2014 at 4:59 PM, Martin Thomson > > wrote: > > On 10 December 2014 at 13:46, Florian Weimer > wrote: > > This rules out commercial use. Doesn't this fail the "reasonable" > > part of RAND because it is expected that commercial end users > obtain a > > separate patent license of their own (which is not part of a product > > that can be purchased)? If this is still considered > "reasonable", is > > the fact relevant that all published MPEG-LA material about H.264 > > refers to patent licensing in a broadcasting context (either the > > production side, or the receiver side)? This strongly suggests > to me > > that they may lack the rights to license H.264 for use in video > > conferencing applications. > > I recommend that you consult counsel on these sorts of questions. > Seeking legal opinion on an internet mailing list might not produce > the best results. > > _______________________________________________ > 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 --------------000606050706070205060403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
No it is not.

The availability of OpenH264 was proposed here in this list as one argument in favor of adopting H264, so IMHO, this should be explained.

Best regards
Sergio
On 11/12/2014 0:04, Richard Barnes wrote:
+1 

This conversation is out of scope for this mailing list.

On Wed, Dec 10, 2014 at 4:59 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 10 December 2014 at 13:46, Florian Weimer <fw@deneb.enyo.de> wrote:
> This rules out commercial use.  Doesn't this fail the “reasonable”
> part of RAND because it is expected that commercial end users obtain a
> separate patent license of their own (which is not part of a product
> that can be purchased)?  If this is still considered “reasonable”, is
> the fact relevant that all published MPEG-LA material about H.264
> refers to patent licensing in a broadcasting context (either the
> production side, or the receiver side)?  This strongly suggests to me
> that they may lack the rights to license H.264 for use in video
> conferencing applications.

I recommend that you consult counsel on these sorts of questions.
Seeking legal opinion on an internet mailing list might not produce
the best results.

_______________________________________________
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

--------------000606050706070205060403-- From nobody Wed Dec 10 15:18:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278791A1B4B for ; Wed, 10 Dec 2014 15:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTqR0-xI01GO for ; Wed, 10 Dec 2014 15:17:59 -0800 (PST) Received: from smtpdg94.aruba.it (smtpdg96.aruba.it [62.149.158.96]) by ietfa.amsl.com (Postfix) with ESMTP id 66CBF1A1B2D for ; Wed, 10 Dec 2014 15:17:58 -0800 (PST) Received: from rainpc ([82.61.122.170]) by smtpcmd05.ad.aruba.it with bizsmtp id RzHu1p00Q3ghNjW01zHvfa; Thu, 11 Dec 2014 00:17:56 +0100 Date: Thu, 11 Dec 2014 00:17:54 +0100 From: Lorenzo Miniero To: Richard Barnes Message-ID: <20141211001754.77725b5d@rainpc> In-Reply-To: <20141211001317.0f8760c8@rainpc> References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> <20141211001317.0f8760c8@rainpc> Organization: Meetecho X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZR9szr0gF6E5jE1A8ZQ7Jw0GQKQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 patent licensing options (was: Re: confirming sense of the room: mti codec) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 23:18:02 -0000 On Thu, 11 Dec 2014 00:13:17 +0100 Lorenzo Miniero wrote: > On Wed, 10 Dec 2014 18:04:46 -0500 > Richard Barnes wrote: >=20 > > +1 > >=20 > > This conversation is out of scope for this mailing list. > >=20 >=20 >=20 > And yet it does raise some flags, though. Had I blindly trusted the claim= s that have been made on this ML (not out of scope at the time, apparently)= about what the infamous plugin allegedly provided, I could have ended up o= ffering services based on openH264 and hopefully try and make some money ou= t of it: only to find myself suitable in the process, and in perfectly good= faith. I don't think raising awareness on such a delicate issue that matte= rs to the discussion is so out of scope. >=20 PS: I guess "suitable" is not the word I was looking for (maybe "impeachabl= e"? I should work on my vocabulary!) but, hey, hope you got what I meant :-) L. > Lorenzo >=20 >=20 > > On Wed, Dec 10, 2014 at 4:59 PM, Martin Thomson > > wrote: > >=20 > > > On 10 December 2014 at 13:46, Florian Weimer wrote: > > > > This rules out commercial use. Doesn't this fail the =E2=80=9Creas= onable=E2=80=9D > > > > part of RAND because it is expected that commercial end users obtai= n a > > > > separate patent license of their own (which is not part of a product > > > > that can be purchased)? If this is still considered =E2=80=9Creaso= nable=E2=80=9D, is > > > > the fact relevant that all published MPEG-LA material about H.264 > > > > refers to patent licensing in a broadcasting context (either the > > > > production side, or the receiver side)? This strongly suggests to = me > > > > that they may lack the rights to license H.264 for use in video > > > > conferencing applications. > > > > > > I recommend that you consult counsel on these sorts of questions. > > > Seeking legal opinion on an internet mailing list might not produce > > > the best results. > > > > > > _______________________________________________ > > > rtcweb mailing list > > > rtcweb@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtcweb > > > >=20 >=20 > --=20 > Lorenzo Miniero, COB >=20 > Meetecho s.r.l. > Web Conferencing and Collaboration Tools > http://www.meetecho.com >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From nobody Wed Dec 10 15:20:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D951A1B32 for ; Wed, 10 Dec 2014 15:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCpwG0KAIiwD for ; Wed, 10 Dec 2014 15:19:59 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F211B1A0105 for ; Wed, 10 Dec 2014 15:19:58 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so4979013wgg.5 for ; Wed, 10 Dec 2014 15:19:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Rf/ulWSFvxazDZA9fqDZ7qYtpt0/x8cX5Z69aQ2erwM=; b=eF8Sl+LIhI1IiE2XdkfGdTvJw5mFHkJe8/qu/BOer+j6i6rxfBXwKbspRpqgH0iGvi XGrm4JTfhxPJZVOTqqDwVmwdEwhnl1taH2ndiZPaY+9HdKUdDhxLveSyu1jsXhqquNZM yC23Y6Uv/xOjMlM25ZrtzevIU1UlATmXJ1Zhb+8NUJOlkgmEtdXmKOjOLk1G69b59BWy K9YZ1HshnKiTR6XFj5Y16+2TnONIYidvK4lx7daEPMlREHkw20x1lahIV5//+IIcnrFv kClqzQN5LoYS+rsd4kzs3JD7CqpDKOiRagrqC4vn+y0njzyHWlcyIy6hVTK8bpr4N1Ox sPTw== X-Gm-Message-State: ALoCoQk2ItSoZ12BUOfgVbvo95VAc1HuJWCqNKLatl6pJ1XhXvHp4RJ80nrcQRmlCbPHY80bAA26 X-Received: by 10.194.175.69 with SMTP id by5mr10857453wjc.32.1418253597779; Wed, 10 Dec 2014 15:19:57 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com. [209.85.212.174]) by mx.google.com with ESMTPSA id gf6sm7671650wjc.11.2014.12.10.15.19.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 15:19:56 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id h11so12855944wiw.13 for ; Wed, 10 Dec 2014 15:19:56 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.109.3 with SMTP id ho3mr10339040wib.39.1418253596111; Wed, 10 Dec 2014 15:19:56 -0800 (PST) Received: by 10.217.191.202 with HTTP; Wed, 10 Dec 2014 15:19:56 -0800 (PST) In-Reply-To: <20141211001317.0f8760c8@rainpc> References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> <20141211001317.0f8760c8@rainpc> Date: Wed, 10 Dec 2014 18:19:56 -0500 Message-ID: From: Roman Shpount To: Lorenzo Miniero Content-Type: multipart/alternative; boundary=e89a8f3b9dafcc3c1c0509e4e596 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9OJEt2pUSzF1XEGi7iUAm9TgAcM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 patent licensing options (was: Re: confirming sense of the room: mti codec) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 23:20:01 -0000 --e89a8f3b9dafcc3c1c0509e4e596 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 10, 2014 at 6:13 PM, Lorenzo Miniero wrote: > On Wed, 10 Dec 2014 18:04:46 -0500 > Richard Barnes wrote: > > > +1 > > > > This conversation is out of scope for this mailing list. > > > > > And yet it does raise some flags, though. Had I blindly trusted the claims > that have been made on this ML (not out of scope at the time, apparently) > about what the infamous plugin allegedly provided, I could have ended up > offering services based on openH264 and hopefully try and make some money > out of it: only to find myself suitable in the process, and in perfectly > good faith. I don't think raising awareness on such a delicate issue that > matters to the discussion is so out of scope. > > You might as well discuss such things as what is the definition of RAND and if such things as IPR declarations are legally enforceable. Both are very tricky and very heavily depend on the the standard body. _____________ Roman Shpount --e89a8f3b9dafcc3c1c0509e4e596 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Dec 10, 2014 at 6:13 PM, Lorenzo Miniero <lorenzo@meetecho.com= > wrote:
On Wed, 10 Dec 2014= 18:04:46 -0500
Richard Barnes <rlb@ipv.sx> wrote:

> +1
>
> This conversation is out of scope for this mailing list.
>


And yet it does raise some flags, though. Had I blindly trusted the = claims that have been made on this ML (not out of scope at the time, appare= ntly) about what the infamous plugin allegedly provided, I could have ended= up offering services based on openH264 and hopefully try and make some mon= ey out of it: only to find myself suitable in the process, and in perfectly= good faith. I don't think raising awareness on such a delicate issue t= hat matters to the discussion is so out of scope.

=C2=A0
You might as well discuss such thing= s as what is the definition of RAND and if such things as IPR declarations = are legally enforceable. Both are very tricky and very heavily depend on th= e the standard body.
_____________=
Roman Shpount
=C2=A0
--e89a8f3b9dafcc3c1c0509e4e596-- From nobody Wed Dec 10 15:21:53 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D011A1B32 for ; Wed, 10 Dec 2014 15:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94NIQ7q1lJn8 for ; Wed, 10 Dec 2014 15:21:50 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 600801A0105 for ; Wed, 10 Dec 2014 15:21:50 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ex7so6886223wid.0 for ; Wed, 10 Dec 2014 15:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=SsCfd404y9ybpyG7e53OdYsf77ciULQhzw+qeRzMBuA=; b=iTCJHQxBOdbTdbSdu0uDQ+9yLnNR3U7AGbedDWax2syj4bdVBFbhZsZlIDCol2RY6n k5ri2AHDsKIsJyxljyPW0x2y9BH0uQcnL5nyW0K+6YCFPoPiCf0Ls5z3i+yu5/EJZs4G mzpTGThU3l5R/y6VCo/5EXjcUu+rYxV2nwqyE6zGq/jfWqjI1IPgQ7Zvtm3qEp0oeQ2P f1PHk7JsYKRWuj9BZybLTYeK3w2rnQ+8kmRe4h6SzScieAVjJia54SHeBXtFF5l0KPPD 0sgb4+34s5IbxkQ7CdeK1McuPcVheTN7Fp2OU0nTL6gXRZ7EiCCPNmHgcOXycPeDb3fX 8CWA== X-Received: by 10.180.218.39 with SMTP id pd7mr17422680wic.21.1418253709141; Wed, 10 Dec 2014 15:21:49 -0800 (PST) Received: from [192.168.0.194] ([95.61.111.78]) by mx.google.com with ESMTPSA id cz3sm7666615wjb.23.2014.12.10.15.21.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 15:21:48 -0800 (PST) Message-ID: <5488D58B.6040606@gmail.com> Date: Thu, 11 Dec 2014 00:21:47 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20141210012208.GK19538@hex.shelbyville.oz> <20141210200027.GM19538@hex.shelbyville.oz> <20141210230012.GN19538@hex.shelbyville.oz> In-Reply-To: <20141210230012.GN19538@hex.shelbyville.oz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nfyZGkEhnf6bY5Pf8j75MKvnglw Subject: Re: [rtcweb] WebRTC endpoint categories X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 23:21:52 -0000 On 11/12/2014 0:00, Ron wrote: > [Changing the subject of this thread as requested earlier] > > On Wed, Dec 10, 2014 at 01:50:50PM -0800, David Singer wrote: >> I don’t think we need to change definitions. In some specs, there is >> an explicit “if the device supports the audio media type, it must…†>> and I took it as implicit that that was the case for the codecs for a >> given media type here. Users would not expect a device that states it >> doesn’t do audio to interop on audio. But if a device claims to be a >> general-purpose device that supports audio and video in webRTC, I >> think we’d all like it if it actually interoperated, right? Isn’t that >> the main thrust of looking for MTI codecs? > I'm afraid I'm missing the crux of the distinction you see if you think > we're not just agreeing with each other now :) > > A device is a WebRTC endpoint (browser or not) if it implements the > mandatory requirements of the WebRTC protocol (which includes MTI > codecs). > > Anything which doesn't do that, but can otherwise do some subset of > WebRTC to operate with WebRTC endpoints, in some unspecified here way, > is in the WebRTC-compatible class of devices. Whatever we end up > calling those, if the definition remains the same, they can do anything > they please, however they please, which obviously video and audio is a > subset of. I don't see how we could sensibly say they must not do > either of those things at all, when the definition says they are not > constrained by, or defined in, or implementations of, this spec. > > There's no confusion about the expectations for interop though, because > they are "non-WebRTC" devices, so nothing at all can be expected except > what the device itself says it is actually capable of. They might > implement some melange of various standards or they might be an entirely > proprietary thing. The IETF isn't really concerned with marketing > appellations, these classes are just language to use in the spec itself > when we need to say something referring to these categories of things. > > A device which doesn't implement the WebRTC protocol, doesn't implement > the WebRTC protocol. It doesn't really matter what its reasons for that > might be, or what other things it does implement. Does it? > > If I implement a protocol that shares the same first 8 octets with an > IPv4 header, that doesn't mean I have implemented RFC 791. > > +1 It is quite difficult to not agree with anything that Ron says.. :) Also, I hear some people complaining about the definition of a WebRTC compatible endpoint, but it would be good if those people expose what are the changes that they want to introduce: -Remove webrtc compatible endpoints mentions from spec -Change definition of a webrtc compatible endpoint -Mandate webrtc compatible enpoints to implement both MTI video codecs Best regards Sergio From nobody Wed Dec 10 15:35:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E50B1AC42B for ; Wed, 10 Dec 2014 15:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kespX9yb9UBJ for ; Wed, 10 Dec 2014 15:35:07 -0800 (PST) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3AC1AC41A for ; Wed, 10 Dec 2014 15:35:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418254506; x=2282168106; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mzqWG9EkkWXSjJ9M5OYMcnO0ASlu10soMZUKT4p8p90=; b=Qju2GVEzhvk9BFEjqivvL5/Xjt6ALCPFIV8SeQDb3oS9VckjVY6w3bW9pMHiDIrD ne8klMiD4+7ijUbNCFsWghM5VCKnXAraHhJ5QfX2iqLGNoC7C7YeOPi22g4fwRno F8LsFva1/fFaHjn/uCutr4vznbpEId02eRJNu/lhVDx7DZLUK7q/g/DQorefd3QX lKdsxoswBymh+sioKllndO8H+PmJ4a20ovksuda2wB/IKSCWp+V26WUTJaX1157r dw3Oca2vxhJX0YcTsW7fMG4sO2pK6D2xKlXsgqhdy/hY/uoKUvRz4Y8aebMAfVEC BQxcfbrbeJs12N2myi7oGA==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 8F.4E.26546.AA8D8845; Wed, 10 Dec 2014 15:35:06 -0800 (PST) X-AuditID: 11973e11-f79af6d0000067b2-0c-5488d8aa0474 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id A4.37.06123.CA8D8845; Wed, 10 Dec 2014 15:35:08 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGE0020R46HX160@marigold.apple.com> for rtcweb@ietf.org; Wed, 10 Dec 2014 15:35:05 -0800 (PST) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: Date: Wed, 10 Dec 2014 15:35:05 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <20141210012208.GK19538@hex.shelbyville.oz> To: Andrew Allen X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FAYobvqRkeIwZJP8hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr486jySwFe5gqlt47x9rA+IOxi5GDQ0LARGJuk3wXIyeQKSZx 4d56ti5GLg4hgb2MEid/vmeCSJhIXLj2mAUiMYlJ4t7VU8wQznwmiUdTv7KBVDELaEms33kc rINXQE+i6cljJpANwgK2EluvB4GE2QRUJR7MOcYIYnMKeEq8m7UJrJwFKN5/aT4LxBh1iaWT G6BGaks8eXeBFWKkjcTqn6vAeoUEvjNLtCzxB7FFBDQkZnxsgDpUVuLfxTPsILdJCHxklTh/ 4h3jBEbhWUjOm4XkvFlIdixgZF7FKJSbmJmjm5lnpJdYUJCTqpecn7uJERTG0+0EdzAeX2V1 iFGAg1GJh3fF1fYQIdbEsuLK3EOM0hwsSuK8R3YDhQTSE0tSs1NTC1KL4otKc1KLDzEycXBK NTC6cK5dvfaeQ7hG3XP93ImT7rWsjXa4FiF47ftp45OvsqV054RvOhhZduXs9A0pJo3hzn8/ Lm3s9rmVc8u9JylpkyHP/h0d/128xG5yzD1VGTPTY4tqzIEA1ezkhxmlqdZdyRPecCdzZd59 ILL0ScekrTc3+Qb80j/UuOAW19HChD3VCfcTEkSUWIozEg21mIuKEwGAgwi1RAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcorvmRkeIweWD4hZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr486jySwFe5gqlt47x9rA+IOxi5GTQ0LAROLCtccsELaYxIV7 69m6GLk4hAQmMUncu3qKGcKZzyTxaOpXNpAqZgEtifU7jzOB2LwCehJNTx4D2RwcwgK2Eluv B4GE2QRUJR7MOQa2gFPAU+LdrE1g5SxA8f5L81kgxqhLLJ3cADVSW+LJuwusECNtJFb/XAXW KyTwnVmiZYk/iC0ioCEx42MDE8ShshL/Lp5hn8AoMAvJRbOQXDQLydgFjMyrGAWKUnMSK031 EgsKclL1kvNzNzGCA68wYgfj/2VWhxgFOBiVeHhXXG0PEWJNLCuuzD3EKMHBrCTC+2VbR4gQ b0piZVVqUX58UWlOavEhRmkOFiVx3pJ3jSFCAumJJanZqakFqUUwWSYOTqkGxpPHHsbvde2x 0t999OH9/TMfvOP8Wbi49ojS7FlRT/1+V537+GRd7LHEK3P3nWMPf8eiJt9hrDI586nzmlqF r/m/ww//d1HlWmb4+uikkD8LW77e2Gxr7c0xxUGu9xlbPOO6Ddv7sl+IvroUKtJ79tjlcuFj pw/IdCpceJa4ls++dWvo/lNrubmVWIozEg21mIuKEwFOHjbcOAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HT4-7og43dEdjPqVRKWJ57Piuww Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 23:35:08 -0000 > On Dec 10, 2014, at 15:15 , Andrew Allen = wrote: >=20 > It [non-video non-audio device] could be a telemetry device supporting = only the data channel so no audio or video (not such an odd duck I = think). ah yes, thanks David Singer Manager, Software Standards, Apple Inc. From nobody Wed Dec 10 15:43:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8221AC423 for ; Wed, 10 Dec 2014 15:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpdRAA1TON1T for ; Wed, 10 Dec 2014 15:43:41 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F6A31AC41A for ; Wed, 10 Dec 2014 15:43:41 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id va2so427337obc.8 for ; Wed, 10 Dec 2014 15:43:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TOtAjYtyJ2mKpNuGd+q34PRKrVgavPuP8TtEAG9RI6w=; b=wEg2rEOhxT0J14ijMvGxwQB3WLbvH2XnEN+Mvbf/f/4N0EDgB1keu4ifIorkvuIXjM UL412ckSlwRQ8QRXepnlofYjURm3lZxwjdIEiJ38DgKyRsz6spZoaVBj9BORdMMFTx/1 LYYyMIcIbskdll+QnpioIvoalwn/ez9VvmLsb8tYq70D6zfFdN+ZQGPsZ4NKLzai5YO2 YnTvrB8EzX+l4k8bboKt9hj7zW9r6IO9r6lj3u8G4YRHyBAaHA1rJknxXzN/oCNHuDYO ccfR+U8KoBjfKKu3vzMvg4Cz3Jmw2cRp4gkU4T7QhQMqTnYpNOc9k3OAi6GeNMNp43ei MACQ== MIME-Version: 1.0 X-Received: by 10.182.46.134 with SMTP id v6mr406978obm.34.1418255020679; Wed, 10 Dec 2014 15:43:40 -0800 (PST) Received: by 10.202.107.19 with HTTP; Wed, 10 Dec 2014 15:43:40 -0800 (PST) In-Reply-To: <5488D49D.5040307@gmail.com> References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> <5488D49D.5040307@gmail.com> Date: Wed, 10 Dec 2014 15:43:40 -0800 Message-ID: From: Martin Thomson To: Sergio Garcia Murillo Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WILv1oQlxz2MTHZhe75PdpBAOV8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 patent licensing options X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 23:43:43 -0000 On 10 December 2014 at 15:17, Sergio Garcia Murillo wrote: > The availability of OpenH264 was proposed here in this list as one argument > in favor of adopting H264, so IMHO, this should be explained. I recommend that you reach your own conclusions about whether to consider OpenH264 as having any bearing on the discussion. From nobody Wed Dec 10 15:46:04 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C981A1AC7 for ; Wed, 10 Dec 2014 15:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XZ3jig4JPYD for ; Wed, 10 Dec 2014 15:46:01 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFF3A1A0105 for ; Wed, 10 Dec 2014 15:46:00 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id l18so4919668wgh.26 for ; Wed, 10 Dec 2014 15:45:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=oSy/cgyoMqrAR9cO5B51JnHWnWKWMJbJri7L6Jt+668=; b=mOE/qA7pqvUqCsHSee7PDOaNd+PD5+htzisizq2kZtWStlAsIeorWxECIwcBWs3ncR awtJJNf6pt11CojgUJxmbbvbLGXMAEn0V1OlyhKBt94zWFsm/eoHGefVaQxOUwX9Dfvn 8GyLz59GM0VMC9dKKGnx5XWdrQndWf1dbnMCleZV6JBgiBRTMjoiwMg5JvrqGF6T2EHL CscsUHHKschPoQVG7E3nMPKjVXc3FauMaJaqAKLhnR7GSufmLTE+O9U5hPSFXPKKO/CZ mZLY83lc6PQYo8+uBfkcK9X9YT/q76xTvVDK9WCkFMIbqQz5XfV6j38pq9MdkcgfaKBb HIpg== X-Received: by 10.180.221.72 with SMTP id qc8mr10556108wic.19.1418255159721; Wed, 10 Dec 2014 15:45:59 -0800 (PST) Received: from [100.68.186.149] (140.82-130-174.dynamic.clientes.euskaltel.es. [82.130.174.140]) by mx.google.com with ESMTPSA id h8sm612668wiy.17.2014.12.10.15.45.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 15:45:58 -0800 (PST) References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> <5481672E.4080305@alvestrand.no> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-91E0D77C-CF43-413D-B3FD-013B21334AB6 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D201) From: Victor Pascual Date: Thu, 11 Dec 2014 00:45:50 +0100 To: Varun Singh Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cXA92uZT4zywMeiSKstiuyBRrGM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 23:46:03 -0000 --Apple-Mail-91E0D77C-CF43-413D-B3FD-013B21334AB6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1 > On Dec 6, 2014, at 6:02 PM, Varun Singh wrote: >=20 > A) Yes, I have read the draft and I support adopting it. >=20 > Varun. >=20 >> On 5 Dec 2014 10:05, "Harald Alvestrand" wrote: >> Just to get the ball rolling: >>=20 >> A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG docume= nt now. >>=20 >>> On 12/04/2014 08:29 PM, Cullen Jennings (fluffy) wrote: >>> Having reviewed the fine technical comments on this draft since we asked= for comments, the chairs have noted that multiple people seem to have read t= he draft. Given this great news we are going make a call for adoption. >>>=20 >>> If you have an opinion, please email the list by Dec 19 and let us know i= f you either: >>>=20 >>> A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG docum= ent now >>>=20 >>> B) no, not right now >>>=20 >>> If we get consensus around A we will work with ADs on milestone. Otherwi= se we will encourage the authors to keep working on this draft and continue u= sing this email list. We may adopt it later or include the text in other dra= fts. >>>=20 >>> Thanks, >>> The Chairs (Cullen, Sean, Ted) >>>=20 >>> PS - if you want to send an email that says more than A or B, feel free t= o change the subject, start a new thread etc. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >> _______________________________________________ >> 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 --Apple-Mail-91E0D77C-CF43-413D-B3FD-013B21334AB6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
+1

On Dec 6, 2014, at 6:02 PM, Varun Singh <vsingh.ietf@gmail.com> wrote:

A) Yes, I have read the draft and I support adopting it.

Varun.

On 5 Dec 2014 10:05, "Harald Alvestrand" <harald@alvestrand.no> wrote:
Just to get the ball rolling:

A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG document now.

On 12/04/2014 08:29 PM, Cullen Jennings (fluffy) wrote:
Having reviewed the fine technical comments on this draft since we asked for comments, the chairs have noted that multiple people seem to have read the draft. Given this great news we are going make a call for adoption.

If you have an opinion, please email the list by Dec 19 and let us know if you either:

A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG document now

B) no, not right now

If we get consensus around A we will work with ADs on milestone. Otherwise we will encourage the authors to keep working on this draft and continue using this email list. We may adopt it later or include the text in other drafts.

Thanks,
The Chairs (Cullen, Sean, Ted)

PS - if you want to send an email that says more than A or B, feel free to change the subject, start a new thread etc.








_______________________________________________
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
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--Apple-Mail-91E0D77C-CF43-413D-B3FD-013B21334AB6-- From nobody Wed Dec 10 23:24:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278331A0058 for ; Wed, 10 Dec 2014 23:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.34 X-Spam-Level: X-Spam-Status: No, score=0.34 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hB0ws4GGg5X3 for ; Wed, 10 Dec 2014 23:24:22 -0800 (PST) Received: from albireo.enyo.de (albireo.enyo.de [46.237.207.196]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C961A854A for ; Wed, 10 Dec 2014 23:24:21 -0800 (PST) Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) id 1Xyy6l-0000hS-Bf; Thu, 11 Dec 2014 08:24:19 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1Xyy6l-0002xC-2x; Thu, 11 Dec 2014 08:24:19 +0100 From: Florian Weimer To: Martin Thomson References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> Date: Thu, 11 Dec 2014 08:24:18 +0100 In-Reply-To: (Martin Thomson's message of "Wed, 10 Dec 2014 13:59:05 -0800") Message-ID: <87iohisl7h.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BWQqR7vep-tng-zkow609QVpcLA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 patent licensing options X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 07:24:24 -0000 * Martin Thomson: > On 10 December 2014 at 13:46, Florian Weimer wrote: >> This rules out commercial use. Doesn't this fail the =E2=80=9Creasonabl= e=E2=80=9D >> part of RAND because it is expected that commercial end users obtain a >> separate patent license of their own (which is not part of a product >> that can be purchased)? If this is still considered =E2=80=9Creasonable= =E2=80=9D, is >> the fact relevant that all published MPEG-LA material about H.264 >> refers to patent licensing in a broadcasting context (either the >> production side, or the receiver side)? This strongly suggests to me >> that they may lack the rights to license H.264 for use in video >> conferencing applications. > > I recommend that you consult counsel on these sorts of questions. > Seeking legal opinion on an internet mailing list might not produce > the best results. This is about IETF policy towards RAND licensing. It's a working group and IETF decision, not something that can be left to lawyers. From nobody Thu Dec 11 02:19:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2558D1ACDDE for ; Thu, 11 Dec 2014 02:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6abzREAHwci5 for ; Thu, 11 Dec 2014 02:19:14 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106371ACDD1 for ; Thu, 11 Dec 2014 02:19:14 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex7so14022608wid.15 for ; Thu, 11 Dec 2014 02:19:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cMq0sYH4nwXskRANdNs4o7ZKWs5DNNRSVebv4+DtTgw=; b=Aviahr5P3MSflyTDlelaqvO3WsfRWXbaZ2epg7Oz6h3iwzqELXsu0Mmx8SFc65riCQ S/Hpw2Z1qhqr5xZWi8pzo+wEE99Ua2KPV9VuWTLa3kfM5m97y0WRnx20HOlk6/wifoNn U03hgN7F4ClkQsM7hT3OiobtOM6+YN8SA/DtX06zjnzs/E6ojFacaCOK7C06khJNIB+V 78lgPHc4NbCpuHMock9rqxtVftEnuuzm2KgfYmlZst5WW8VrLeFTfy3+gJF6nfuol5UB oPljRdO+qaJUzWpx8leapT+05qYnCEXjCzcxcSZBoNTL7JNpHDzvVMl1nIE818p25gfV 6LaA== X-Gm-Message-State: ALoCoQlRygMaUsIK3TJNaRyFLZ6KTd5zqOld+typWvvt6VnkbByX48sToW2SEk+OP3uKo2tqYQwA X-Received: by 10.180.73.206 with SMTP id n14mr21549828wiv.60.1418293151600; Thu, 11 Dec 2014 02:19:11 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com. [209.85.212.171]) by mx.google.com with ESMTPSA id p1sm1080081wjy.22.2014.12.11.02.19.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Dec 2014 02:19:10 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bs8so14038197wib.4 for ; Thu, 11 Dec 2014 02:19:10 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.109.3 with SMTP id ho3mr14459808wib.39.1418293150151; Thu, 11 Dec 2014 02:19:10 -0800 (PST) Received: by 10.217.191.202 with HTTP; Thu, 11 Dec 2014 02:19:10 -0800 (PST) In-Reply-To: <87iohisl7h.fsf@mid.deneb.enyo.de> References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> <87iohisl7h.fsf@mid.deneb.enyo.de> Date: Thu, 11 Dec 2014 05:19:10 -0500 Message-ID: From: Roman Shpount To: Florian Weimer Content-Type: multipart/alternative; boundary=e89a8f3b9daf66ffd70509ee1b98 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/aeixYqYRystdtuIFTrCtSGJ8ZpE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 patent licensing options X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 10:19:16 -0000 --e89a8f3b9daf66ffd70509ee1b98 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 11, 2014 at 2:24 AM, Florian Weimer wrote: > > This is about IETF policy towards RAND licensing. It's a working > group and IETF decision, not something that can be left to lawyers. > When discussing RAND terms in general, I would suggest reading something like this http://www.cravath.com/files/Uploads/Documents/Publications/3233990_1.pdf and then talking to your legal counsel. Typically, as far as standards are concerned (this comes with a a huge IANAL disclaimer), obligation to license IPR under RAND terms implies only that some licensing terms will be offered for this IPR to anybody who is willing to implement the standard. What these terms are is up to the IPR holder. In a lot of cases, obligation to license under RAND terms is meaningless and the actual licensing policy by IPR holders must be considered. In case of H.264, as far as our company is concerned, this implies that we cannot license H.264 IPR. To work around this, we are planning to offer H.264 in client software on the platforms where H.264 is provided by the platform itself or via OpenH264. In both cases, we consider H.264 licensing will be something that will occur between the end user and the platform provider, or, in case of OpenH264, between the end user and Cisco. If end users decides to ignore the H.264 licensing terms, as they typically do, this is between the end user and whoever provided them with the H.264 license. We will not license H.264 ourselves or provide any H.264 licenses from us to our customers. In anything that we license directly to our customers or operate ourselves (which typically means professional conferencing services), we are planning to support VP8 only and will not claim WebRTC compliance. End points which implement H.264 only will not be fully supported by the services we operate and would only be provided with limited feature set that can be enabled based on peer-to-peer communications or relay without the need for transcoding or other H.264 related server functionality. This is why the currently offered compromise works for us even though H.264 licensing policy is less then ideal. _____________ Roman Shpount --e89a8f3b9daf66ffd70509ee1b98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 11, 2014 at 2:24 AM, Florian Weimer <fw@deneb.enyo.de> wrote:

This is about IETF policy towards RAND licensing.=C2=A0 It's a working<= br> group and IETF decision, not something that can be left to lawyers.

When discussing RAND terms in general, I would= suggest reading something like this http://www.cravath.com/file= s/Uploads/Documents/Publications/3233990_1.pdf and then talking to your= legal counsel.=C2=A0

Typically, as far as standar= ds are concerned (this comes with a a huge IANAL disclaimer), obligation to= license IPR under RAND terms implies only that some licensing terms will b= e offered for this IPR to anybody who is willing to implement the standard.= What these terms are is up to the IPR holder. In a lot of cases, obligatio= n to license under RAND terms is meaningless and the actual licensing polic= y by IPR holders must be considered.=C2=A0

In case= of H.264, as far as our company is concerned, this implies that we cannot = license H.264 IPR. To work around this, we are planning to offer H.264 in c= lient software on the platforms where H.264 is provided by the platform its= elf or via OpenH264. In both cases, we consider H.264 licensing will be som= ething that will occur between the end user and the platform provider, or, = in case of OpenH264, between the end user and Cisco. If end users decides t= o ignore the H.264 licensing terms, as they typically do, this is between t= he end user and whoever provided them with the H.264 license. We will not l= icense H.264 ourselves or provide any H.264 licenses from us to our custome= rs. In anything that we license directly to our customers or operate oursel= ves (which typically means professional conferencing services), we are plan= ning to support VP8 only and will not claim WebRTC compliance. End points w= hich implement H.264 only will not be fully supported by the services we op= erate and would only be provided with limited feature set that can be enabl= ed based on peer-to-peer communications or relay without the need for trans= coding or other=C2=A0H.264=C2=A0related server functionality. This is why t= he currently offered compromise works for us even though H.264 licensing po= licy is less then ideal.
_____________
Roman Shpount
=
--e89a8f3b9daf66ffd70509ee1b98-- From nobody Thu Dec 11 06:39:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EFA1ACEEE for ; Thu, 11 Dec 2014 06:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.811 X-Spam-Level: X-Spam-Status: No, score=-111.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlxdiSMDrkPK for ; Thu, 11 Dec 2014 06:39:18 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684B31ACEE3 for ; Thu, 11 Dec 2014 06:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3076; q=dns/txt; s=iport; t=1418308758; x=1419518358; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iEOPBYxAqwJ89vuaxW/FpXeLh3shY9/v8JHW4DDCJZA=; b=Sm5yqDOjt7UV6A/Mk598hSOZN2kF0s8e//DfRwj1F1ueu2zcBTA8iDWJ xQa1TXfM/CgyNoyfGxlnWC+eprDjRI08RRuN+luaKDDKAfx3Q8zOiIyNg SxBxKTzbPPJ9Clvw0XNMWljU05cDSi8VOVV7/LBoD+xCAGVkHPJeNtS5j Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4GAJ+riVStJA2D/2dsb2JhbABZgmQiUlgEgwHCc4VuAhyBABYBAQEBAX2EDAEBAQIBASMRRQULAgEIDgoCAiYCAgIwFRACBA4FiCQIAQzBH5ZiAQEBAQEBAQEBAQEBAQEBAQEBARmBIYhjhS8zB4JoLoETBY1/iG2BDIxwgzcigjCBPG4BgQIFPX4BAQE X-IronPort-AV: E=Sophos;i="5.07,558,1413244800"; d="scan'208";a="104797307" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP; 11 Dec 2014 14:39:17 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sBBEdH5k025157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Dec 2014 14:39:17 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 08:39:17 -0600 From: "Cullen Jennings (fluffy)" To: Florian Weimer Thread-Topic: [rtcweb] H.264 patent licensing options (was: Re: confirming sense of the room: mti codec) Thread-Index: AQHQFVA9CX0oaunmoU2SfagR3TvGgA== Date: Thu, 11 Dec 2014 14:39:15 +0000 Message-ID: <310BD70B-6302-4ACC-954A-DF5FFB420408@cisco.com> References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> In-Reply-To: <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="utf-8" Content-ID: <08D9469B9ABABF4F83AC3E914AA87038@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ABaZwQdFrYDFUM-ldAxTfenzkOg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 patent licensing options (was: Re: confirming sense of the room: mti codec) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 14:39:20 -0000 DQo+IE9uIERlYyAxMCwgMjAxNCwgYXQgMjo0NiBQTSwgRmxvcmlhbiBXZWltZXIgPGZ3QGRlbmVi LmVueW8uZGU+IHdyb3RlOg0KPiANCj4gKiBBbmRyZXcgQWxsZW46DQo+IA0KPj4gT3VyIHByZWZl cmVuY2UgaXMgZm9yIEguMjY0IHRvIGJlIHRoZSBzaW5nbGUgTVRJLiBXZSBiZWxpZXZlIHRoYXQN Cj4+IENpc2NvJ3Mgb3BlbiBzb3VyY2Ugcm95YWx0eSBmcmVlIGNvZGUgb2ZmZXIgZ29lcyBhIGxv bmcgbG9uZyB3YXkgdG8NCj4+IGFkZHJlc3MgdGhlIGNvbmNlcm5zIG9mIG1hbnkgcmVsYXRlZCB0 byBJUFIgb24gSC4yNjQNCj4gDQo+IENpc2NvIGlzIHJlcXVpcmVkIHRvIHNheSB0aGlzIGFib3V0 IHRoZSBwYXRlbnQgbGljZW5zZSB0aGV5IGFsbGVnZWRseQ0KPiBjb25mZXI6DQo+IA0KPiDigJxU SElTIFBST0RVQ1QgSVMgTElDRU5TRUQgVU5ERVIgVEhFIEFWQyBQQVRFTlQgUE9SVEZPTElPIExJ Q0VOU0UgRk9SDQo+IFRIRSBQRVJTT05BTCBVU0UgT0YgQSBDT05TVU1FUiBPUiBPVEhFUiBVU0VT IElOIFdISUNIIElUIERPRVMgTk9UDQo+IFJFQ0VJVkUgUkVNVU5FUkFUSU9OIFRPIChpKSBFTkNP REUgVklERU8gSU4gQ09NUExJQU5DRSBXSVRIIFRIRSBBVkMNCj4gU1RBTkRBUkQgKOKAnEFWQyBW SURFT+KAnSkgQU5EL09SIChpaSkgREVDT0RFIEFWQyBWSURFTyBUSEFUIFdBUyBFTkNPREVEDQo+ IEJZIEEgQ09OU1VNRVIgRU5HQUdFRCBJTiBBIFBFUlNPTkFMIEFDVElWSVRZIEFORC9PUiBXQVMg T0JUQUlORUQgRlJPTQ0KPiBBIFZJREVPIFBST1ZJREVSIExJQ0VOU0VEIFRPIFBST1ZJREUgQVZD IFZJREVPLiAgTk8gTElDRU5TRSBJUyBHUkFOVEVEDQo+IE9SIFNIQUxMIEJFIElNUExJRUQgRk9S IEFOWSBPVEhFUiBVU0UuICBBRERJVElPTkFMIElORk9STUFUSU9OIE1BWSBCRQ0KPiBPQlRBSU5F RCBGUk9NIE1QRUcgTEEsIEwuTC5DLiBTRUUgSFRUUDovL1dXVy5NUEVHTEEuQ09N4oCdDQo+IA0K PiBUaGlzIHJ1bGVzIG91dCBjb21tZXJjaWFsIHVzZS4gDQoNCkkgZG9uJ3QgdGhpbmsgdGhhdCBp cyB0aGUgY2FzZS4gVGhpcyBpcyByZWFsbHkgbm90IGluIHNjb3BlIGZvciB0aGlzIGxpc3QgYnV0 IEknbSBnb2luZyB0byBhbnN3ZXIgYW55d2F5cy4gVGhpcyB0ZXJtcyBwZXJzb25hbCBhbmQgY29u c3VtZXIgYXJlIGRlZmluZWQgaW4gYSB3YXkgdGhhdCBtaWdodCBzdXJwcmlzZSB5b3UgaW4gdGhl IE1QTEVHLUxBIGxpY2Vuc2UuIFRoaXMgY2FuIGJlIHVzZWQgZm9yIHdoYXQgbW9zdCBwZW9wbGUg Y29uc2lkZXIgY29tbWVyY2lhbCBpbiB0aGUgdXN1YWwgdXNlIG9mIHRoZSB3b3JkLiBUaGUgYmVz dCBkb2N1bWVudCB0byB1bmRlcnN0YW5kIHRoZXNlcyBpcyAgaHR0cDovL3d3dy5tcGVnbGEuY29t L21haW4vcHJvZ3JhbXMvYXZjL0RvY3VtZW50cy9BVkNfVGVybXNTdW1tYXJ5LnBkZiBhbmQgd29y ayB3aXRoIHlvdXIgbGVnYWwgdGVhbS4gDQoNClRoZSBsaWNlbnNlIENpc2NvIGlzIHByb3ZpZGlu ZyBmb3Igb3BlbmgyNjQgaXMgIHRoZSBzYW1lIE1QRUctTEEgbGljZW5zZSB0aGF0IGlzIHVzZWQg YnkgcHJvZHVjdHMgc3VjaCBhcyBDaXNjbyB2aWRlbyBwaG9uZXMsIHRlbGUgcHJldGVuc2VzIHN5 c3RlbXMsIHNvZnQgcGhvbmVzLCB3ZWJleCwgamFiYmVyIGVjdC4gTW9zdCBwZW9wbGUgdGhpbmsg b2YgdGhlIHByaWNlcyBvZiBvdXIgdmlkZW8gYW5kIHRlbGUgcHJlc2VuY2Ugc3lzdGVtcyBhcyBt b3N0IGRlZmluaXRlbHkgImNvbW1lcmNpYWwiIGFuZCBwZW9wbGUgcGF5IHRvIHVzZSB3ZWJleC4g WW91IGNhbiB1c2Ugb3BlbmgyNjQgZm9yIHRoaW5ncyBsaWtlIHRoYXQgd2l0aCB0aGUgbGljZW5z ZSBwcm92aWRlZC4gDQoNCkl0J3MgYWxzbyB3ZWxsIHdvcnRoIG5vdGluZyB0aGF0IGlmIHlvdSBz aGlwIGxlc3MgdGhhbiAxMDBrIHVuaXRzL3llYXIsIGl0IGZyZWUgYW5kIHlvdSBjYW4ganVzdCBj b21waWxlIGluIHlvdXIgZmF2b3JpdGUgMjY0IG9wZW4gc291cmNlIGNvZGUgICh0aGVyZSBhcmUg bXVsdGlwbGUgdG8gY2hvb3NlIGZyb20pIGFuZCBzaGlwIGl0LiANCg0KSSBkb24ndCB3YW50IHRv IHN0YXJ0IGEgdGhyZWFkIGFib3V0IGhvdyB0byB1bmRlcnN0YW5kIGEgY29tcGxleCBsZWdhbCBk b2N1bWVudCBmcm9tIE1QRUctTEEgYnV0IEkgZGlkIHdhbnQgdG8ganVzdCBwcm92aWRlIHBvaW50 ZXJzIHRvIHRoZSBhYm92ZSBpbmZvLiANCg0KQ3VsbGVuICh3aXRoIG15IGluZGl2aWR1YWwgY29u dHJpYnV0b3IgaGF0IG9uKQ0KDQoNCg== From nobody Thu Dec 11 07:15:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777E71ACDC8 for ; Thu, 11 Dec 2014 07:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fLeNghrXwjT for ; Thu, 11 Dec 2014 07:15:28 -0800 (PST) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33A21A1BE9 for ; Thu, 11 Dec 2014 07:15:27 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id h15so5014466igd.1 for ; Thu, 11 Dec 2014 07:15:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=OnTtrvOzZx9ZoY0a2152gi+vYxnEWROK4x711ssHu10=; b=Va9uKDr3kS20p0j35GLVgC5cxrJ5FrvHE9MYkXE144J87QFtNCqidD7csDNr+B+Chi m8QuKYysl2INrQ+aJgWPJlTh9wJYuSRMtHVahACbKcworqRtWeJrtdQJhTD66O+G+bqe 9QCoGMgnReniQnWQHB7h3y0fvZnU+a46jM9cJhUPX1InxwhTzl672dlK2lzR0dORsc/1 qYNVsnOAuRpkXbebdneXwolR/WkfoznTnSP/9GZg2u6wmZ8DiJtgpca/io2wsbBtYMQV a7B8PR5FhQpe4y7Tw/W5bHuoXnAtt+R/fzZbeZ21dk1UCUDKT/cZQR/5wJWgYK5x9M8O 9z3A== X-Gm-Message-State: ALoCoQmB/qRc/s0bHKOT+4uBMrwGs+1vvUtBXgp4FPGcWPLoLZsndHjAHqACcn3N+rOmXM7diiRP X-Received: by 10.50.4.102 with SMTP id j6mr31639936igj.37.1418310927228; Thu, 11 Dec 2014 07:15:27 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id jg3sm1316281igb.12.2014.12.11.07.15.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Dec 2014 07:15:26 -0800 (PST) Message-ID: <5489B4CE.7060108@bbs.darktech.org> Date: Thu, 11 Dec 2014 10:14:22 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> <310BD70B-6302-4ACC-954A-DF5FFB420408@cisco.com> In-Reply-To: <310BD70B-6302-4ACC-954A-DF5FFB420408@cisco.com> Content-Type: multipart/alternative; boundary="------------070902060809000803070203" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9ZR2r1EFP3LzWA3z_o-EDbV8J0k Subject: Re: [rtcweb] H.264 patent licensing options X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 15:15:30 -0000 This is a multi-part message in MIME format. --------------070902060809000803070203 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/12/2014 9:39 AM, Cullen Jennings (fluffy) wrote: >> On Dec 10, 2014, at 2:46 PM, Florian Weimer wrote: >> >> * Andrew Allen: >> >>> Our preference is for H.264 to be the single MTI. We believe that >>> Cisco's open source royalty free code offer goes a long long way to >>> address the concerns of many related to IPR on H.264 >> Cisco is required to say this about the patent license they allegedly >> confer: >> >> “THIS PRODUCT IS LICENSED UNDER THE AVC PATENT PORTFOLIO LICENSE FOR >> THE PERSONAL USE OF A CONSUMER OR OTHER USES IN WHICH IT DOES NOT >> RECEIVE REMUNERATION TO (i) ENCODE VIDEO IN COMPLIANCE WITH THE AVC >> STANDARD (“AVC VIDEOâ€) AND/OR (ii) DECODE AVC VIDEO THAT WAS ENCODED >> BY A CONSUMER ENGAGED IN A PERSONAL ACTIVITY AND/OR WAS OBTAINED FROM >> A VIDEO PROVIDER LICENSED TO PROVIDE AVC VIDEO. NO LICENSE IS GRANTED >> OR SHALL BE IMPLIED FOR ANY OTHER USE. ADDITIONAL INFORMATION MAY BE >> OBTAINED FROM MPEG LA, L.L.C. SEE HTTP://WWW.MPEGLA.COM†>> >> This rules out commercial use. > I don't think that is the case. This is really not in scope for this list but I'm going to answer anyways. This terms personal and consumer are defined in a way that might surprise you in the MPLEG-LA license. This can be used for what most people consider commercial in the usual use of the word. The best document to understand theses is http://www.mpegla.com/main/programs/avc/Documents/AVC_TermsSummary.pdf and work with your legal team. > > The license Cisco is providing for openh264 is the same MPEG-LA license that is used by products such as Cisco video phones, tele pretenses systems, soft phones, webex, jabber ect. Most people think of the prices of our video and tele presence systems as most definitely "commercial" and people pay to use webex. You can use openh264 for things like that with the license provided. > > It's also well worth noting that if you ship less than 100k units/year, it free and you can just compile in your favorite 264 open source code (there are multiple to choose from) and ship it. > > I don't want to start a thread about how to understand a complex legal document from MPEG-LA but I did want to just provide pointers to the above info. > > Cullen (with my individual contributor hat on) This just reinforces the point made by others which is when it comes to H264 this isn't so much a royalty problem (hence "free" is nice but not all that meaningful) but rather a problem where you have no way of using English or common sense in evaluating whether you are breaking the law or not. On the one hand, we have H264 proponents claiming OpenH264 solves all our woes. On the other hand, we have a legally-binding statement that pretty clearly states the opposite. Now you would have us believe that: 1. This is out of scope for this mailing list (which I disagree with as it has a profound impact on our members) 2. "You have nothing to worry about. But you can't take our word for it. Go pay a lawyer >$10,000 to find out for sure" Honestly. MPEG-LA is shooting itself in the foot by making these licensing terms so complex. Even if I wanted to give them my money the sheer complexity of the matter prevents me from touching their codec with a 10 feet pole. Gili --------------070902060809000803070203 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/12/2014 9:39 AM, Cullen Jennings (fluffy) wrote: 
On Dec 10, 2014, at 2:46 PM, Florian Weimer <fw@deneb.enyo.de> wrote:

* Andrew Allen:


Our preference is for H.264 to be the single MTI. We believe that
Cisco's open source royalty free code offer goes a long long way to
address the concerns of many related to IPR on H.264

Cisco is required to say this about the patent license they allegedly
confer:

“THIS PRODUCT IS LICENSED UNDER THE AVC PATENT PORTFOLIO LICENSE FOR
THE PERSONAL USE OF A CONSUMER OR OTHER USES IN WHICH IT DOES NOT
RECEIVE REMUNERATION TO (i) ENCODE VIDEO IN COMPLIANCE WITH THE AVC
STANDARD (“AVC VIDEOâ€) AND/OR (ii) DECODE AVC VIDEO THAT WAS ENCODED
BY A CONSUMER ENGAGED IN A PERSONAL ACTIVITY AND/OR WAS OBTAINED FROM
A VIDEO PROVIDER LICENSED TO PROVIDE AVC VIDEO.  NO LICENSE IS GRANTED
OR SHALL BE IMPLIED FOR ANY OTHER USE.  ADDITIONAL INFORMATION MAY BE
OBTAINED FROM MPEG LA, L.L.C. SEE HTTP://WWW.MPEGLA.COMâ€

This rules out commercial use. 

I don't think that is the case. This is really not in scope for this list but I'm going to answer anyways. This terms personal and consumer are defined in a way that might surprise you in the MPLEG-LA license. This can be used for what most people consider commercial in the usual use of the word. The best document to understand theses is  http://www.mpegla.com/main/programs/avc/Documents/AVC_TermsSummary.pdf and work with your legal team. 

The license Cisco is providing for openh264 is  the same MPEG-LA license that is used by products such as Cisco video phones, tele pretenses systems, soft phones, webex, jabber ect. Most people think of the prices of our video and tele presence systems as most definitely "commercial" and people pay to use webex. You can use openh264 for things like that with the license provided. 

It's also well worth noting that if you ship less than 100k units/year, it free and you can just compile in your favorite 264 open source code  (there are multiple to choose from) and ship it. 

I don't want to start a thread about how to understand a complex legal document from MPEG-LA but I did want to just provide pointers to the above info. 

Cullen (with my individual contributor hat on)

This just reinforces the point made by others which is when it comes to H264 this isn't so much a royalty problem (hence "free" is nice but not all that meaningful) but rather a problem where you have no way of using English or common sense in evaluating whether you are breaking the law or not. On the one hand, we have H264 proponents claiming OpenH264 solves all our woes. On the other hand, we have a legally-binding statement that pretty clearly states the opposite. Now you would have us believe that:
  1. This is out of scope for this mailing list (which I disagree with as it has a profound impact on our members)
  2. "You have nothing to worry about. But you can't take our word for it. Go pay a lawyer >$10,000 to find out for sure"
Honestly. MPEG-LA is shooting itself in the foot by making these licensing terms so complex. Even if I wanted to give them my money the sheer complexity of the matter prevents me from touching their codec with a 10 feet pole.

Gili
--------------070902060809000803070203-- From nobody Thu Dec 11 07:46:37 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CBA1A9009 for ; Thu, 11 Dec 2014 07:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id milKBCu6KRqM for ; Thu, 11 Dec 2014 07:46:33 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002-out2.apm-internet.net [85.119.248.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DAC91A8707 for ; Thu, 11 Dec 2014 07:46:32 -0800 (PST) Received: (qmail 33329 invoked from network); 11 Dec 2014 15:46:30 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 10695 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 11 Dec 2014 15:46:30 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id CC7C918A1A3D; Thu, 11 Dec 2014 15:46:24 +0000 (GMT) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id B770218A19EE; Thu, 11 Dec 2014 15:46:24 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F083238C-17D4-4912-A90A-5CD459448CEE" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Tim Panton In-Reply-To: <310BD70B-6302-4ACC-954A-DF5FFB420408@cisco.com> Date: Thu, 11 Dec 2014 15:46:24 +0000 Message-Id: <269EA234-9EE5-4997-8BDD-483AFC4FB8D4@phonefromhere.com> References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> <310BD70B-6302-4ACC-954A-DF5FFB420408@cisco.com> To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4YB5KYEzmEDwbk5i3-UZ70X2jDQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 patent licensing options (was: Re: confirming sense of the room: mti codec) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 15:46:35 -0000 --Apple-Mail=_F083238C-17D4-4912-A90A-5CD459448CEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 11 Dec 2014, at 14:39, Cullen Jennings (fluffy) > wrote: >=20 > tele pretenses systems Do you do one that can join conference calls pretending to be me? :-) T. Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk --Apple-Mail=_F083238C-17D4-4912-A90A-5CD459448CEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 11 Dec 2014, at 14:39, Cullen Jennings = (fluffy) <fluffy@cisco.com> wrote:

 tele pretenses = systems

Do = you do one that can join conference calls pretending to be me?

:-)

T.


Tim Panton - = Web/VoIP consultant and implementor
www.westhawk.co.uk



= --Apple-Mail=_F083238C-17D4-4912-A90A-5CD459448CEE-- From nobody Thu Dec 11 08:42:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC371A1F04 for ; Thu, 11 Dec 2014 08:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLNsqiDUDWkZ for ; Thu, 11 Dec 2014 08:42:22 -0800 (PST) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44AD1A1BBF for ; Thu, 11 Dec 2014 08:42:21 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id le20so2705918vcb.12 for ; Thu, 11 Dec 2014 08:42:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4XHsdNRP567/IWbYDu/A2Om1Bgv6pxA1KR4SNDsl5NI=; b=bIkrxU+RPqRucVfO4V8ouPz11yr/31LH+zPr+ZEXfdVeBmXwA3kDTNIp0vPSQ8zQcv GJs+Twc3vKdRIqZgnCJZ9uqB7/lvCFaY6NOLljS1BnSBEmbn4gEn34qkwfIn80UgD7sU vVKpfW8eBzBzML0EoA7kHr+iZtt0P7gRckdgMS0wTL82OrLd9+G0N3i6uyiSXX1BmMTm UCQNVENQEi0y/i6REMPpFvsQMV36NOUXlOD2yHBVfGzzZHZ9f+bMrA6So9reXYWAuGP6 Qtkw6pIxzK+457U2suenG+ZJtJ8R75/PIqOu5/2koKPsg0cSkTKT9F41PgdtqPSpHTzH VK+w== X-Gm-Message-State: ALoCoQlHWc/FLBpjKoFkZnSa2njgghwHvcH48+gWwcxXEADc41chwXQ5r5qEneS8FLt4vaTMj1TO MIME-Version: 1.0 X-Received: by 10.220.118.194 with SMTP id w2mr7628936vcq.24.1418316141160; Thu, 11 Dec 2014 08:42:21 -0800 (PST) Received: by 10.31.139.9 with HTTP; Thu, 11 Dec 2014 08:42:21 -0800 (PST) In-Reply-To: <5489B4CE.7060108@bbs.darktech.org> References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> <310BD70B-6302-4ACC-954A-DF5FFB420408@cisco.com> <5489B4CE.7060108@bbs.darktech.org> Date: Thu, 11 Dec 2014 11:42:21 -0500 Message-ID: From: Richard Barnes To: cowwoc Content-Type: multipart/alternative; boundary=001a1132f4bac5f7260509f37545 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9h9bkQ6AKgxfBOFgQTSQoc6kgS8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 patent licensing options X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 16:42:24 -0000 --001a1132f4bac5f7260509f37545 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would like to re-emphasize that discussions of license terms are out of scope for this list. This thread is closed. On Thu, Dec 11, 2014 at 10:14 AM, cowwoc wrote: > On 11/12/2014 9:39 AM, Cullen Jennings (fluffy) wrote: > > On Dec 10, 2014, at 2:46 PM, Florian Weimer wrote: > > * Andrew Allen: > > > Our preference is for H.264 to be the single MTI. We believe that > Cisco's open source royalty free code offer goes a long long way to > address the concerns of many related to IPR on H.264 > > Cisco is required to say this about the patent license they allegedly > confer: > > =E2=80=9CTHIS PRODUCT IS LICENSED UNDER THE AVC PATENT PORTFOLIO LICENSE = FOR > THE PERSONAL USE OF A CONSUMER OR OTHER USES IN WHICH IT DOES NOT > RECEIVE REMUNERATION TO (i) ENCODE VIDEO IN COMPLIANCE WITH THE AVC > STANDARD (=E2=80=9CAVC VIDEO=E2=80=9D) AND/OR (ii) DECODE AVC VIDEO THAT = WAS ENCODED > BY A CONSUMER ENGAGED IN A PERSONAL ACTIVITY AND/OR WAS OBTAINED FROM > A VIDEO PROVIDER LICENSED TO PROVIDE AVC VIDEO. NO LICENSE IS GRANTED > OR SHALL BE IMPLIED FOR ANY OTHER USE. ADDITIONAL INFORMATION MAY BE > OBTAINED FROM MPEG LA, L.L.C. SEE HTTP://WWW.MPEGLA.COM=E2=80=9D > > This rules out commercial use. > > I don't think that is the case. This is really not in scope for this lis= t but I'm going to answer anyways. This terms personal and consumer are def= ined in a way that might surprise you in the MPLEG-LA license. This can be = used for what most people consider commercial in the usual use of the word.= The best document to understand theses is http://www.mpegla.com/main/prog= rams/avc/Documents/AVC_TermsSummary.pdf and work with your legal team. > > The license Cisco is providing for openh264 is the same MPEG-LA license = that is used by products such as Cisco video phones, tele pretenses systems= , soft phones, webex, jabber ect. Most people think of the prices of our vi= deo and tele presence systems as most definitely "commercial" and people pa= y to use webex. You can use openh264 for things like that with the license = provided. > > It's also well worth noting that if you ship less than 100k units/year, i= t free and you can just compile in your favorite 264 open source code (the= re are multiple to choose from) and ship it. > > I don't want to start a thread about how to understand a complex legal do= cument from MPEG-LA but I did want to just provide pointers to the above in= fo. > > Cullen (with my individual contributor hat on) > > > This just reinforces the point made by others which is when it comes to > H264 this isn't so much a royalty problem (hence "free" is nice but not a= ll > that meaningful) but rather a problem where you have no way of using > English or common sense in evaluating whether you are breaking the law or > not. On the one hand, we have H264 proponents claiming OpenH264 solves al= l > our woes. On the other hand, we have a legally-binding statement that > pretty clearly states the opposite. Now you would have us believe that: > > 1. This is out of scope for this mailing list (which I disagree with > as it has a profound impact on our members) > 2. "You have nothing to worry about. But you can't take our word for > it. Go pay a lawyer >$10,000 to find out for sure" > > Honestly. MPEG-LA is shooting itself in the foot by making these licensin= g > terms so complex. Even if I wanted to give them my money the sheer > complexity of the matter prevents me from touching their codec with a 10 > feet pole. > > Gili > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1132f4bac5f7260509f37545 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would like to re-emphasize that discussions of license t= erms are out of scope for this list.=C2=A0 This thread is closed.

On Thu, Dec 11, 2014 = at 10:14 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
=20 =20 =20
On 11/12/2014 9:39 AM, Cullen Jennings (fluffy) wrote: 
On Dec 10, 2014, at 2:46 PM, Florian Weimer <fw@deneb.enyo.de> wrote:

* Andrew Allen:


Our preference is for H.264 to be the single MTI. We believe=
 that
Cisco's open source royalty free code offer goes a long long way to
address the concerns of many related to IPR on H.264

Cisco is required to say this about the patent license they al=
legedly
confer:

=E2=80=9CTHIS PRODUCT IS LICENSED UNDER THE AVC PATENT PORTFOLIO LICENSE FO=
R
THE PERSONAL USE OF A CONSUMER OR OTHER USES IN WHICH IT DOES NOT
RECEIVE REMUNERATION TO (i) ENCODE VIDEO IN COMPLIANCE WITH THE AVC
STANDARD (=E2=80=9CAVC VIDEO=E2=80=9D) AND/OR (ii) DECODE AVC VIDEO THAT WA=
S ENCODED
BY A CONSUMER ENGAGED IN A PERSONAL ACTIVITY AND/OR WAS OBTAINED FROM
A VIDEO PROVIDER LICENSED TO PROVIDE AVC VIDEO.  NO LICENSE IS GRANTED
OR SHALL BE IMPLIED FOR ANY OTHER USE.  ADDITIONAL INFORMATION MAY BE
OBTAINED FROM MPEG LA, L.L.C. SEE HTTP://WWW.MPEGLA.COM=E2=80=9D

This rules out commercial use.=20

I don't think that is the case. This is really not in scope =
for this list but I'm going to answer anyways. This terms personal and =
consumer are defined in a way that might surprise you in the MPLEG-LA licen=
se. This can be used for what most people consider commercial in the usual =
use of the word. The best document to understand theses is  http://www.mpegla.com/main/programs/avc/Documents/AVC_TermsSumm=
ary.pdf and work with your legal team.=20

The license Cisco is providing for openh264 is  the same MPEG-LA license th=
at is used by products such as Cisco video phones, tele pretenses systems, =
soft phones, webex, jabber ect. Most people think of the prices of our vide=
o and tele presence systems as most definitely "commercial" and p=
eople pay to use webex. You can use openh264 for things like that with the =
license provided.=20

It's also well worth noting that if you ship less than 100k units/year,=
 it free and you can just compile in your favorite 264 open source code  (t=
here are multiple to choose from) and ship it.=20

I don't want to start a thread about how to understand a complex legal =
document from MPEG-LA but I did want to just provide pointers to the above =
info.=20

Cullen (with my individual contributor hat on)

This just reinforces the point made by others which is when it comes to H264 this isn't so much a royalty problem (hence "free"= ; is nice but not all that meaningful) but rather a problem where you have no way of using English or common sense in evaluating whether you are breaking the law or not. On the one hand, we have H264 proponents claiming OpenH264 solves all our woes. On the other hand, we have a legally-binding statement that pretty clearly states the opposite. Now you would have us believe that:
  1. This is out of scope for this mailing list (which I disagree with as it has a profound impact on our members)
  2. "You have nothing to worry about. But you can't take our= word for it. Go pay a lawyer >$10,000 to find out for sure"
Honestly. MPEG-LA is shooting itself in the foot by making these licensing terms so complex. Even if I wanted to give them my money the sheer complexity of the matter prevents me from touching their codec with a 10 feet pole.

Gili

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--001a1132f4bac5f7260509f37545-- From nobody Thu Dec 11 10:32:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4181A8835 for ; Thu, 11 Dec 2014 10:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrMXagKE7tqK for ; Thu, 11 Dec 2014 10:32:50 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C93571A87EA for ; Thu, 11 Dec 2014 10:32:50 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 679CAC94BD; Thu, 11 Dec 2014 13:32:48 -0500 (EST) Date: Thu, 11 Dec 2014 13:32:48 -0500 From: John Leslie To: Roman Shpount Message-ID: <20141211183248.GE47023@verdi> References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> <87iohisl7h.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/V-T6SdtRMZQJ-A4rRfLd0VqXkVQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 patent licensing options X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 18:32:54 -0000 Roman Shpount wrote: >... > In case of H.264, as far as our company is concerned, this implies that we > cannot license H.264 IPR. To work around this, we are planning to offer > H.264 in client software on the platforms where H.264 is provided by the > platform itself or via OpenH264. In both cases, we consider H.264 licensing > will be something that will occur between the end user and the platform > provider, or, in case of OpenH264, between the end user and Cisco. If end > users decides to ignore the H.264 licensing terms, as they typically do, > this is between the end user and whoever provided them with the H.264 > license. We will not license H.264 ourselves or provide any H.264 licenses > from us to our customers. In anything that we license directly to our > customers or operate ourselves (which typically means professional > conferencing services), we are planning to support VP8 only and will not > claim WebRTC compliance. End points which implement H.264 only will not be > fully supported by the services we operate and would only be provided with > limited feature set that can be enabled based on peer-to-peer > communications or relay without the need for transcoding or > other H.264 related server functionality. This is why the currently offered > compromise works for us even though H.264 licensing policy is less then > ideal. > _____________ > Roman Shpount This explanation is definitely helpful. Thank you! -- John Leslie From nobody Thu Dec 11 10:37:56 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD8D1A87B1 for ; Thu, 11 Dec 2014 10:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEX8j_FGlSQQ for ; Thu, 11 Dec 2014 10:37:51 -0800 (PST) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA241A6FC0 for ; Thu, 11 Dec 2014 10:37:51 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id ij19so2720062vcb.8 for ; Thu, 11 Dec 2014 10:37:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FiBhOs2XjbbyLZ2P5qhxuQvfgUxDftRuLjAVQq64+kU=; b=jZ721J7xKQGXjktj+6Xmqcfs5ZCvOfyGolGAbgLB5LlEZ4ruFnOh/vuhV75vJhpQvU +Ibd1O/1DmNw4olR4qiN7/s1eJXNWcXtFbPg1VMR8XRF+uenIzTYFaDA+ABg9ldpTCwU BTYeeLOQPQpfkUgS+bjsY2qFm5jItGTLcilvgn5Dtp+zxRF+OzGPcEk8GgcUKXhLVKRa dinOn5fxSnKX9EhpLdhgF+RZ4h/fdkBRh23hDzDUZYZmZD8I31jxjjosEY8cj1XU1WLU QZCAxD7aPMTPWlVQEr4uzaueoVWXAa2EF5bx4LGTKgWqa1wztCZj2JhJIHi5KBrgZDGJ j95g== X-Gm-Message-State: ALoCoQnZp9uBP3rOgG7dyxwCODTinseiKzZpq+exczRuKrFik0jl/AkCtn4iR+LVc1HnUeXO0rwG MIME-Version: 1.0 X-Received: by 10.220.3.71 with SMTP id 7mr8184045vcm.56.1418323070836; Thu, 11 Dec 2014 10:37:50 -0800 (PST) Received: by 10.31.139.9 with HTTP; Thu, 11 Dec 2014 10:37:50 -0800 (PST) In-Reply-To: <20141211183248.GE47023@verdi> References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> <87iohisl7h.fsf@mid.deneb.enyo.de> <20141211183248.GE47023@verdi> Date: Thu, 11 Dec 2014 13:37:50 -0500 Message-ID: From: Richard Barnes To: John Leslie Content-Type: multipart/alternative; boundary=001a11c3cb1ad076830509f512ab Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/x8unjXibdztLloedHl3UxruH6dA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 patent licensing options X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 18:37:53 -0000 --001a11c3cb1ad076830509f512ab Content-Type: text/plain; charset=UTF-8 Let me re-iterate: This thread is closed. On Thu, Dec 11, 2014 at 1:32 PM, John Leslie wrote: > Roman Shpount wrote: > >... > > In case of H.264, as far as our company is concerned, this implies that > we > > cannot license H.264 IPR. To work around this, we are planning to offer > > H.264 in client software on the platforms where H.264 is provided by the > > platform itself or via OpenH264. In both cases, we consider H.264 > licensing > > will be something that will occur between the end user and the platform > > provider, or, in case of OpenH264, between the end user and Cisco. If end > > users decides to ignore the H.264 licensing terms, as they typically do, > > this is between the end user and whoever provided them with the H.264 > > license. We will not license H.264 ourselves or provide any H.264 > licenses > > from us to our customers. In anything that we license directly to our > > customers or operate ourselves (which typically means professional > > conferencing services), we are planning to support VP8 only and will not > > claim WebRTC compliance. End points which implement H.264 only will not > be > > fully supported by the services we operate and would only be provided > with > > limited feature set that can be enabled based on peer-to-peer > > communications or relay without the need for transcoding or > > other H.264 related server functionality. This is why the currently > offered > > compromise works for us even though H.264 licensing policy is less then > > ideal. > > _____________ > > Roman Shpount > > This explanation is definitely helpful. Thank you! > > -- > John Leslie > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c3cb1ad076830509f512ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let me re-iterate: This thread is closed.

On Thu, Dec 11, 2014 at 1:3= 2 PM, John Leslie <john@jlc.net> wrote:
Roman Shpount <roman@telur= ix.com> wrote:
>...
> In case of H.264, as far as our company is concerned,= this implies that we
> cannot license H.264 IPR. To work around this, we are planning to offe= r
> H.264 in client software on the platforms where H.264 is provided by t= he
> platform itself or via OpenH264. In both cases, we consider H.264 lice= nsing
> will be something that will occur between the end user and the platfor= m
> provider, or, in case of OpenH264, between the end user and Cisco. If = end
> users decides to ignore the H.264 licensing terms, as they typically d= o,
> this is between the end user and whoever provided them with the H.264<= br> > license. We will not license H.264 ourselves or provide any H.264 lice= nses
> from us to our customers. In anything that we license directly to our<= br> > customers or operate ourselves (which typically means professional
> conferencing services), we are planning to support VP8 only and will n= ot
> claim WebRTC compliance. End points which implement H.264 only will no= t be
> fully supported by the services we operate and would only be provided = with
> limited feature set that can be enabled based on peer-to-peer
> communications or relay without the need for transcoding or
> other H.264 related server functionality. This is why the currently of= fered
> compromise works for us even though H.264 licensing policy is less the= n
> ideal.
> _____________
> Roman Shpount

=C2=A0 =C2=A0This explanation is definitely helpful. Thank you!

--
John Leslie <john@jlc.net>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--001a11c3cb1ad076830509f512ab-- From nobody Thu Dec 11 10:53:43 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0611A8775 for ; Thu, 11 Dec 2014 10:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgcw2s6vYPFd for ; Thu, 11 Dec 2014 10:53:39 -0800 (PST) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3231A888A for ; Thu, 11 Dec 2014 10:53:39 -0800 (PST) Received: by mail-vc0-f169.google.com with SMTP id hy10so2868392vcb.14 for ; Thu, 11 Dec 2014 10:53:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tYg6LMPqVjcZ20b0mWMnzBzktLlpbWI2Vy6oOc9Q8Js=; b=ic7GuzWGeqFPF4K1h/lA6giqCJVXpUov+42qithC83N39aLytO+eL3UxvrnV6EsJMU A6JSOtO4UXUrf+UAG/ghWsPAj10RbpdvvkWSpYCYElt8MfmmJSlPe4k8r1L0oGfS9M/J J0MJm6/jWcAng8SfxOhvnTbgvPk/Wf+uArq3AUs9FxfIqesLM64yCwXm8Op/PABjDnBk RSZxH0isOJwW+TKluVqeiDnuO20weSeMRjSkpDNQLddrWd6tE8UCFIrmTXIZDktNwIcM w2Dr38gebKbDSlJa+ZrI1vRrQmfFWbImVa8MYbctYgVqBU0BD54wvPrhBMYVHgoTTNz0 fKtg== X-Gm-Message-State: ALoCoQm/2uC/iIVGrg8uff6kOurL9mV9Hmnd5pff+fdPHTNpwfahENfN5SXDgyj9e3TlwEaD1+2e MIME-Version: 1.0 X-Received: by 10.220.178.3 with SMTP id bk3mr466843vcb.16.1418324017970; Thu, 11 Dec 2014 10:53:37 -0800 (PST) Received: by 10.31.139.9 with HTTP; Thu, 11 Dec 2014 10:53:37 -0800 (PST) In-Reply-To: References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> <87iohisl7h.fsf@mid.deneb.enyo.de> <20141211183248.GE47023@verdi> Date: Thu, 11 Dec 2014 13:53:37 -0500 Message-ID: From: Richard Barnes To: John Leslie Content-Type: multipart/alternative; boundary=001a11c1d37044958f0509f54b12 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/g73SMmTAqQkV_3uWFbrflxB_2oQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] H.264 patent licensing options X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 18:53:42 -0000 --001a11c1d37044958f0509f54b12 Content-Type: text/plain; charset=UTF-8 Just to clarify: The above messages closing the thread were with my RAI AD hat on, so as a matter of IETF process. On Thu, Dec 11, 2014 at 1:37 PM, Richard Barnes wrote: > Let me re-iterate: This thread is closed. > > On Thu, Dec 11, 2014 at 1:32 PM, John Leslie wrote: > >> Roman Shpount wrote: >> >... >> > In case of H.264, as far as our company is concerned, this implies that >> we >> > cannot license H.264 IPR. To work around this, we are planning to offer >> > H.264 in client software on the platforms where H.264 is provided by the >> > platform itself or via OpenH264. In both cases, we consider H.264 >> licensing >> > will be something that will occur between the end user and the platform >> > provider, or, in case of OpenH264, between the end user and Cisco. If >> end >> > users decides to ignore the H.264 licensing terms, as they typically do, >> > this is between the end user and whoever provided them with the H.264 >> > license. We will not license H.264 ourselves or provide any H.264 >> licenses >> > from us to our customers. In anything that we license directly to our >> > customers or operate ourselves (which typically means professional >> > conferencing services), we are planning to support VP8 only and will not >> > claim WebRTC compliance. End points which implement H.264 only will not >> be >> > fully supported by the services we operate and would only be provided >> with >> > limited feature set that can be enabled based on peer-to-peer >> > communications or relay without the need for transcoding or >> > other H.264 related server functionality. This is why the currently >> offered >> > compromise works for us even though H.264 licensing policy is less then >> > ideal. >> > _____________ >> > Roman Shpount >> >> This explanation is definitely helpful. Thank you! >> >> -- >> John Leslie >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > --001a11c1d37044958f0509f54b12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just to clarify: The above messages closing the thread wer= e with my RAI AD hat on, so as a matter of IETF process.

On Thu, Dec 11, 2014 at 1:37 P= M, Richard Barnes <rlb@ipv.sx> wrote:
Let me re-iterate: This thread is closed.

On Thu= , Dec 11, 2014 at 1:32 PM, John Leslie <john@jlc.net> wrote:
<= /span>
Roman Shpount &= lt;roman@telurix.com= > wrote:
>...
> In case of H.264, as far as our company is concerned, this impli= es that we
> cannot license H.264 IPR. To work around this, we are planning to offe= r
> H.264 in client software on the platforms where H.264 is provided by t= he
> platform itself or via OpenH264. In both cases, we consider H.264 lice= nsing
> will be something that will occur between the end user and the platfor= m
> provider, or, in case of OpenH264, between the end user and Cisco. If = end
> users decides to ignore the H.264 licensing terms, as they typically d= o,
> this is between the end user and whoever provided them with the H.264<= br> > license. We will not license H.264 ourselves or provide any H.264 lice= nses
> from us to our customers. In anything that we license directly to our<= br> > customers or operate ourselves (which typically means professional
> conferencing services), we are planning to support VP8 only and will n= ot
> claim WebRTC compliance. End points which implement H.264 only will no= t be
> fully supported by the services we operate and would only be provided = with
> limited feature set that can be enabled based on peer-to-peer
> communications or relay without the need for transcoding or
> other H.264 related server functionality. This is why the currently of= fered
> compromise works for us even though H.264 licensing policy is less the= n
> ideal.
> _____________
> Roman Shpount

=C2=A0 =C2=A0This explanation is definitely helpful. Thank you!

--
John Leslie <john@jlc.= net>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb


--001a11c1d37044958f0509f54b12-- From nobody Thu Dec 11 11:40:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7CB1A1B57 for ; Thu, 11 Dec 2014 11:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B77CDtaSxbX5 for ; Thu, 11 Dec 2014 11:40:16 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100631A1A9A for ; Thu, 11 Dec 2014 11:40:15 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id x19so5591540ier.13 for ; Thu, 11 Dec 2014 11:40:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sPZI+32+ZAlWcxtEAYX9T5Gw79KM4hRNyjc+VOFlCzA=; b=a9e5lFYNmvEU4ewpLSx4wWekUXJQr9z9ndPInEkkYbR72KsyEMfOhu9hHrrmkZqqLG EVDxIeTRBoPVnoTy+l7LTBkaW0Bc6moEa1NMvcUyBPkcP5/8EJV8gCNBCjMP2Vg8749T Q3A/7LTUapK/oOhyJfeuHMzi2CR94On9gYbL6xUZdC3PXosnYykV8bTM1QksxPhgvffe 9SCUyPtRHnx52NoaYMriW/Tx+mal0uX9ZGlhYS8YwAFMGFjRPXUAZlkJZOIvXS9eaWZg wZE0neltftQbeM3pjKWV8JK5jQhbJk87JkRFH7DZ3EF4qYtlNUotJKm4huTR6FtICGCH 6o8w== X-Gm-Message-State: ALoCoQn5Ak435jMdv9zFdH6EHsN12Lh+qjn8D9WCjQCA6cDtb6HwieNZbvpr0lkI6o+7qH5NKzq4 X-Received: by 10.50.225.1 with SMTP id rg1mr652957igc.39.1418326815197; Thu, 11 Dec 2014 11:40:15 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id b7sm182975igx.15.2014.12.11.11.40.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Dec 2014 11:40:14 -0800 (PST) Message-ID: <5489F2DE.8030602@bbs.darktech.org> Date: Thu, 11 Dec 2014 14:39:10 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> <87iohisl7h.fsf@mid.deneb.enyo.de> <20141211183248.GE47023@verdi> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FrjAzMYCkHoq5g3Qtqrh6W06By0 Subject: [rtcweb] What is the judging criteria? (Was: H.264 patent licensing options) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 19:40:17 -0000 Richard, I don't want to start a flamewar but I don't get the IETF's reasoning on this matter. Is the IETF planning to pick one or more MTI codecs based purely on technical merits? Or are they taking other matters (such as licensing) into consideration? If you are judging based purely on technical merits, why are we entertaining this "compromise" proposal? I thought we had agreed long ago that both codecs were more or less equivalent from a technical merit point of view. If you are not judging purely based on technical merits, why are we not allowed to debate matters that are part of the judging criteria? Gili On 11/12/2014 1:53 PM, Richard Barnes wrote: > Just to clarify: The above messages closing the thread were with my > RAI AD hat on, so as a matter of IETF process. From nobody Thu Dec 11 12:51:37 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713921A871B for ; Thu, 11 Dec 2014 12:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hr_1Th6NArhN for ; Thu, 11 Dec 2014 12:51:24 -0800 (PST) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497C51A016B for ; Thu, 11 Dec 2014 12:51:24 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id im6so2870938vcb.25 for ; Thu, 11 Dec 2014 12:51:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PynNfLxuogkXU104Mt+ETsK06DuLeqXQARI9NXuByzo=; b=aDaJyGBI+CHP6u3EBRNfF/aB77RYxINAod5vHhnUipLwSI579nUdFSpI183ZVDgpTa QjJOhFtwOYxNfLfK03qJogs8t0H1qIrC208oRLjIg1NuIeLcCpKkEqe6aCJytSeAbxPY ukXxUHh7PnG3bHFqFv5ZZmTQDfR6FRNptzge06VZ5hMDX8U4Ugdj205d74ktyEr2ZNeF fbMUqYcdCQ7A2mOZsJGsKdeFmhA1GVryINtN1bYXPzXsGp+8ifwDg5fbiNi60nJl4NUk jEq4PtsdytUCWwUYo6a2sdnKY81FbredwIoP6Ld5M79B1TJ29pKVWvjOfD5QD8OMr01o L+cg== X-Gm-Message-State: ALoCoQlsgjBtAYXSKC3r5Icm7irfT5FY2VHYzTW2h7fwjRGQit1MrUEHeys/PMxfYO43Ke1BvnE2 MIME-Version: 1.0 X-Received: by 10.220.3.71 with SMTP id 7mr8809701vcm.56.1418331083456; Thu, 11 Dec 2014 12:51:23 -0800 (PST) Received: by 10.31.139.9 with HTTP; Thu, 11 Dec 2014 12:51:23 -0800 (PST) In-Reply-To: <5489F2DE.8030602@bbs.darktech.org> References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> <87iohisl7h.fsf@mid.deneb.enyo.de> <20141211183248.GE47023@verdi> <5489F2DE.8030602@bbs.darktech.org> Date: Thu, 11 Dec 2014 15:51:23 -0500 Message-ID: From: Richard Barnes To: cowwoc Content-Type: multipart/alternative; boundary=001a11c3cb1a67569e0509f6f0e1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/z9DqT4oq7-zHGbhPXHgDaDddQhU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What is the judging criteria? (Was: H.264 patent licensing options) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 20:51:35 -0000 --001a11c3cb1a67569e0509f6f0e1 Content-Type: text/plain; charset=UTF-8 Hi Gili, Fair question. Keep in mind that the context here is Sean's message of December 5, which was to confirm the consensus in the room at the IETF meeting. He noted three objections that were discussed in the room, including one about IPR. He sought to confirm consensus on the list, and asked that anyone raise any other, additional issues by December 19. Appropriate responses to his message would include: people who were in the room re-stating their positions, people who were not in the room stating positions, and people raising issues that were not in his issue list. That said, it is important that all relevant facts be on the table. So participants should feel free to point out direct, factual things about the options, technical or not. However, any discussion or *analysis* of those facts, however, has to be off the table. For example, "X open-source project is available under Y license" is OK, but "Y license doesn't allow Z use" is not. Obviously, participants are welcome to come to their positions by whatever means they choose. Participants may consider technical characteristics, IPR terms, legal issues, or anything else. However, this working group is chartered to develop technical solutions, and the expertise on this list is technical. So I am precluding discussion of non-technical matters in this forum. Thanks, --Richard On Thu, Dec 11, 2014 at 2:39 PM, cowwoc wrote: > Richard, > > I don't want to start a flamewar but I don't get the IETF's reasoning on > this matter. > > Is the IETF planning to pick one or more MTI codecs based purely on > technical merits? Or are they taking other matters (such as licensing) > into consideration? > > If you are judging based purely on technical merits, why are we > entertaining this "compromise" proposal? I thought we had agreed long ago > that both codecs were more or less equivalent from a technical merit point > of view. > > If you are not judging purely based on technical merits, why are we not > allowed to debate matters that are part of the judging criteria? > > Gili > > On 11/12/2014 1:53 PM, Richard Barnes wrote: > >> Just to clarify: The above messages closing the thread were with my RAI >> AD hat on, so as a matter of IETF process. >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c3cb1a67569e0509f6f0e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Gili,

Fair question.= =C2=A0 Keep in mind that the context here is Sean's message of December= 5, which was to confirm the consensus in the room at the IETF meeting.=C2= =A0 He noted three objections that were discussed in the room, including on= e about IPR. He sought to confirm consensus on the list, and asked that any= one raise any other, additional issues by December 19.

=
Appropriate responses to his message would include: people who were in= the room re-stating their positions, people who were not in the room stati= ng positions, and people raising issues that were not in his issue list.

That said, it is important that all relevant facts b= e on the table.=C2=A0 So participants should feel free to point out direct,= factual things about the options, technical or not.=C2=A0 However, any dis= cussion or *analysis* of those facts, however, has to be off the table.=C2= =A0 For example, "X open-source project is available under Y license&q= uot; is OK, but "Y license doesn't allow Z use" is not.
=

Obviously, participants are welcome to come to their po= sitions by whatever means they choose.=C2=A0 Participants may consider tech= nical characteristics, IPR terms, legal issues, or anything else.=C2=A0 How= ever, this working group is chartered to develop technical solutions, and t= he expertise on this list is technical.=C2=A0 So I am precluding discussion= of non-technical matters in this forum.

Thanks,
--Richard

On Thu, Dec 11, 2014 at 2:39 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
Richard,=

I don't want to start a flamewar but I don't get the IETF's rea= soning on this matter.

Is the IETF planning to pick one or more MTI codecs based purely on technic= al merits?=C2=A0 Or are they taking other matters (such as licensing) into = consideration?

If you are judging based purely on technical merits, why are we entertainin= g this "compromise" proposal? I thought we had agreed long ago th= at both codecs were more or less equivalent from a technical merit point of= view.

If you are not judging purely based on technical merits, why are we not all= owed to debate matters that are part of the judging criteria?

Gili

On 11/12/2014 1:53 PM, Richard Barnes wrote:
Just to clarify: The above messages closing the thread were with my RAI AD = hat on, so as a matter of IETF process.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--001a11c3cb1a67569e0509f6f0e1-- From nobody Thu Dec 11 13:02:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA901A8033 for ; Thu, 11 Dec 2014 13:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STXG9bS-2jHd for ; Thu, 11 Dec 2014 13:02:10 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4491A1C06 for ; Thu, 11 Dec 2014 13:02:10 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so621638wiv.2 for ; Thu, 11 Dec 2014 13:02:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AqllShfHmJCS+I5TPE+cFYpNxnUvURJ0gyuBZziv1Tk=; b=SAWFoow56fbZ5ZU3/3Q48TU44xHw7/1AZwzHNKUE2uno1lPeZWpCteJT+7pHY7M5VC Ft3c7LaeWkn6ylMTFJZLwSjUV+WdVbf8BMCq83H41vq38sFYczhO7r0UvpsclYjEZgiW ZU3aCgW27dK2ImpdcAoudxX5UnkyXBSJV5Ozip4m81nM0WykqPlbojLtk2kMsU8SgqnX DbrpLTn6hDotSbWztIDI8UwRYxoc3wYwJYx/pZh+flMNSStIMEAhUQO1UgGeY5mIp/LY o9WeZyBVoc1Md1xcMM4uZR8mDMNkl677zfGq0pzFd3a7oPH+Lqiv+Fwpz9C9Ll2V7FP7 WVbA== X-Gm-Message-State: ALoCoQkIT7Z2oIrf3arz8UDQyHtMJYOhuZZU/dzM21QAo6w5YPR8W7LR7q3wBg9ei8W3ducZxBb2 X-Received: by 10.180.81.7 with SMTP id v7mr1481195wix.74.1418331729022; Thu, 11 Dec 2014 13:02:09 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com. [74.125.82.46]) by mx.google.com with ESMTPSA id gi5sm3091124wjd.26.2014.12.11.13.02.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Dec 2014 13:02:07 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so7592252wgg.33 for ; Thu, 11 Dec 2014 13:02:07 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.76.7 with SMTP id g7mr1595250wiw.38.1418331727564; Thu, 11 Dec 2014 13:02:07 -0800 (PST) Received: by 10.217.191.202 with HTTP; Thu, 11 Dec 2014 13:02:07 -0800 (PST) In-Reply-To: References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> <87iohisl7h.fsf@mid.deneb.enyo.de> <20141211183248.GE47023@verdi> <5489F2DE.8030602@bbs.darktech.org> Date: Thu, 11 Dec 2014 16:02:07 -0500 Message-ID: From: Roman Shpount To: Richard Barnes Content-Type: multipart/alternative; boundary=f46d043893c7cb98c90509f716c0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NNv0gRgIA3k7XxumRnq1nTekyUU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What is the judging criteria? (Was: H.264 patent licensing options) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 21:02:13 -0000 --f46d043893c7cb98c90509f716c0 Content-Type: text/plain; charset=UTF-8 Richard, Is it fair to state things like due to licensing considerations, as we see them, we will implement things X and Y in the following manner, and because of this we support the proposed compromise? _____________ Roman Shpount On Thu, Dec 11, 2014 at 3:51 PM, Richard Barnes wrote: > Hi Gili, > > Fair question. Keep in mind that the context here is Sean's message of > December 5, which was to confirm the consensus in the room at the IETF > meeting. He noted three objections that were discussed in the room, > including one about IPR. He sought to confirm consensus on the list, and > asked that anyone raise any other, additional issues by December 19. > > Appropriate responses to his message would include: people who were in the > room re-stating their positions, people who were not in the room stating > positions, and people raising issues that were not in his issue list. > > That said, it is important that all relevant facts be on the table. So > participants should feel free to point out direct, factual things about the > options, technical or not. However, any discussion or *analysis* of those > facts, however, has to be off the table. For example, "X open-source > project is available under Y license" is OK, but "Y license doesn't allow Z > use" is not. > > Obviously, participants are welcome to come to their positions by whatever > means they choose. Participants may consider technical characteristics, > IPR terms, legal issues, or anything else. However, this working group is > chartered to develop technical solutions, and the expertise on this list is > technical. So I am precluding discussion of non-technical matters in this > forum. > > Thanks, > --Richard > > > On Thu, Dec 11, 2014 at 2:39 PM, cowwoc wrote: > >> Richard, >> >> I don't want to start a flamewar but I don't get the IETF's reasoning on >> this matter. >> >> Is the IETF planning to pick one or more MTI codecs based purely on >> technical merits? Or are they taking other matters (such as licensing) >> into consideration? >> >> If you are judging based purely on technical merits, why are we >> entertaining this "compromise" proposal? I thought we had agreed long ago >> that both codecs were more or less equivalent from a technical merit point >> of view. >> >> If you are not judging purely based on technical merits, why are we not >> allowed to debate matters that are part of the judging criteria? >> >> Gili >> >> On 11/12/2014 1:53 PM, Richard Barnes wrote: >> >>> Just to clarify: The above messages closing the thread were with my RAI >>> AD hat on, so as a matter of IETF process. >>> >> >> _______________________________________________ >> 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 > > --f46d043893c7cb98c90509f716c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Richard,

Is it fair to state things lik= e due to licensing considerations, as we see them, we will implement things= X and Y in the following manner, and because of this we support the propos= ed compromise?

_____________
Roman Shpount

On Thu, Dec 11, 2014 at 3:51 PM, Richard Bar= nes <r= lb@ipv.sx> wrote:
Hi Gili,

Fair question.=C2=A0 K= eep in mind that the context here is Sean's message of December 5, whic= h was to confirm the consensus in the room at the IETF meeting.=C2=A0 He no= ted three objections that were discussed in the room, including one about I= PR. He sought to confirm consensus on the list, and asked that anyone raise= any other, additional issues by December 19.

Appr= opriate responses to his message would include: people who were in the room= re-stating their positions, people who were not in the room stating positi= ons, and people raising issues that were not in his issue list.
<= br>
That said, it is important that all relevant facts be on the = table.=C2=A0 So participants should feel free to point out direct, factual = things about the options, technical or not.=C2=A0 However, any discussion o= r *analysis* of those facts, however, has to be off the table.=C2=A0 For ex= ample, "X open-source project is available under Y license" is OK= , but "Y license doesn't allow Z use" is not.

<= /div>
Obviously, participants are welcome to come to their positions by= whatever means they choose.=C2=A0 Participants may consider technical char= acteristics, IPR terms, legal issues, or anything else.=C2=A0 However, this= working group is chartered to develop technical solutions, and the experti= se on this list is technical.=C2=A0 So I am precluding discussion of non-te= chnical matters in this forum.

Thanks,
-= -Richard


On Thu, Dec 11, 2014 at 2:39 PM, c= owwoc <cowwoc@bbs.darktech.org> wrote:
Richard,

I don't want to start a flamewar but I don't get the IETF's rea= soning on this matter.

Is the IETF planning to pick one or more MTI codecs based purely on technic= al merits?=C2=A0 Or are they taking other matters (such as licensing) into = consideration?

If you are judging based purely on technical merits, why are we entertainin= g this "compromise" proposal? I thought we had agreed long ago th= at both codecs were more or less equivalent from a technical merit point of= view.

If you are not judging purely based on technical merits, why are we not all= owed to debate matters that are part of the judging criteria?

Gili

On 11/12/2014 1:53 PM, Richard Barnes wrote:
Just to clarify: The above messages closing the thread were with my RAI AD = hat on, so as a matter of IETF process.

_______________________________________________
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


--f46d043893c7cb98c90509f716c0-- From nobody Thu Dec 11 13:35:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22091A07BD for ; Thu, 11 Dec 2014 13:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JW3hE1qBZPWD for ; Thu, 11 Dec 2014 13:35:16 -0800 (PST) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F021A020B for ; Thu, 11 Dec 2014 13:35:15 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id h15so392870igd.14 for ; Thu, 11 Dec 2014 13:35:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=a1G94rtod2sDGTprvvkHyHh9J9q+tc530qsKiFVXSGE=; b=FGM9KSj7Z9mGYs4a6nmDONHcXu/nuKejTy+zrH1MTGgCVLbarALhZ8UXWoapzrr5P5 OfToN2BcMLdUMFt/nBdK6V7a1hn7UkxQEi63TTlNT+h4HB5uWKN3R2xRH5+bMhXtpBR4 W0NKtT8FH6avcVKmqtFIEpgziBRyidl1VtH/hHOJr4V322cAuU/Qwt0+DZUC6lsKOxv5 kfy7sHgUOW0G38/D3NAXKTitWptYanu1qYV+tDNBj1XDjY+WfCPMxxHmMYr61BLJLfJH kX8r29kBbxwBvBr1Ch1Xw9jS3BCI7SdzfnPmd3HfdBeqxFUBPQSmx5AI4a2tp1X/R9is iyvA== X-Gm-Message-State: ALoCoQlIziBHLOOz4M+UiG15APMeGYLirJK7pnB/lzZxiTVFezfUuGd7fa3CXMuL3GwxZpEpUBlt X-Received: by 10.51.17.107 with SMTP id gd11mr1216389igd.45.1418333715334; Thu, 11 Dec 2014 13:35:15 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id ii3sm1371649igb.1.2014.12.11.13.35.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Dec 2014 13:35:14 -0800 (PST) Message-ID: <548A0E11.4090709@andyet.net> Date: Thu, 11 Dec 2014 14:35:13 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Harald Alvestrand , "rtcweb@ietf.org" References: <5486C48D.8040602@alvestrand.no> In-Reply-To: <5486C48D.8040602@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fQrQ96IOlM2olwSUDilRqRJMDHA Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 21:35:18 -0000 On 12/9/14, 2:44 AM, Harald Alvestrand wrote: > I note that the "confirming sense of the room" thread has gotten a lot > of messages that are not declaring a position on the question. > > I also note that from the messages on the thread, I can't figure out if > Keith Drage, Gili, Monty Montgomery or Peter Saint-Andre have taken a > position (I could guess, but I don't want to - besides, they might not > want to take a position, which is perfectly OK). +0. I neither support nor object to The Honolulu Compromise (THC). As Mo Zanaty pointed out, its primary benefit is that it necessitates codec negotiation, capabilities discovery, and other features that can will prove helpful once we have a truly open and technically superior video codec (think "Opus for video"). Until then, THC is merely a temporary palliative. Peter P.S. https://blog.andyet.com/2014/12/11/video-codecs-past-present-future From nobody Thu Dec 11 13:51:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F2A1A0121 for ; Thu, 11 Dec 2014 13:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVUyQCf68eZS for ; Thu, 11 Dec 2014 13:51:14 -0800 (PST) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EA721A007C for ; Thu, 11 Dec 2014 13:51:14 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id hq11so2950220vcb.23 for ; Thu, 11 Dec 2014 13:51:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CgZjlAQuUamjrJQgcSbi0jROWeSsHp8QJ9kvFDqSoS4=; b=V/NZJlthq1/biYRiFhsJ71LzFw1A6JWOzZ0kPr1sLIpXuNS4ijjNBZVitTKuvu16vE gxnyNI4xBymLFTUJUTQWD/iGAPiA1/X8ugphvYI31VKi2YSmtmeI701gK4aYx5nUcmRI ixAMvKm55h80maIBGZfl289Uz9kxzeMEPuAB80TE8V8JMLbOO6R7rXRVFdreEQ0lltqX HWzu6EinS+Pgig/ezXDR3AFYwzMOfT2WA1eVtWuFeydkIptiLxdgdrIB2l1BDqWm+ck0 yacRzRQKpqmeIOJzv2W/0JZQT4Lt1AmK3Wax+NTTS0/26j8TNXMDb0JH0X3SX0BBxqfi LDew== X-Gm-Message-State: ALoCoQklIsCUafQJHha3G/SpEeUxfSXrv/0IaJC+1YCKQA7LNyKmXh2Z05e2ygqLcmTPZQS0J1Y+ MIME-Version: 1.0 X-Received: by 10.220.92.69 with SMTP id q5mr6383309vcm.35.1418334673322; Thu, 11 Dec 2014 13:51:13 -0800 (PST) Received: by 10.31.139.9 with HTTP; Thu, 11 Dec 2014 13:51:13 -0800 (PST) In-Reply-To: References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> <87iohisl7h.fsf@mid.deneb.enyo.de> <20141211183248.GE47023@verdi> <5489F2DE.8030602@bbs.darktech.org> Date: Thu, 11 Dec 2014 16:51:13 -0500 Message-ID: From: Richard Barnes To: Roman Shpount Content-Type: multipart/alternative; boundary=089e015375ba6058bb0509f7c609 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/cz9VML411PBBt1cYVhGbX3rttig Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What is the judging criteria? (Was: H.264 patent licensing options) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 21:51:19 -0000 --089e015375ba6058bb0509f7c609 Content-Type: text/plain; charset=UTF-8 Yes. It is a fact, about you -- namely, the fact that you intent to implement. As above, analysis of that position would be off the table. --Richard On Thu, Dec 11, 2014 at 4:02 PM, Roman Shpount wrote: > Richard, > > Is it fair to state things like due to licensing considerations, as we see > them, we will implement things X and Y in the following manner, and because > of this we support the proposed compromise? > > _____________ > Roman Shpount > > On Thu, Dec 11, 2014 at 3:51 PM, Richard Barnes wrote: > >> Hi Gili, >> >> Fair question. Keep in mind that the context here is Sean's message of >> December 5, which was to confirm the consensus in the room at the IETF >> meeting. He noted three objections that were discussed in the room, >> including one about IPR. He sought to confirm consensus on the list, and >> asked that anyone raise any other, additional issues by December 19. >> >> Appropriate responses to his message would include: people who were in >> the room re-stating their positions, people who were not in the room >> stating positions, and people raising issues that were not in his issue >> list. >> >> That said, it is important that all relevant facts be on the table. So >> participants should feel free to point out direct, factual things about the >> options, technical or not. However, any discussion or *analysis* of those >> facts, however, has to be off the table. For example, "X open-source >> project is available under Y license" is OK, but "Y license doesn't allow Z >> use" is not. >> >> Obviously, participants are welcome to come to their positions by >> whatever means they choose. Participants may consider technical >> characteristics, IPR terms, legal issues, or anything else. However, this >> working group is chartered to develop technical solutions, and the >> expertise on this list is technical. So I am precluding discussion of >> non-technical matters in this forum. >> >> Thanks, >> --Richard >> >> >> On Thu, Dec 11, 2014 at 2:39 PM, cowwoc wrote: >> >>> Richard, >>> >>> I don't want to start a flamewar but I don't get the IETF's reasoning on >>> this matter. >>> >>> Is the IETF planning to pick one or more MTI codecs based purely on >>> technical merits? Or are they taking other matters (such as licensing) >>> into consideration? >>> >>> If you are judging based purely on technical merits, why are we >>> entertaining this "compromise" proposal? I thought we had agreed long ago >>> that both codecs were more or less equivalent from a technical merit point >>> of view. >>> >>> If you are not judging purely based on technical merits, why are we not >>> allowed to debate matters that are part of the judging criteria? >>> >>> Gili >>> >>> On 11/12/2014 1:53 PM, Richard Barnes wrote: >>> >>>> Just to clarify: The above messages closing the thread were with my RAI >>>> AD hat on, so as a matter of IETF process. >>>> >>> >>> _______________________________________________ >>> 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 >> >> > --089e015375ba6058bb0509f7c609 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes.=C2=A0 It is a fact, about you -- namely, the fact tha= t you intent to implement.=C2=A0 As above, analysis of that position would = be off the table.

--Richard

On Thu, Dec 11, 2014 at 4:02 PM, R= oman Shpount <roman@telurix.com> wrote:
Richard,

Is it fair to st= ate things like due to licensing considerations, as we see them, we will im= plement things X and Y in the following manner, and because of this we supp= ort the proposed compromise?

_____________
Roman Shpount

On Thu, Dec 11, 2014 at 3:51 PM, Richard Bar= nes <r= lb@ipv.sx> wrote:
Hi Gili,

Fair question.=C2=A0 K= eep in mind that the context here is Sean's message of December 5, whic= h was to confirm the consensus in the room at the IETF meeting.=C2=A0 He no= ted three objections that were discussed in the room, including one about I= PR. He sought to confirm consensus on the list, and asked that anyone raise= any other, additional issues by December 19.

Appr= opriate responses to his message would include: people who were in the room= re-stating their positions, people who were not in the room stating positi= ons, and people raising issues that were not in his issue list.
<= br>
That said, it is important that all relevant facts be on the = table.=C2=A0 So participants should feel free to point out direct, factual = things about the options, technical or not.=C2=A0 However, any discussion o= r *analysis* of those facts, however, has to be off the table.=C2=A0 For ex= ample, "X open-source project is available under Y license" is OK= , but "Y license doesn't allow Z use" is not.

<= /div>
Obviously, participants are welcome to come to their positions by= whatever means they choose.=C2=A0 Participants may consider technical char= acteristics, IPR terms, legal issues, or anything else.=C2=A0 However, this= working group is chartered to develop technical solutions, and the experti= se on this list is technical.=C2=A0 So I am precluding discussion of non-te= chnical matters in this forum.

Thanks,
-= -Richard

On Thu, Dec 11, 2014 at 2:39 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
Richard,=

I don't want to start a flamewar but I don't get the IETF's rea= soning on this matter.

Is the IETF planning to pick one or more MTI codecs based purely on technic= al merits?=C2=A0 Or are they taking other matters (such as licensing) into = consideration?

If you are judging based purely on technical merits, why are we entertainin= g this "compromise" proposal? I thought we had agreed long ago th= at both codecs were more or less equivalent from a technical merit point of= view.

If you are not judging purely based on technical merits, why are we not all= owed to debate matters that are part of the judging criteria?

Gili

On 11/12/2014 1:53 PM, Richard Barnes wrote:
Just to clarify: The above messages closing the thread were with my RAI AD = hat on, so as a matter of IETF process.

_______________________________________________
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



--089e015375ba6058bb0509f7c609-- From nobody Thu Dec 11 13:55:31 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815C51A0101 for ; Thu, 11 Dec 2014 13:55:27 -0800 (PST) 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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwUV6hDvoayN for ; Thu, 11 Dec 2014 13:55:25 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5271A0032 for ; Thu, 11 Dec 2014 13:55:25 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id tp5so5768923ieb.9 for ; Thu, 11 Dec 2014 13:55:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=AXZYe63m1AOlV2otFj00o2m3g7jHoTitr27+aNPVUq0=; b=fMwPVl+6dMaPSdjfhvFsyv8DXVk9N4WnbfoG77RmhlFnraiKeEKSa/X3oLIKEh+PPD n0MgjvTzvkp0JaIWUbJU+Mn7MSFuwajPLDYrzpVOkhzwtybQipfLcxSK8YyAa1iEQ8qf hBv9vxPMRLrEMujBg4E/PorZ/1sO0onB1NoBjiBBpBsPdBMUtTLnjRsJasQkmZsKJWkB 45wQZRZ4PzmAYq8LYVBr9CLYe7WEAX+DyXfbEC4qsrn1bzmPSFr8wGUNBObqICcNe+Es Tfo3QCkjkFikK/jpHetbGRlDBXTdpy4FlL/hcfeQv8Aed4QymPDttSpc5x4AywolqTVb 1Qfg== X-Gm-Message-State: ALoCoQnN80kGyGBctsB1HxSpdhK+LCvdvo7kFbYnhvpgZYQ/f1Gf0UL3hAtCuzeyCbPHcDnVAvqU X-Received: by 10.42.194.17 with SMTP id dw17mr13515803icb.4.1418334924474; Thu, 11 Dec 2014 13:55:24 -0800 (PST) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id qc7sm370795igb.5.2014.12.11.13.55.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Dec 2014 13:55:23 -0800 (PST) Message-ID: <548A1288.7040001@bbs.darktech.org> Date: Thu, 11 Dec 2014 16:54:16 -0500 From: cowwoc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Richard Barnes References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> <87iohisl7h.fsf@mid.deneb.enyo.de> <20141211183248.GE47023@verdi> <5489F2DE.8030602@bbs.darktech.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070903050407030103060300" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/w0DAy0claM2x6Sg4jBiV2OvYinQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What is the judging criteria? (Was: H.264 patent licensing options) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 21:55:27 -0000 This is a multi-part message in MIME format. --------------070903050407030103060300 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Richard, Please try to emphasize this fact (what is acceptable vs what is not) the next time you close a thread. I agree with your position, but I was not aware of what you meant until now. Thanks, Gili On 11/12/2014 3:51 PM, Richard Barnes wrote: > Hi Gili, > > Fair question. Keep in mind that the context here is Sean's message > of December 5, which was to confirm the consensus in the room at the > IETF meeting. He noted three objections that were discussed in the > room, including one about IPR. He sought to confirm consensus on the > list, and asked that anyone raise any other, additional issues by > December 19. > > Appropriate responses to his message would include: people who were in > the room re-stating their positions, people who were not in the room > stating positions, and people raising issues that were not in his > issue list. > > That said, it is important that all relevant facts be on the table. > So participants should feel free to point out direct, factual things > about the options, technical or not. However, any discussion or > *analysis* of those facts, however, has to be off the table. For > example, "X open-source project is available under Y license" is OK, > but "Y license doesn't allow Z use" is not. > > Obviously, participants are welcome to come to their positions by > whatever means they choose. Participants may consider technical > characteristics, IPR terms, legal issues, or anything else. However, > this working group is chartered to develop technical solutions, and > the expertise on this list is technical. So I am precluding > discussion of non-technical matters in this forum. > > Thanks, > --Richard > > > On Thu, Dec 11, 2014 at 2:39 PM, cowwoc > wrote: > > Richard, > > I don't want to start a flamewar but I don't get the IETF's > reasoning on this matter. > > Is the IETF planning to pick one or more MTI codecs based purely > on technical merits? Or are they taking other matters (such as > licensing) into consideration? > > If you are judging based purely on technical merits, why are we > entertaining this "compromise" proposal? I thought we had agreed > long ago that both codecs were more or less equivalent from a > technical merit point of view. > > If you are not judging purely based on technical merits, why are > we not allowed to debate matters that are part of the judging > criteria? > > Gili > > On 11/12/2014 1:53 PM, Richard Barnes wrote: > > Just to clarify: The above messages closing the thread were > with my RAI AD hat on, so as a matter of IETF process. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --------------070903050407030103060300 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Richard,

Please try to emphasize this fact (what is acceptable vs what is not) the next time you close a thread. I agree with your position, but I was not aware of what you meant until now.

Thanks,
Gili

On 11/12/2014 3:51 PM, Richard Barnes wrote:
Hi Gili,

Fair question.  Keep in mind that the context here is Sean's message of December 5, which was to confirm the consensus in the room at the IETF meeting.  He noted three objections that were discussed in the room, including one about IPR. He sought to confirm consensus on the list, and asked that anyone raise any other, additional issues by December 19.

Appropriate responses to his message would include: people who were in the room re-stating their positions, people who were not in the room stating positions, and people raising issues that were not in his issue list.

That said, it is important that all relevant facts be on the table.  So participants should feel free to point out direct, factual things about the options, technical or not.  However, any discussion or *analysis* of those facts, however, has to be off the table.  For example, "X open-source project is available under Y license" is OK, but "Y license doesn't allow Z use" is not.

Obviously, participants are welcome to come to their positions by whatever means they choose.  Participants may consider technical characteristics, IPR terms, legal issues, or anything else.  However, this working group is chartered to develop technical solutions, and the expertise on this list is technical.  So I am precluding discussion of non-technical matters in this forum.

Thanks,
--Richard


On Thu, Dec 11, 2014 at 2:39 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
Richard,

I don't want to start a flamewar but I don't get the IETF's reasoning on this matter.

Is the IETF planning to pick one or more MTI codecs based purely on technical merits?  Or are they taking other matters (such as licensing) into consideration?

If you are judging based purely on technical merits, why are we entertaining this "compromise" proposal? I thought we had agreed long ago that both codecs were more or less equivalent from a technical merit point of view.

If you are not judging purely based on technical merits, why are we not allowed to debate matters that are part of the judging criteria?

Gili

On 11/12/2014 1:53 PM, Richard Barnes wrote:
Just to clarify: The above messages closing the thread were with my RAI AD hat on, so as a matter of IETF process.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--------------070903050407030103060300-- From nobody Thu Dec 11 14:41:13 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F791A89AF for ; Thu, 11 Dec 2014 14:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7Dbt8YBDxV6 for ; Thu, 11 Dec 2014 14:41:09 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id D45F41A1BE7 for ; Thu, 11 Dec 2014 14:41:08 -0800 (PST) Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 11 Dec 2014 17:41:03 -0500 Received: from XCT116CNC.rim.net (10.65.161.216) by XCT108CNC.rim.net (10.65.161.208) with Microsoft SMTP Server (TLS) id 14.3.210.2; Thu, 11 Dec 2014 17:41:02 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Thu, 11 Dec 2014 17:41:02 -0500 From: Gaelle Martin-Cocher To: Sergio Garcia Murillo , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WebRTC endpoint categories Thread-Index: AQHQFM0kak8mo4J6FkamLzsTItyLlZyJylqAgAEt3QA= Date: Thu, 11 Dec 2014 22:41:02 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF35FA2D@XMB111CNC.rim.net> References: <20141210012208.GK19538@hex.shelbyville.oz> <20141210200027.GM19538@hex.shelbyville.oz> <20141210230012.GN19538@hex.shelbyville.oz> <5488D58B.6040606@gmail.com> In-Reply-To: <5488D58B.6040606@gmail.com> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/H0RO0-Pwg_jmHELpGxdbMajovIk Subject: Re: [rtcweb] WebRTC endpoint categories X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 22:41:11 -0000 QW5zd2VyaW5nIHlvdXIgcXVlc3Rpb25zIGJlbG93IHdpdGggW2dtY10gYW5kIHJlcGVhdGluZyBt eXNlbGYsIHNvcnJ5Lg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcnRjd2Vi IFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTZXJnaW8gR2Fy Y2lhIE11cmlsbG8NClNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMTAsIDIwMTQgNjoyMiBQTQ0K VG86IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdlYlJUQyBlbmRwb2lu dCBjYXRlZ29yaWVzDQoNCg0KQWxzbywgSSBoZWFyIHNvbWUgcGVvcGxlIGNvbXBsYWluaW5nIGFi b3V0IHRoZSBkZWZpbml0aW9uIG9mIGEgV2ViUlRDIGNvbXBhdGlibGUgZW5kcG9pbnQsIGJ1dCBp dCB3b3VsZCBiZSBnb29kIGlmIHRob3NlIHBlb3BsZSBleHBvc2Ugd2hhdCBhcmUgdGhlIGNoYW5n ZXMgdGhhdCB0aGV5IHdhbnQgdG8gaW50cm9kdWNlOg0KICAtUmVtb3ZlIHdlYnJ0YyBjb21wYXRp YmxlIGVuZHBvaW50cyBtZW50aW9ucyBmcm9tIHNwZWMgDQpbZ21jXSBmb3IgbWUsIHRoYXQgaXMg YW4gb3B0aW9uIGlmICdXZWJSVEMtY29tcGF0aWJsZSBlbmRwb2ludCcgaXMgbm90IGJldHRlciBk ZWZpbmVkLg0KQ3VycmVudGx5IHRoYXQgdW5jbGVhciBjYXRlZ29yeSBjb3JyZXNwb25kIHRvIGJv dGgg4oCYbWVhbmluZ2Z1bOKAmSBlbnRpdGllcyAoZ2F0ZXdheSwgY3VycmVudCBXZWJSVEMgbGli cmFpcmllcywgb3IgUm9u4oCZcyBjb2ZmZWUgbWFrZXIpIGFuZCBwb3NzaWJseSBzb21lIHN1Yi1z dGFuZGFyZCBpbXBsZW1lbnRhdGlvbi4NCg0KICAtQ2hhbmdlIGRlZmluaXRpb24gb2YgYSB3ZWJy dGMgY29tcGF0aWJsZSBlbmRwb2ludCANCltnbWNdIHllcywgb3IgYWN0dWFsbHkgY2xlYXJseSBz ZXQgb3V0IHRoZSByZXF1aXJlbWVudHMgdGhhdCBhcHBseSB0byB0aGVtLiBBcyBzYWlkIGJlZm9y ZTogVGhlIFdlYlJUQyBnYXRld2F5IGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQt YWx2ZXN0cmFuZC1ydGN3ZWItZ2F0ZXdheXMtMDEudHh0IGlzIGRlZmluZWQgYXMgYSBXZWJSVEMt Y29tcGF0aWJsZSBlbmRwb2ludCB3aXRoIHNvbWUgcmVxdWlyZW1lbnRzIGJlaW5nIGFwcGxpZWQg dG8gaXQuDQpJIGFtIG5vdCBzdXJlIGhvdyB0aGUgbGFzdCBzZW50ZW5jZSBpbiB0aGUgV2ViUlRD LWNvbXBhdGlibGUgZW5kcG9pbnQgZGVmaW5pdGlvbiAg4oCcSXQgaXMgbm90IGNvbnN0cmFpbmVk IGJ5IHRoaXMgc3BlY2lmaWNhdGlvbuKApuKAnSAgYXBwbGllcyB0byB0aGUgZ2F0ZXdheS4NClBy b3Bvc2FsIEE6IGRlZmluZSBpbiBhIGRyYWZ0IHRoZSBtaW5pbWFsIHJlcXVpcmVtZW50cyB0aGF0 IGFwcGx5IHRvIGEgV2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnQgdG8g4oCcc3VjY2Vzc2Z1bGx5 IGNvbW11bmljYXRlIHdpdGggYSBXZWJSVEMgZW5kcG9pbnTigJ0uICAgIFRoaXMgZHJhZnQgY2Fu IGJlIGFuIGV4dGVuc2lvbiBvZiB0aGUgZ2F0ZXdheSBkcmFmdC4NClByb3Bvc2FsIEI6ICB0aGUg V2ViUlRDIGdhdGV3YXkgY291bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBXZWJSVEMtY29tcGF0aWJs ZSBlbmRwb2ludCBjYXRlZ29yeSBhbmQgY2FsbGVkIGEgd2ViUlRDIGdhdGV3YXkgd2l0aCBpdHMg b3duIGRyYWZ0LiBBcywgdGhlcmUgbWlnaHQgYmUgZW5vdWdoIGRpZmZlcmVuY2VzIHRvICBqdXN0 aWZ5IHR3byBlbnRpdGllcywgdGhlcmUgd291bGQgYmUgdGhlIGdhdGV3YXkgZHJhZnQgYW5kIGEg ZHJhZnQgZm9yIFdlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50IGFzIGluIHByb3Bvc2FsIEEuDQpD aGFuZ2luZyB0aGUgbmFtaW5nIG9mIOKAnFdlYlJUQy1jb21wYXRpYmxl4oCdIHRvIGEgbGVzcyBj b25mdXNpbmcgdGVybSBpcyBhIGNvc21ldGljIGNoYW5nZSAoYnV0IG1pZ2h0IGJlIGEgZ29vZCB0 aGluZykuDQoNCiAgLU1hbmRhdGUgd2VicnRjIGNvbXBhdGlibGUgZW5wb2ludHMgdG8gaW1wbGVt ZW50IGJvdGggTVRJIHZpZGVvIGNvZGVjcw0KW2dtY10gTm8uIA0KDQpQcm9wb3NhbCBDOiBhbGxv dyBhbiBlbmRwb2ludCB0aGF0IGRvIG5vdCByZXF1aXJlZCBzb21lIGZ1bmN0aW9ucyAoYnkgZnVu Y3Rpb24gaXQgbWVhbnMgdGhhdCBmdW5jdGlvbiBpbiBpdHMgZW50aXJldHkpIHRvIGJlIGNhbGxl ZCBhIFdlYlJUQyBlbmRwb2ludC4NCkV4YW1wbGU6IGFuIGVuZHBvaW50IHRoYXQgZG9lcyBub3Qg bmVlZCB0byBkbyBhdWRpbyBhdCBhbGwgaXMgYSB3ZWJSVEMgZW5kcG9pbnQuIEFuIGVuZHBvaW50 IHRoYXQgY2hvc2UgdG8gaW1wbGVtZW50IGEgc2luZ2xlIGF1ZGlvIGNvZGVjIG91dCBvZiB0aGUg dHdvIE1USSBhdWRpbyBjb2RlYyBpcyBub3QgYSBXZWJSVEMgZW5kcG9pbnQuDQoNCkdhw6tsbGUN Cg0KDQoNCg0KQmVzdCByZWdhcmRzDQpTZXJnaW8NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg== From nobody Thu Dec 11 14:48:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39331A8A52 for ; Thu, 11 Dec 2014 14:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtXxtuQQGPkI for ; Thu, 11 Dec 2014 14:48:26 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3424E1A1AA9 for ; Thu, 11 Dec 2014 14:48:26 -0800 (PST) Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail06.adl6.internode.on.net with ESMTP; 12 Dec 2014 09:18:25 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 10D01FFD93; Fri, 12 Dec 2014 09:18:24 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3tgyZPBQVKwU; Fri, 12 Dec 2014 09:18:23 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 047D6FFB5A; Fri, 12 Dec 2014 09:18:23 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id EB38F80470; Fri, 12 Dec 2014 09:18:22 +1030 (ACDT) Date: Fri, 12 Dec 2014 09:18:22 +1030 From: Ron To: Peter Saint-Andre - &yet , rtcweb@ietf.org Message-ID: <20141211224822.GB20986@hex.shelbyville.oz> References: <5486C48D.8040602@alvestrand.no> <548A0E11.4090709@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <548A0E11.4090709@andyet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LBqWH5SK9fTuWrzRo1Yu1gZRQNY Subject: Re: [rtcweb] Video codecs: Clear positions.... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 22:48:29 -0000 On Thu, Dec 11, 2014 at 02:35:13PM -0700, Peter Saint-Andre - &yet wrote: > On 12/9/14, 2:44 AM, Harald Alvestrand wrote: > >I note that the "confirming sense of the room" thread has gotten a lot > >of messages that are not declaring a position on the question. > > > >I also note that from the messages on the thread, I can't figure out if > >Keith Drage, Gili, Monty Montgomery or Peter Saint-Andre have taken a > >position (I could guess, but I don't want to - besides, they might not > >want to take a position, which is perfectly OK). > > +0. I neither support nor object to The Honolulu Compromise (THC). > > As Mo Zanaty pointed out, its primary benefit is that it necessitates codec > negotiation, capabilities discovery, and other features that can will prove > helpful once we have a truly open and technically superior video codec > (think "Opus for video"). > > Until then, THC is merely a temporary palliative. I still would be very interested in seeing some sort of rationale text that lays this side of things out a bit more openly, if only to give some sort of guidance (even if not normative) to future folk (and the broader internet community when this gets to them for review) about how we arrived at this state and why we've accepted it as an interim workaround even if a lot of us do think it's a kind of dopey situation to have ended up wedged in. I certainly don't think you're alone in criticising it in this way, whatever the concern may be for upsetting a delicate consensus. I'd like to think there is some way we can elaborate on this without risking pulling the ground out from under what people have been resigned to agreeing to here. Even Cisco folk are on the record for saying they would greatly prefer the kind of Final Solution that an "Opus for video" could bring us. I'd hinted at that again here: http://www.ietf.org/mail-archive/web/rtcweb/current/msg13819.html You are right that there are more than just these two camps though. There's also a (clearly large) subset of both that cares enough about the success of this project to compromise with each other in its best interests. With enough options and workarounds to get by until we have an IETF video codec to solve it properly (and I still do think that clarifying that is important here. If we're going to do something as audacious as mandate a patent minefield like H.264 when there is an equivalent that actually meets the IETF's aspirational requirements for RF technology, we need a better reason for that than "some people with H.264 patents insisted" if it's going to survive being challenged, or ridiculed, in later review). and in one or two other comments here. But I could easily forgive anyone for missing that in the current frenzied scrum. As I understand things we not only need to get consensus on this here, but it also needs to stand up to scrutiny from the IESG and internet community in general, who still could reject it as a load of hazy tosh if we haven't made our reasoning clear and acceptable to them. I don't know what the odds of that actually are, but I can only assume they are worse if we don't clearly explain not only "what" but "why" in a case like this. Cheers, Ron From nobody Thu Dec 11 15:18:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2AC1A887B for ; Thu, 11 Dec 2014 15:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cb9qbP3VQZZX for ; Thu, 11 Dec 2014 15:18:29 -0800 (PST) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9861A8A56 for ; Thu, 11 Dec 2014 15:17:53 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id hy4so3056487vcb.2 for ; Thu, 11 Dec 2014 15:17:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fNdRWZevCCST2AupT7i4FVVKh1q5qaG66O/S1KnXvNU=; b=EzdJAJDuMQaziib+rnu2n0o14wEccGyFdPlvzRDG/3qoD0QF6a3SXX+zuCTMNU4/L2 0uX3gNZVBbfeWSiWgmDIGiG1W/YinRAMjju1DV5MMgC24eCaxcYZcUB92UDM8UqACQ9J tHCGZ/ESmnCxezviT6ooXeAVFyedHiESrFPtgiHIcivXmRCFOu64qaU5HMwhmtNPpnTC a7A0POCJh9gkz3pCzsdjGNp4aSlVB6vWgZFVuSTFcX6hWKxzg5xcI6wdkRHvWv06HCRm IlDE+Gct8HIqp0CkEWpzodDDtVZaSjF5mLqD6LPB6i9g0YG2jsQMkxS+FvGp3q0ULXTL /IwA== X-Gm-Message-State: ALoCoQk7rgQkG9ou28JAmDCwEnxVdafVE4g3ASFcD0GLTkd+iw7SdtNHTHfgfpa3/1KZLMqx9Jt/ MIME-Version: 1.0 X-Received: by 10.52.10.198 with SMTP id k6mr7855956vdb.38.1418339873157; Thu, 11 Dec 2014 15:17:53 -0800 (PST) Received: by 10.31.139.9 with HTTP; Thu, 11 Dec 2014 15:17:53 -0800 (PST) In-Reply-To: <548A1288.7040001@bbs.darktech.org> References: <54820E74.90201@mozilla.com> <54861AD6.8090603@reavy.org> <63BC3D6D-03A1-41C2-B92D-C8DD57DC51DB@nostrum.com> <87d27r9o0a.fsf_-_@mid.deneb.enyo.de> <87iohisl7h.fsf@mid.deneb.enyo.de> <20141211183248.GE47023@verdi> <5489F2DE.8030602@bbs.darktech.org> <548A1288.7040001@bbs.darktech.org> Date: Thu, 11 Dec 2014 18:17:53 -0500 Message-ID: From: Richard Barnes To: cowwoc Content-Type: multipart/alternative; boundary=20cf30334e254f865b0509f8fcca Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Ahp5s_ShNDRNRLvysMsu8rSWWIg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] What is the judging criteria? (Was: H.264 patent licensing options) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2014 23:18:31 -0000 --20cf30334e254f865b0509f8fcca Content-Type: text/plain; charset=UTF-8 Will do. Thanks for the feedback :) --Richard On Thu, Dec 11, 2014 at 4:54 PM, cowwoc wrote: > Hi Richard, > > Please try to emphasize this fact (what is acceptable vs what is not) the > next time you close a thread. I agree with your position, but I was not > aware of what you meant until now. > > Thanks, > Gili > > > On 11/12/2014 3:51 PM, Richard Barnes wrote: > > Hi Gili, > > Fair question. Keep in mind that the context here is Sean's message of > December 5, which was to confirm the consensus in the room at the IETF > meeting. He noted three objections that were discussed in the room, > including one about IPR. He sought to confirm consensus on the list, and > asked that anyone raise any other, additional issues by December 19. > > Appropriate responses to his message would include: people who were in > the room re-stating their positions, people who were not in the room > stating positions, and people raising issues that were not in his issue > list. > > That said, it is important that all relevant facts be on the table. So > participants should feel free to point out direct, factual things about the > options, technical or not. However, any discussion or *analysis* of those > facts, however, has to be off the table. For example, "X open-source > project is available under Y license" is OK, but "Y license doesn't allow Z > use" is not. > > Obviously, participants are welcome to come to their positions by > whatever means they choose. Participants may consider technical > characteristics, IPR terms, legal issues, or anything else. However, this > working group is chartered to develop technical solutions, and the > expertise on this list is technical. So I am precluding discussion of > non-technical matters in this forum. > > Thanks, > --Richard > > > On Thu, Dec 11, 2014 at 2:39 PM, cowwoc wrote: > >> Richard, >> >> I don't want to start a flamewar but I don't get the IETF's reasoning on >> this matter. >> >> Is the IETF planning to pick one or more MTI codecs based purely on >> technical merits? Or are they taking other matters (such as licensing) >> into consideration? >> >> If you are judging based purely on technical merits, why are we >> entertaining this "compromise" proposal? I thought we had agreed long ago >> that both codecs were more or less equivalent from a technical merit point >> of view. >> >> If you are not judging purely based on technical merits, why are we not >> allowed to debate matters that are part of the judging criteria? >> >> Gili >> >> On 11/12/2014 1:53 PM, Richard Barnes wrote: >> >>> Just to clarify: The above messages closing the thread were with my RAI >>> AD hat on, so as a matter of IETF process. >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > --20cf30334e254f865b0509f8fcca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Will do.=C2=A0 Thanks for the feedback :)

--Richard

On Thu, Dec 11, 2014 at 4:54 PM, cowwoc <cowwoc@bbs.darktech.= org> wrote:
=20 =20 =20
Hi Richard,

Please try to emphasize this fact (what is acceptable vs what is not) the next time you close a thread. I agree with your position, but I was not aware of what you meant until now.

Thanks,
Gili


On 11/12/2014 3:51 PM, Richard Barnes wrote:
Hi Gili,

Fair question.=C2=A0 Keep in mind that the context here is Sean's message of December 5, which was to confirm the consensus in the room at the IETF meeting.=C2=A0 He noted three objections that were discussed in the room, including one about IPR. He sought to confirm consensus on the list, and asked that anyone raise any other, additional issues by December 19.

Appropriate responses to his message would include: people who were in the room re-stating their positions, people who were not in the room stating positions, and people raising issues that were not in his issue list.

That said, it is important that all relevant facts be on the table.=C2=A0 So participants should feel free to point out direct, factual things about the options, technical or not.=C2= =A0 However, any discussion or *analysis* of those facts, however, has to be off the table.=C2=A0 For example, "X open-source project is available under Y license" is OK, b= ut "Y license doesn't allow Z use" is not.

Obviously, participants are welcome to come to their positions by whatever means they choose.=C2=A0 Participants may consider technical characteristics, IPR terms, legal issues, or anything else.=C2=A0 However, this working group is chartere= d to develop technical solutions, and the expertise on this list is technical.=C2=A0 So I am precluding discussion of non-technical matters in this forum.

Thanks,
--Richard


On Thu, Dec 11, 2014 at 2:39 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
Richard,

I don't want to start a flamewar but I don't get the IETF's reasoning on this matter.

Is the IETF planning to pick one or more MTI codecs based purely on technical merits?=C2=A0 Or are they taking other matters (such as licensing) into consideration?

If you are judging based purely on technical merits, why are we entertaining this "compromise" proposal? I t= hought we had agreed long ago that both codecs were more or less equivalent from a technical merit point of view.

If you are not judging purely based on technical merits, why are we not allowed to debate matters that are part of the judging criteria?

Gili

On 11/12/2014 1:53 PM, Richard Barnes wrote:
Just to clarify: The above messages closing the thread were with my RAI AD hat on, so as a matter of IETF process.

_______________________________________________
rtcweb mailing list
rtcweb@i= etf.org
https://www.ietf.org/mailman/listinfo/rtcweb



--20cf30334e254f865b0509f8fcca-- From nobody Fri Dec 12 02:45:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F2F1ACCEA for ; Fri, 12 Dec 2014 02:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.79 X-Spam-Level: * X-Spam-Status: No, score=1.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, TVD_FROM_1=0.999, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BSTQvizSi5T for ; Fri, 12 Dec 2014 02:45:41 -0800 (PST) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 459161ACCDC for ; Fri, 12 Dec 2014 02:45:41 -0800 (PST) Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id sBCAjdRZ071100 for ; Fri, 12 Dec 2014 02:45:40 -0800 (PST) (envelope-from finlayson@live555.com) From: Ross Finlayson Content-Type: multipart/alternative; boundary="Apple-Mail=_C7CB574F-01AB-45A3-8545-3FD63B24676D" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Date: Fri, 12 Dec 2014 23:45:39 +1300 References: <5485CC5B.2030104@alvestrand.no> To: rtcweb@ietf.org In-Reply-To: <5485CC5B.2030104@alvestrand.no> X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wc5hghTWK0lDErTtVBAKpgaSFnI Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 10:45:42 -0000 --Apple-Mail=_C7CB574F-01AB-45A3-8545-3FD63B24676D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I also support the rough consensus reached by those of us in the room in = Honolulu. It has been said that =93a good compromise is one in which all parties = are unhappy=94. By that measure, this is most definitely a good = compromise :-) I think that just about everybody is unhappy about at least some aspect = of this compromise. (For example, as I noted at the microphone in = Honolulu, I dislike the fact that making two codecs MTI in browsers for = perpetuity - and with the likelihood that at least one of these codecs = will be somewhat encumbered for at least the near future - may dampen = the possibility of a flourishing ecosystem emerging in the browser = space. But I understand why many others feel that this requirement on = browsers is necessary.) So yes, we=92re all a bit unhappy, but I haven=92t seen any sign - in = any of the recent postings on this mailing list - of an alternative = compromise that is likely to gain close to the same degree of consensus. = So, continuing to debate this ad nauseam does nothing but cause further = delay (which I'm sure nobody would want :-) It=92s time for us to collectively hold our noses, declare consensus on = this issue, and move forward. Ross Finlayson Live Networks, Inc. http://www.live555.com/ --Apple-Mail=_C7CB574F-01AB-45A3-8545-3FD63B24676D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I also support the rough consensus reached by those of = us in the room in Honolulu.

It has been said that =93a good compromise is one in which = all parties are unhappy=94.  By that measure, this is most = definitely a good compromise :-)

I think that just about everybody is = unhappy about at least some aspect of this compromise.  (For = example, as I noted at the microphone in Honolulu, I dislike the fact = that making two codecs MTI in browsers for perpetuity - and with the = likelihood that at least one of these codecs will be somewhat encumbered = for at least the near future - may dampen the possibility of a = flourishing ecosystem emerging in the browser space.  But I = understand why many others feel that this requirement on browsers is = necessary.)

So = yes, we=92re all a bit unhappy, but I haven=92t seen any sign - in any = of the recent postings on this mailing list - of an alternative = compromise that is likely to gain close to the same degree of consensus. =  So, continuing to debate this ad nauseam does nothing but cause = further delay (which I'm sure nobody would want :-)

It=92s time for us to = collectively hold our noses, declare consensus on this issue, and move = forward.

Ross Finlayson
Live= Networks, Inc.
http://www.live555.com/

= --Apple-Mail=_C7CB574F-01AB-45A3-8545-3FD63B24676D-- From nobody Fri Dec 12 03:14:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2941A8725 for ; Fri, 12 Dec 2014 03:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUNhwY89mpRY for ; Fri, 12 Dec 2014 03:14:45 -0800 (PST) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F101A1AF2 for ; Fri, 12 Dec 2014 03:14:45 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id w7so5362698qcr.14 for ; Fri, 12 Dec 2014 03:14:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=OLVlzFccTwAq+KxTURULI90M9dydas76HxeiTIvYFk8=; b=hpC3HCG6JB7fBp069OoatktJ++MPdYgnjKEnRUZSuUOhRN+zdVKQfPLgtVzHPku86U Lpb4Zm8I2Jl5NYoVEnc3jtSBmmrKWfKJSDzDukpxX4QNWaqmhZDyT9WekdnQgH+fcTAv AY2mHRsciftlvjUN+xa59AQMSdVPWP5Atkv+u1nQr7emDOjiL/hbqT6UsnPsCancaDMV lEONl4jbUpjOga3VVFWPFJgWLkM6CSYy+vCbRr0NFIcsmLN+g/ogqicswehlJSWi2/bT mcuIMplClOS28lFaFO3XEIJBfD8KK4dkQu7zqUFFBTecSvNEdvuo1puvgaKaVxY3PTg0 fciw== X-Gm-Message-State: ALoCoQnZFEjsardAvxhOnaNECPyJbxrvZtUqTp3+koo8q0ljKpMjHHuDKJ34d/olwdxYn+ZqSrxR X-Received: by 10.140.92.215 with SMTP id b81mr28541546qge.5.1418382884882; Fri, 12 Dec 2014 03:14:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Fri, 12 Dec 2014 03:14:23 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 12 Dec 2014 12:14:23 +0100 Message-ID: To: Sean Turner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hJg04ehsmBQ-NJMNlc7htZaOVs4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 11:14:47 -0000 Question: If the World gets a new "Opus for video" codec, will this WG make it MTI for WebRTC at the same time it removes both VP8 and H264 from the list of MTI codecs? --=20 I=C3=B1aki Baz Castillo From nobody Fri Dec 12 03:32:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A811ACD0A for ; Fri, 12 Dec 2014 03:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDlUkfk0ejg3 for ; Fri, 12 Dec 2014 03:32:43 -0800 (PST) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 40D0F1ACD09 for ; Fri, 12 Dec 2014 03:32:42 -0800 (PST) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id BD77032E586; Fri, 12 Dec 2014 20:31:57 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 588c_a61b_1e7adda8_59ad_4a6c_a6c0_eb0020ce6333; Fri, 12 Dec 2014 20:31:57 +0900 Received: from [133.2.210.64] (unknown [133.2.210.64]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id D214BBF509; Fri, 12 Dec 2014 20:31:56 +0900 (JST) Message-ID: <548AD22D.7040104@it.aoyama.ac.jp> Date: Fri, 12 Dec 2014 20:31:57 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Sean Turner References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/oNaxJ_57GZnNhVAcjooVLAVRt5I Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 11:32:45 -0000 On 2014/12/12 20:14, I=C3=B1aki Baz Castillo wrote: > Question: If the World gets a new "Opus for video" codec, will this WG > make it MTI for WebRTC at the same time it removes both VP8 and H264 > from the list of MTI codecs? 1) This is a good question. I wish I knew :-). 2) This is conditional on a hypothetical event in the future ("Opus for=20 video"). At that point, this WG may no longer exist. Or it may do=20 whatever it pleases (as long as it is within its charter). 3) Even if VP8 and H264 are removed from the list of MIT codecs in a=20 future spec, implementations still may need them for quite a while to be=20 backwards compatible with other not yet updated implementations and old=20 content. Just my 3=C2=A2. Regards, Martin. From nobody Fri Dec 12 06:19:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B6E1A0004 for ; Fri, 12 Dec 2014 06:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmoscaQXofUY for ; Fri, 12 Dec 2014 06:19:04 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3091A86FA for ; Fri, 12 Dec 2014 06:19:03 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 9188E23F051E; Fri, 12 Dec 2014 15:19:02 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.192]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 15:19:02 +0100 From: "Hutton, Andrew" To: Victor Pascual , Varun Singh Thread-Topic: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways Thread-Index: AQHQFNN6SVHVOj3UYUSe8yR2iFzK7ZyMAzqQ Date: Fri, 12 Dec 2014 14:19:01 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E63DA20@MCHP04MSX.global-ad.net> References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> <5481672E.4080305@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF1E63DA20MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Tl2XKxOPEJFXZFBja-6HJGU_1Mk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 14:19:10 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF1E63DA20MCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KSSBoYXZlIHJlYWQgdGhpcyBhbmQgdGhpbmsgaXQgaXMgdXNlZnVsIHRvIGhhdmUgdGhl cmVmb3JlIHN1cHBvcnQgdGhlIGFkb3B0aW9uLg0KDQpBbmR5DQoNCkZyb206IHJ0Y3dlYiBbbWFp bHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVmljdG9yIFBhc2N1YWwN ClNlbnQ6IDEwIERlY2VtYmVyIDIwMTQgMjM6NDYNClRvOiBWYXJ1biBTaW5naA0KQ2M6IHJ0Y3dl YkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIENhbGwgZm9yIGFkb3B0aW9uIG9mIGRy YWZ0LWFsdmVzdHJhbmQtcnRjd2ViLWdhdGV3YXlzDQoNCisxDQoNCk9uIERlYyA2LCAyMDE0LCBh dCA2OjAyIFBNLCBWYXJ1biBTaW5naCA8dnNpbmdoLmlldGZAZ21haWwuY29tPG1haWx0bzp2c2lu Z2guaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KQSkgWWVzLCBJIGhhdmUgcmVhZCB0aGUgZHJh ZnQgYW5kIEkgc3VwcG9ydCBhZG9wdGluZyBpdC4NCg0KVmFydW4uDQpPbiA1IERlYyAyMDE0IDEw OjA1LCAiSGFyYWxkIEFsdmVzdHJhbmQiIDxoYXJhbGRAYWx2ZXN0cmFuZC5ubzxtYWlsdG86aGFy YWxkQGFsdmVzdHJhbmQubm8+PiB3cm90ZToNCkp1c3QgdG8gZ2V0IHRoZSBiYWxsIHJvbGxpbmc6 DQoNCkEpIHllcywgZHJhZnQtYWx2ZXN0cmFuZC1ydGN3ZWItZ2F0ZXdheXMgc2hvdWxkIGJlIGFk b3B0ZWQgYXMgYSBXRyBkb2N1bWVudCBub3cuDQoNCk9uIDEyLzA0LzIwMTQgMDg6MjkgUE0sIEN1 bGxlbiBKZW5uaW5ncyAoZmx1ZmZ5KSB3cm90ZToNCkhhdmluZyByZXZpZXdlZCB0aGUgZmluZSB0 ZWNobmljYWwgY29tbWVudHMgb24gdGhpcyBkcmFmdCBzaW5jZSB3ZSBhc2tlZCBmb3IgY29tbWVu dHMsIHRoZSBjaGFpcnMgaGF2ZSBub3RlZCB0aGF0IG11bHRpcGxlIHBlb3BsZSBzZWVtIHRvIGhh dmUgcmVhZCB0aGUgZHJhZnQuIEdpdmVuIHRoaXMgZ3JlYXQgbmV3cyB3ZSBhcmUgZ29pbmcgbWFr ZSBhIGNhbGwgZm9yIGFkb3B0aW9uLg0KDQpJZiB5b3UgaGF2ZSBhbiBvcGluaW9uLCBwbGVhc2Ug ZW1haWwgdGhlIGxpc3QgYnkgRGVjIDE5IGFuZCBsZXQgdXMga25vdyBpZiB5b3UgZWl0aGVyOg0K DQpBKSB5ZXMsIGRyYWZ0LWFsdmVzdHJhbmQtcnRjd2ViLWdhdGV3YXlzIHNob3VsZCBiZSBhZG9w dGVkIGFzIGEgV0cgZG9jdW1lbnQgbm93DQoNCkIpIG5vLCBub3QgcmlnaHQgbm93DQoNCklmIHdl IGdldCBjb25zZW5zdXMgYXJvdW5kIEEgd2Ugd2lsbCB3b3JrIHdpdGggQURzIG9uIG1pbGVzdG9u ZS4gT3RoZXJ3aXNlIHdlIHdpbGwgZW5jb3VyYWdlIHRoZSBhdXRob3JzIHRvIGtlZXAgd29ya2lu ZyBvbiB0aGlzIGRyYWZ0IGFuZCBjb250aW51ZSB1c2luZyB0aGlzIGVtYWlsIGxpc3QuIFdlIG1h eSBhZG9wdCBpdCBsYXRlciBvciBpbmNsdWRlIHRoZSB0ZXh0IGluIG90aGVyIGRyYWZ0cy4NCg0K VGhhbmtzLA0KVGhlIENoYWlycyAoQ3VsbGVuLCBTZWFuLCBUZWQpDQoNClBTIC0gaWYgeW91IHdh bnQgdG8gc2VuZCBhbiBlbWFpbCB0aGF0IHNheXMgbW9yZSB0aGFuIEEgb3IgQiwgZmVlbCBmcmVl IHRvIGNoYW5nZSB0aGUgc3ViamVjdCwgc3RhcnQgYSBuZXcgdGhyZWFkIGV0Yy4NCg0KDQoNCg0K DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K cnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxp bmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dl YkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg== --_000_9F33F40F6F2CD847824537F3C4E37DDF1E63DA20MCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+JiM0MzsxDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgaGF2ZSByZWFkIHRoaXMgYW5kIHRoaW5rIGl0 IGlzIHVzZWZ1bCB0byBoYXZlIHRoZXJlZm9yZSBzdXBwb3J0IHRoZSBhZG9wdGlvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRj d2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PlZpY3RvciBQYXNjdWFsPGJyPg0KPGI+U2VudDo8L2I+IDEwIERlY2VtYmVyIDIwMTQgMjM6NDY8 YnI+DQo8Yj5Ubzo8L2I+IFZhcnVuIFNpbmdoPGJyPg0KPGI+Q2M6PC9iPiBydGN3ZWJAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIENhbGwgZm9yIGFkb3B0aW9uIG9m IGRyYWZ0LWFsdmVzdHJhbmQtcnRjd2ViLWdhdGV3YXlzPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48YnI+DQpPbiBEZWMgNiwgMjAxNCwgYXQgNjowMiBQTSwgVmFydW4gU2luZ2ggJmx0Ozxh IGhyZWY9Im1haWx0bzp2c2luZ2guaWV0ZkBnbWFpbC5jb20iPnZzaW5naC5pZXRmQGdtYWlsLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cD5BKSBZ ZXMsIEkgaGF2ZSByZWFkIHRoZSBkcmFmdCBhbmQgSSBzdXBwb3J0IGFkb3B0aW5nIGl0LiA8bzpw PjwvbzpwPjwvcD4NCjxwPlZhcnVuLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIDUgRGVjIDIwMTQgMTA6MDUsICZxdW90O0hhcmFsZCBBbHZlc3RyYW5kJnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm8iPmhhcmFsZEBhbHZl c3RyYW5kLm5vPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5KdXN0IHRvIGdldCB0aGUgYmFsbCByb2xsaW5nOjxicj4NCjxicj4NCkEpIHllcywgZHJh ZnQtYWx2ZXN0cmFuZC1ydGN3ZWItZ2F0ZXdheXMgc2hvdWxkIGJlIGFkb3B0ZWQgYXMgYSBXRyBk b2N1bWVudCBub3cuPGJyPg0KPGJyPg0KT24gMTIvMDQvMjAxNCAwODoyOSBQTSwgQ3VsbGVuIEpl bm5pbmdzIChmbHVmZnkpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGF2aW5nIHJldmlld2VkIHRoZSBmaW5lIHRlY2huaWNhbCBjb21tZW50cyBvbiB0aGlzIGRy YWZ0IHNpbmNlIHdlIGFza2VkIGZvciBjb21tZW50cywgdGhlIGNoYWlycyBoYXZlIG5vdGVkIHRo YXQgbXVsdGlwbGUgcGVvcGxlIHNlZW0gdG8gaGF2ZSByZWFkIHRoZSBkcmFmdC4gR2l2ZW4gdGhp cyBncmVhdCBuZXdzIHdlIGFyZSBnb2luZyBtYWtlIGEgY2FsbCBmb3IgYWRvcHRpb24uPGJyPg0K PGJyPg0KSWYgeW91IGhhdmUgYW4gb3BpbmlvbiwgcGxlYXNlIGVtYWlsIHRoZSBsaXN0IGJ5IERl YyAxOSBhbmQgbGV0IHVzIGtub3cgaWYgeW91IGVpdGhlcjo8YnI+DQo8YnI+DQpBKSB5ZXMsIGRy YWZ0LWFsdmVzdHJhbmQtcnRjd2ViLWdhdGV3YXlzIHNob3VsZCBiZSBhZG9wdGVkIGFzIGEgV0cg ZG9jdW1lbnQgbm93PGJyPg0KPGJyPg0KQikgbm8sIG5vdCByaWdodCBub3c8YnI+DQo8YnI+DQpJ ZiB3ZSBnZXQgY29uc2Vuc3VzIGFyb3VuZCBBIHdlIHdpbGwgd29yayB3aXRoIEFEcyBvbiBtaWxl c3RvbmUuIE90aGVyd2lzZSB3ZSB3aWxsIGVuY291cmFnZSB0aGUgYXV0aG9ycyB0byBrZWVwIHdv cmtpbmcgb24gdGhpcyBkcmFmdCBhbmQgY29udGludWUgdXNpbmcgdGhpcyBlbWFpbCBsaXN0LiBX ZSBtYXkgYWRvcHQgaXQgbGF0ZXIgb3IgaW5jbHVkZSB0aGUgdGV4dCBpbiBvdGhlciBkcmFmdHMu PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NClRoZSBDaGFpcnMgKEN1bGxlbiwgU2VhbiwgVGVkKTxi cj4NCjxicj4NClBTIC0gaWYgeW91IHdhbnQgdG8gc2VuZCBhbiBlbWFpbCB0aGF0IHNheXMgbW9y ZSB0aGFuIEEgb3IgQiwgZmVlbCBmcmVlIHRvIGNoYW5nZSB0aGUgc3ViamVjdCwgc3RhcnQgYSBu ZXcgdGhyZWFkIGV0Yy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRj d2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRjd2ViIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9F33F40F6F2CD847824537F3C4E37DDF1E63DA20MCHP04MSXglobal_-- From nobody Fri Dec 12 06:26:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBD51A878C for ; Fri, 12 Dec 2014 06:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ziIhGT_EDrm for ; Fri, 12 Dec 2014 06:26:38 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B3CE1A876F for ; Fri, 12 Dec 2014 06:26:36 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id rp18so7020688iec.11 for ; Fri, 12 Dec 2014 06:26:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AiBhx/MjdgFYcHtabOGeRMlP9LFa0B9E3d29E72KBv8=; b=JByg9Qcw8ABcYLK/c00gFMM92GjAJaKX6Dk8RNnjeyPmIa2QeO2E5y9Wr9dKMf4dNK zo+Pq28vAgW66AmGPb3IrYMmqxei4Towfxd8dFdIxmwV5ZxxVHEAH4g8/Yv3EWSnl9UU m2bE/PBfNvH5hLOpuN79yBX5YibQgxl4x//EC0cxMr60Dq1VLg7QUChU/ycHyJ1vnk/R owDSStbaM8RE7pV8UA0hdDVwwicjXUwifIfxC4FsQGou45iV04JRJaRhi8u1SRUaLEft S6SQ2Txf9ZTfVdRJYgs3QUovYJF/poUsiyXhXIHhL5GNyHLNHzzhdQv7OoXquob/sl83 R5Jw== X-Gm-Message-State: ALoCoQkwdlwArSDyDT/PmXYitio0Atq33RZVDwPfW/BFM2jlmFMM/V1iJRbfy9Le14Pe8VnFz2NU X-Received: by 10.42.251.68 with SMTP id mr4mr16398289icb.94.1418394395782; Fri, 12 Dec 2014 06:26:35 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id a68sm697706ioe.18.2014.12.12.06.26.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Dec 2014 06:26:35 -0800 (PST) Message-ID: <548AFB1A.1040405@andyet.net> Date: Fri, 12 Dec 2014 07:26:34 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Sean Turner References: <548AD22D.7040104@it.aoyama.ac.jp> In-Reply-To: <548AD22D.7040104@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/yZimps_-Wu8kuv-8gMUFDBk5sW0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 14:26:40 -0000 On 12/12/14, 4:31 AM, "Martin J. Dürst" wrote: > On 2014/12/12 20:14, Iñaki Baz Castillo wrote: >> Question: If the World gets a new "Opus for video" codec, will this WG >> make it MTI for WebRTC at the same time it removes both VP8 and H264 >> from the list of MTI codecs? > > 1) This is a good question. I wish I knew :-). > > 2) This is conditional on a hypothetical event in the future ("Opus for > video"). At that point, this WG may no longer exist. Or it may do > whatever it pleases (as long as it is within its charter). Sure, but that can all happen through normal IETF processes (form a new WG, write an I-D that obsoletes this dual-MTI solution, etc.). IMHO it would still be good to address some aspects of the various possible scenarios that I mentioned here: http://www.ietf.org/mail-archive/web/rtcweb/current/msg13754.html I have it on my to-do list to draft some text. Peter -- Peter Saint-Andre CTO @ &yet https://andyet.com/ From nobody Fri Dec 12 06:45:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEC61ACD8D for ; Fri, 12 Dec 2014 06:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUwk_uy_W4NP for ; Fri, 12 Dec 2014 06:45:21 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59201ACD1A for ; Fri, 12 Dec 2014 06:45:21 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBCEjALO025034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2014 08:45:11 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <548AFF76.1010003@nostrum.com> Date: Fri, 12 Dec 2014 08:45:10 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , =?UTF-8?B?Ik1hcnRpbiBKLiA=?= =?UTF-8?B?RMO8cnN0Ig==?= , =?UTF-8?B?ScOxYWtpIEJh?= =?UTF-8?B?eiBDYXN0aWxsbw==?= , Sean Turner References: <548AD22D.7040104@it.aoyama.ac.jp> <548AFB1A.1040405@andyet.net> In-Reply-To: <548AFB1A.1040405@andyet.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/u7YaNJarl3ac7kqUGVeiuz4sKfU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 14:45:26 -0000 On 12/12/14 08:26, Peter Saint-Andre - &yet wrote: > On 12/12/14, 4:31 AM, "Martin J. Dürst" wrote: >> On 2014/12/12 20:14, Iñaki Baz Castillo wrote: >>> Question: If the World gets a new "Opus for video" codec, will this WG >>> make it MTI for WebRTC at the same time it removes both VP8 and H264 >>> from the list of MTI codecs? >> >> 1) This is a good question. I wish I knew :-). >> >> 2) This is conditional on a hypothetical event in the future ("Opus for >> video"). At that point, this WG may no longer exist. Or it may do >> whatever it pleases (as long as it is within its charter). > > Sure, but that can all happen through normal IETF processes (form a > new WG, write an I-D that obsoletes this dual-MTI solution, etc.). > > IMHO it would still be good to address some aspects of the various > possible scenarios... I think that the future-looking clause is one of the wartiest parts of this proposal. On the other hand, it's the one thing that makes it different than things we've considered in the past, and is clearly a key part of what allowed it to gather the support that it has so far. So: ugly, necessary, and sufficient. Given that it's sufficient to gain the current level of support, the need for change is unclear. Given that it's necessary, we can't remove it, or the whole thing falls apart. And, given that it's ugly, making it more expansive would only make the proposal qualitatively worse. There's no point trying to map out large decision trees for the future, especially since we've had such a contentious time coming to some semblance of agreement on the current direction. Pushing more future-looking decisions into the text would only serve to give us more things to disagree about. And, as you point out, if something comes up in the future that materially changes the landscape, it's completely within the purview of the IETF to apply rational analysis to make a decision based on the actual facts at that time. /a From nobody Fri Dec 12 06:58:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1131ACD9B for ; Fri, 12 Dec 2014 06:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYy3cILW91EZ for ; Fri, 12 Dec 2014 06:58:01 -0800 (PST) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6261ACD8C for ; Fri, 12 Dec 2014 06:58:01 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id f12so5315006qad.28 for ; Fri, 12 Dec 2014 06:58:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=DDGdcrRqatXFdSAQUmONxR6IvJ97kvEFkMJ5cxDhzOc=; b=BEDm9VNykWku9wkr+lxOYdYTPOiMTWEUjMnrnGx/xObuF8rgsczjLiwUBjudB94g5C eqdwGN0WYN7pq17ZvAFWzQP63UUj03dzLw4JEhR6vL1hEuGpAyG9rP+a/n9O+zz8Lbdn NFpmemYAyv6nl0FKg5aSv49x7QcLRdMiHf2iROm08qiCJA4W/vvb7WuS1HFI3So7oRyy kR572NRHZqAzvgNYRTl+icNwzXwvjjk86kA9rktiWxivK9UuMoxoCQQMq6n34uR+HrwL R+lHj83JTXTCI5ufxx1nZXrqNFOFud8/z9OkG1wq1k21/PLEArqVtYymNCHDO9n+wxmW PUUQ== X-Gm-Message-State: ALoCoQnJH/f9Nux8zW0TX5ugifJmT1LZj2Etp4KaPWAcsDQzv7oFX7HrAXzj4jxlrWtIrlNgZRgw X-Received: by 10.140.102.13 with SMTP id v13mr11817345qge.68.1418396280359; Fri, 12 Dec 2014 06:58:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Fri, 12 Dec 2014 06:57:40 -0800 (PST) In-Reply-To: <548AFF76.1010003@nostrum.com> References: <548AD22D.7040104@it.aoyama.ac.jp> <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 12 Dec 2014 15:57:40 +0100 Message-ID: To: Adam Roach Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Ymo6mIhUicw3EwkMVdSwuEI2vUo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 14:58:03 -0000 2014-12-12 15:45 GMT+01:00 Adam Roach : > I think that the future-looking clause is one of the wartiest parts of th= is > proposal. On the other hand, it's the one thing that makes it different t= han > things we've considered in the past, and is clearly a key part of what > allowed it to gather the support that it has so far. So: ugly, necessary, > and sufficient. > > Given that it's sufficient to gain the current level of support, the need > for change is unclear. > > Given that it's necessary, we can't remove it, or the whole thing falls > apart. > > And, given that it's ugly, making it more expansive would only make the > proposal qualitatively worse. > > There's no point trying to map out large decision trees for the future, > especially since we've had such a contentious time coming to some semblan= ce > of agreement on the current direction. Pushing more future-looking decisi= ons > into the text would only serve to give us more things to disagree about. > > And, as you point out, if something comes up in the future that materiall= y > changes the landscape, it's completely within the purview of the IETF to > apply rational analysis to make a decision based on the actual facts at t= hat > time. That would sound really nice if the already chosen MTI codecs were 100% RF with no licensing/patent issues. That's not the case so IMHO the door should remain open for, at least, the inclusion of a new 100% RF video codec. --=20 I=C3=B1aki Baz Castillo From nobody Fri Dec 12 07:06:51 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932CB1A8FD3 for ; Fri, 12 Dec 2014 07:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4z911Gj1tUS0 for ; Fri, 12 Dec 2014 07:06:48 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022FA1A8F4E for ; Fri, 12 Dec 2014 07:06:47 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBCF6dZP028687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2014 09:06:40 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <548B047F.9090704@nostrum.com> Date: Fri, 12 Dec 2014 09:06:39 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <548AD22D.7040104@it.aoyama.ac.jp> <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/g336zJZmAKNCT0MVjS98kEBGO3o Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 15:06:48 -0000 On 12/12/14 08:57, Iñaki Baz Castillo wrote: > IMHO the door should remain open for, at least, the inclusion of a new 100% RF video codec. Then you already have what you want: there's no way we could close that door, no matter how hard we tried. /a From nobody Fri Dec 12 07:28:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C581A6FF3 for ; Fri, 12 Dec 2014 07:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C29tAn_vnJAu for ; Fri, 12 Dec 2014 07:28:03 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 4511A1A8932 for ; Fri, 12 Dec 2014 07:28:03 -0800 (PST) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Dec 2014 10:27:58 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0210.002; Fri, 12 Dec 2014 10:27:58 -0500 From: Gaelle Martin-Cocher To: "Mo Zanaty (mzanaty)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEJCKBITgiQUj50CzzuygMU2TV5yGgaCAgAWZ93A= Date: Fri, 12 Dec 2014 15:27:57 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF360327@XMB111CNC.rim.net> References: In-Reply-To: Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IcC13YeJUUWZiumK30Uvy-jekKQ Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 15:28:05 -0000 Multiple codecs can be supported even if there is only a single MTI defined= in WebRTC.=20 This has been confirmed by those who will implement scalable codecs. I am not aware of anyone asking for removing the codec negotiation/capabili= ty discovery even if there is a single MTI.=20 As such supporting multiple codecs is independent from the MTI discussion. The question is not do we need multiple codecs but do we need multiple MTIs= (and which).=20 Ga=EBlle -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Mo Zanaty (mzana= ty) Sent: Monday, December 08, 2014 3:42 PM To: Sean Turner; rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec To reiterate another point from the meeting, there are technical advantages= to supporting multiple codecs. Dynamic discovery of local capabilities, ne= gotiation of remote capabilities, understanding how different error resilie= nce mechanisms can work (or not) with different codecs, faster adoption of = new (non-mandatory) codecs, easier path to deprecating old (mandatory) code= cs, etc. All those legs never get exercised effectively in single-codec imp= lementations, leaving land mines in browsers, apps, services and sometimes = even specs. They become easier or free once the groundwork is laid for mult= iple codecs. While some have argued against that extra complexity, I see it= as essential for any important standard. Mo From nobody Fri Dec 12 07:52:07 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4ED91ACE32 for ; Fri, 12 Dec 2014 07:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYHW-XI1VicQ for ; Fri, 12 Dec 2014 07:52:03 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF3B1ACE38 for ; Fri, 12 Dec 2014 07:51:57 -0800 (PST) Received: from [172.17.0.43] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 652B0F2A06 for ; Fri, 12 Dec 2014 07:51:56 -0800 (PST) Message-ID: <548B0F1B.3090009@mozilla.com> Date: Fri, 12 Dec 2014 07:51:55 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: rtcweb@ietf.org References: <5485CC5B.2030104@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jgiG9E0PbStWBZvu6VUtZAq2Na8 Subject: Re: [rtcweb] Unhappy People (was: confirming sense of the room: mti codec) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 15:52:05 -0000 Ross Finlayson wrote: > I think that just about everybody is unhappy about at least some aspect > of this compromise. (For example, as I noted at the microphone in Yes. From reading the comments in this discussion, it seems to me many people are unhappy with many _different_ aspects of the proposal. However, there's no one aspect that everyone universally agrees is bad [1]. I include myself among those unhappy people, despite my overall support for the proposal. [1] The one possible exception is the term "WebRTC-compatible" to describe a thing that doesn't obey the WebRTC specs, but as Christer pointed out, that's not an issue with the proposal, that's an issue with draft-ietf-rtcweb-overview. From nobody Fri Dec 12 08:33:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F251ACEB0 for ; Fri, 12 Dec 2014 08:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avqo_5mb3rkn for ; Fri, 12 Dec 2014 08:33:05 -0800 (PST) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537781ACE61 for ; Fri, 12 Dec 2014 08:33:05 -0800 (PST) Received: by mail-qg0-f41.google.com with SMTP id j5so5736443qga.28 for ; Fri, 12 Dec 2014 08:33:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Xv0eKLDbUPJNaQv6pJ871sil6mZSlR6ybWGecVGOsNY=; b=lSFsytVeQkkEVZ+qPVnHevz4e2n2RRyzscMmNouqFXJXThkutLTKz+fYwiHwfUGjsC p0MDu8F3anK7Jb3kyGoPLaNd2EvY0BzSw8csI9a8PGfBGS4Msdo/o3dyLedLhGQmGWRT 7u0N3TXD6JYlos+qMlCFzXBh/AFnMjRn8m13UQ7HOioK8qX5fn3Bq5ED0O8WdqAIESF4 jo+ta4fRq3P+DM0bbutH6hjRYd/Ye1N78alhCueaLyQmb3MCxzUHlub8JgUzD1YjlSL3 ROMG2Vs/D7H03f6xCmGLIRXNPJahBpEfNiI4Cqw6xE2w2SmRdJ+hj9gGvO3Tw9Wyh7ef 6bdw== X-Gm-Message-State: ALoCoQn5t39iLN5NsJeceieUXCgnZrGJ7mFm+pFjbsuVL3+6sRxJgaEJcI+i89ZQF3Dpw7jG44eo X-Received: by 10.224.65.134 with SMTP id j6mr32232103qai.90.1418401984356; Fri, 12 Dec 2014 08:33:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Fri, 12 Dec 2014 08:32:44 -0800 (PST) In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF360327@XMB111CNC.rim.net> References: <92D0D52F3A63344CA478CF12DB0648AADF360327@XMB111CNC.rim.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 12 Dec 2014 17:32:44 +0100 Message-ID: To: Gaelle Martin-Cocher Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sMbMQ4MGxqnctKEJTmG2dus899I Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 16:33:07 -0000 2014-12-12 16:27 GMT+01:00 Gaelle Martin-Cocher : > The question is not do we need multiple codecs but do we need multiple MT= Is (and which). We need MTI codecs, but no patent/license polluted ones. That's the reason of my question. Will those non 100% RF video codecs be removed as MTI *if* a new 100% RF good video codec appeared? Will we have to deal with non RF MTI codecs forever? The arguments I'm reading in this thread about the no-need for more MTI codecs in the future could also be applied for the no-need of defining any MTI codec now. At the end we do have a "codec negotiation/capability discovery" mechanism, right? --=20 I=C3=B1aki Baz Castillo From nobody Fri Dec 12 08:48:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D38B1ACEF3 for ; Fri, 12 Dec 2014 08:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhUArkjsq5OK for ; Fri, 12 Dec 2014 08:48:07 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 8C59C1ACEE6 for ; Fri, 12 Dec 2014 08:48:07 -0800 (PST) Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Dec 2014 11:48:02 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.03.0210.002; Fri, 12 Dec 2014 11:48:01 -0500 From: Gaelle Martin-Cocher To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEJCKBITgiQUj50CzzuygMU2TV5yGgaCAgAWZ93CAAGmcAP//r21g Date: Fri, 12 Dec 2014 16:48:01 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF3604E9@XMB111CNC.rim.net> References: <92D0D52F3A63344CA478CF12DB0648AADF360327@XMB111CNC.rim.net> In-Reply-To: Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VHLZra5g9GxSplfWyt6y0zLiZBk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 16:48:08 -0000 VGhpcyBpcyBub3QgYXQgYWxsIHdoYXQgSSBpbXBsaWVkLg0KSSBiZWxpZXZlIHdlIHdpbGwgbmVl ZCBuZXcgY29kZWNzIGluIHRoZSBmdXR1cmUsIHNheSBvbmUgdGhhdCBwcm92aWRlIG1vcmUgY29t cHJlc3Npb25zLg0KV2lsbCB0aGF0IGhhdmUgdG8gYmUgbWFuZGF0b3J5IG9yIHJlY29tbWVuZGVk IGlzIFRCRC4NCg0KQXQgdGhlIHNhbWUgdGltZSwgaWYgd2UgaGF2ZSBhIG5ldyBjb2RlYyB3ZSBu ZWVkIHRvIGVuc3VyZSBsZWdhY3kgc3lzdGVtcyB3aWxsIGNvbnRpbnVlIHRvIHdvcmsuIA0KVGhp cyBpcyB0aGUgcmVhc29uIEkgZG8gbm90IGFncmVlIHdpdGggdGhlIG5vdGUgdW5kZXIgd2VicnRj LWNvbXBhdGlibGUgZW5kcG9pbnQgd2hpY2ggb25seSB0YWtlIGluIGFjY291bnQgUkYgYXNwZWN0 cy4NCkkgaGF2ZSBwcm9wb3NlZCB0aGF0IHRoZSBub3RlcyB0YWtlIFJGIGFzcGVjdHMgZm9yIFZQ OCBhbmQgdGFrZXMgbGVnYWN5IGFzcGVjdHMgZm9yIEguMjY0IGFzIHRoZXNlIGFyZSB0aGUgYXJn dW1lbnRzIHB1dCBmb3J3YXJkIGJ5IHJlc3BlY3RpdmUgcHJvcG9uZW50cy4NCg0KR2HDq2xsZQ0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxv IFttYWlsdG86aWJjQGFsaWF4Lm5ldF0gDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDEyLCAyMDE0 IDExOjMzIEFNDQpUbzogR2FlbGxlIE1hcnRpbi1Db2NoZXINCkNjOiBNbyBaYW5hdHkgKG16YW5h dHkpOyBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBjb25maXJtaW5nIHNl bnNlIG9mIHRoZSByb29tOiBtdGkgY29kZWMNCg0KMjAxNC0xMi0xMiAxNjoyNyBHTVQrMDE6MDAg R2FlbGxlIE1hcnRpbi1Db2NoZXIgPGdtYXJ0aW5jb2NoZXJAYmxhY2tiZXJyeS5jb20+Og0KPiBU aGUgcXVlc3Rpb24gaXMgbm90IGRvIHdlIG5lZWQgbXVsdGlwbGUgY29kZWNzIGJ1dCBkbyB3ZSBu ZWVkIG11bHRpcGxlIE1USXMgKGFuZCB3aGljaCkuDQoNCldlIG5lZWQgTVRJIGNvZGVjcywgYnV0 IG5vIHBhdGVudC9saWNlbnNlIHBvbGx1dGVkIG9uZXMuIFRoYXQncyB0aGUgcmVhc29uIG9mIG15 IHF1ZXN0aW9uLiBXaWxsIHRob3NlIG5vbiAxMDAlIFJGIHZpZGVvIGNvZGVjcyBiZSByZW1vdmVk IGFzIE1USSAqaWYqIGEgbmV3IDEwMCUgUkYgZ29vZCB2aWRlbyBjb2RlYyBhcHBlYXJlZD8gV2ls bCB3ZSBoYXZlIHRvIGRlYWwgd2l0aCBub24gUkYgTVRJIGNvZGVjcyBmb3JldmVyPw0KDQpUaGUg YXJndW1lbnRzIEknbSByZWFkaW5nIGluIHRoaXMgdGhyZWFkIGFib3V0IHRoZSBuby1uZWVkIGZv ciBtb3JlIE1USSBjb2RlY3MgaW4gdGhlIGZ1dHVyZSBjb3VsZCBhbHNvIGJlIGFwcGxpZWQgZm9y IHRoZSBuby1uZWVkIG9mIGRlZmluaW5nIGFueSBNVEkgY29kZWMgbm93LiBBdCB0aGUgZW5kIHdl IGRvIGhhdmUgYSAiY29kZWMgbmVnb3RpYXRpb24vY2FwYWJpbGl0eSBkaXNjb3ZlcnkiIG1lY2hh bmlzbSwgcmlnaHQ/DQoNCg0KLS0NCknDsWFraSBCYXogQ2FzdGlsbG8NCjxpYmNAYWxpYXgubmV0 Pg0K From nobody Fri Dec 12 09:34:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91AC1A6FB5 for ; Fri, 12 Dec 2014 09:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7PjqZMCWEfE for ; Fri, 12 Dec 2014 09:34:18 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0131A1BBF for ; Fri, 12 Dec 2014 09:34:18 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id DDEA3C94BD; Fri, 12 Dec 2014 12:34:15 -0500 (EST) Date: Fri, 12 Dec 2014 12:34:15 -0500 From: John Leslie To: Peter Saint-Andre - &yet Message-ID: <20141212173415.GH47023@verdi> References: <547511DB.5050100@nostrum.com> <547FC4FD.2050300@andyet.net> <20141204150041.GI10449@hex.shelbyville.oz> <54808198.7030207@andyet.net> <54808719.10402@nostrum.com> <5483B818.7050102@andyet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5483B818.7050102@andyet.net> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/O-R5fwtzsoT75ZWDDxeHzhskaVM Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 17:34:21 -0000 On Sat, 06 Dec 2014, Peter Saint-Andre - &yet wrote: > On 12/4/14, 9:08 AM, Adam Roach wrote: >> On 12/4/14 07:45, Peter Saint-Andre - &yet wrote: >>> On 12/4/14, 8:00 AM, Ron wrote: >>>> On Wed, Dec 03, 2014 at 07:20:45PM -0700, Peter Saint-Andre - &yet >>>> wrote: >>>>> >>>>> IMHO we need to either pull out the future-oriented text entirely >>>>> (which has its own problems) or significantly improve it. I would >>>>> be happy to propose text for the latter. I share Peter's concern: but not knowing what text is proposed, I'm not ready to respond to specifics. Generally, we _cannot_ bind any future WG; and we _must_ avoid making a WG statement about the validity of any IPR claims... [Ron@debian responded:] >>>> I'd definitely be interested in seeing proposals from you to improve >>>> upon these things. It seemed premature to explore this until we had >>>> some sense of whether this kind of compromise could fly at all, but >>>> now that it seems it can, I think these are important details for us >>>> to clarify as best we can. >>> >>> OK, I'll get to work. :-) [Adam Roach responded:] >> Awesome, thanks. I've always found your prose to be clearer and easier >> to read than mine anyway. :) >> >> When you draft your text, keep in mind that what we're trying to do is >> capture the essence of the agreement that we've formed a critical mass >> around. The less formal (i.e., not really document-ready) version of >> this is: ============================== Adam's text ============================== >>> "WebRTC devices MUST implement both VP8 and H.264. If compelling >>> evidence arises that one of the codecs is available for use on a >>> royalty-free basis, such as all IPR declarations known for the codec >>> being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change >>> this normative statement to indicate that only that codec is required. >>> For absolute, crystal clarity, this provision is only applicable to >>> WebRTC devices, and not to WebRTC User Agents." ============================== Adam's text ============================== >> >> There's nuance to be added there, for sure, but I'd encourage you not to >> color way outside those lines. Expanding scope to discuss issues such as >> *other* circumstances that may cause revisiting the MTI, for example, >> are far more likely to weaken consensus than they are to strengthen it. (I don't know whether this is the text which Hawaii hummed for.) Actually, I have less problems with this text than with other versions I have seen. It lists a specific condition of IPR declarations which is not subject to on-list arguments (which is acceptable), but goes beyond that with "such as" (which I find worrysome). Obviously, the condition it listed is wildly improbable except for the "such as" language (which would enable on-list arguments). Further, the pretense that this document could bind a future WG is ridiculous. [Peter responded to Adam:] > I see two kinds of triggers: > > 1. A trigger that is specific to the alternatives we have been presented > so far. That is: only H.264 or VP8 (or both) can be MTI. If we learn > that one of them can be used royalty-free, then that codec will be the > only MTI codec. > > Questions: > > 1a. Does this trigger fire as soon as one codec is learned to be usable > royalty-free? So this is a first-past-the-post contest? (Let's say codec > "c1" is learned to be usable RF and the next week or month or quarter > "c2" is learned to be usable RF. What happens?) > > 1b. Text along the lines of "the IETF will change this normative > statement" does not make it clear how that will happen. Is there an > automatic trigger (i.e., it's built into this document)? Or does the > IETF need to do something (e.g., publish an RFC that obsoletes this one)? > > (There is some interaction between 1a and 1b. If some process is needed > to declare "c1" the only MTI, then it's possible that we might learn > that "c2" can also be used RF before the obsoleting RFC can be published.) Peter is not being difficult here: no process is specified for the IETF to "change this normative statement", and it could take many months to do so. > 2. A trigger that is more general and future-proof. That is: someday > (perhaps before too much longer on the standardization timescale) we > will have other alternatives to consider: H.265, VP9, VP10, Daala, and > who knows what. (I'd be amazed if we didn't have at least one of these ready to use before this document is published as an RFC.) > Another question: > > 2a. There is some interaction between 1b and 2. Let's say it takes us 10 > years to learn that "c1" can be used RF. Hurray! But by that time, we > might have "c3" and "c4" and "c5" to consider. Are we forbidden from > considering anything but "c1" and "c2" at that time? Peter _is_ being difficult here: obviously nothing we could do would bind us or any other WG that tightly. > I *think* that the trigger you're talking about is #1. Personally I am > much more interested in #2 because I don't think we'll really settle > this issue in the medium term or long term until we have the video > equivalent of Opus. IMHO, if we accept this text, we'll effectively bind future implementations to implement both H.264 and VP8 for many years to come. YMMV, of course... > Because I think we're talking about different triggers for different > purposes, my impression is that the text we have in mind would differ > significantly (in particular, I feel no compulsion to "stay within the > lines" because I think those lines are not useful, and indeed are > positively harmful, in the long term). +1 -- John Leslie From nobody Fri Dec 12 09:54:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2831ACEC2 for ; Fri, 12 Dec 2014 09:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEojZ8SEUoED for ; Fri, 12 Dec 2014 09:54:41 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8B41A7029 for ; Fri, 12 Dec 2014 09:54:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3040; q=dns/txt; s=iport; t=1418406881; x=1419616481; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=LGHTLrvqJ4Bo1LJ5IlUjhcpocKCSA9Y4TYJtzMozQ1c=; b=GZOH0SWYh7Koz0rNJ3e2cO2mk3/vdSZKCLzltWI6/aSdpL0Rw+xK4HG/ 1HO7ehq7MAALlZZXwn3gCh9Ux9L6ueS6VWkzOgft0Py7kYk3Z7w5cYjqa MTopoJamrn7cfud1Elm9RywBUDBhRFPdZRi1kNjbTio2GqvVEPDt5I9P3 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFAEkri1StJV2Z/2dsb2JhbABZgwZSWATFc4V2AoEWFgEBAQEBfYQMAQEBBIEFBAIBCBEEAQEoBzIUCQgCBAESiCzYQgEBAQEBAQEBAQEBAQEBAQEBAQEBARePPzoGhCMBBIkThGyDPoUxgQswjESDOCKDbG6BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,565,1413244800"; d="scan'208";a="105239383" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 12 Dec 2014 17:54:40 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBCHseBg027730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Dec 2014 17:54:40 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.121]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 11:54:39 -0600 From: "Mo Zanaty (mzanaty)" To: Gaelle Martin-Cocher , "rtcweb@ietf.org" Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQFjSztNbhnJ5pX0SSlP6pLau9Tg== Date: Fri, 12 Dec 2014 17:54:39 +0000 Message-ID: References: <92D0D52F3A63344CA478CF12DB0648AADF360327@XMB111CNC.rim.net> In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF360327@XMB111CNC.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.150.30.52] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <004C0EADC8CF6245AB96879D5CFD6AAC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UIpYyGG3c77VJ6dW5oksjGEmmNg Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 17:54:42 -0000 Agreed, from the viewpoint of specifications. But from the viewpoint of implementations, there is often quite a difference between the level of support when the spec says =B3can=B2 versus =B3MUST=B2. Mandatory codec agility is even more important than specific mandatory codecs, but it may take the latter to force the former. My comment was not based on hypothetical concerns or foresight. It was from direct experience trying to add H.264 into the webrtc.org codebase and Mozilla=B9s fork. The current support in Firefox barely meets the bar o= f shippable, and webrtc.org support is not shippable at all. (I think your Blackberry colleagues who also started down this path can corroborate this.) There are still many holes, and lots of refactoring is still in progress to have a truly robust multi-codec media engine where resilience and other aspects are harmonized for all codecs. The end result will be a platform that can more easily and rapidly handle VP9, H.265, Daala, netvc, etc. without lots of additional refactoring or gaps in functionality across codecs. It does require extra effort, but I see it as essential investment that should not be deferred. Actually implementing multiple codecs can also reveal gaps in specs. For example, I strongly support your argument for decoding many formats even if you can only encode one or a few. It is a good technical direction. But try to implement it with current standards, and you will hit some walls. Mo On 12/12/14, 10:27 AM, Gaelle Martin-Cocher wrote: Multiple codecs can be supported even if there is only a single MTI defined in WebRTC.=20 This has been confirmed by those who will implement scalable codecs. I am not aware of anyone asking for removing the codec negotiation/capability discovery even if there is a single MTI. As such supporting multiple codecs is independent from the MTI discussion. The question is not do we need multiple codecs but do we need multiple MTIs (and which).=20 Ga=EBlle -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Mo Zanaty (mzanaty) Sent: Monday, December 08, 2014 3:42 PM To: Sean Turner; rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec To reiterate another point from the meeting, there are technical advantages to supporting multiple codecs. Dynamic discovery of local capabilities, negotiation of remote capabilities, understanding how different error resilience mechanisms can work (or not) with different codecs, faster adoption of new (non-mandatory) codecs, easier path to deprecating old (mandatory) codecs, etc. All those legs never get exercised effectively in single-codec implementations, leaving land mines in browsers, apps, services and sometimes even specs. They become easier or free once the groundwork is laid for multiple codecs. While some have argued against that extra complexity, I see it as essential for any important standard. Mo From nobody Fri Dec 12 10:23:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D937B1A1EED for ; Fri, 12 Dec 2014 10:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evwJR9y3_-1T for ; Fri, 12 Dec 2014 10:23:50 -0800 (PST) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7856E1A7D80 for ; Fri, 12 Dec 2014 10:23:50 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id v10so5478202qac.21 for ; Fri, 12 Dec 2014 10:23:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=/lnL3OD5krGPaJXze+GnrGlPa0V+XhwLv0JCEx4Yg9M=; b=bRyIKPwc1ZWQqNUeo2popwHgWiyvTf+62QaCi34ql/a7IoYR2giaBGP30Ehlf98udw 538LAYY+7XBVBCsL6k17bswac/CULJG03on2qM6K0wtTIdCiJydooQyZyj+TkD1UlwoR 5LagVfmLD82fVoXpYYq5NQALLssy7W/6taJBYHpjTvLmOQRQF/EeTZQHsqVHVo3Ms6sn UsmAJR5pcUmU7Y1z9dwWxU3wDYwC14jtS8XgvBHmkHb4v/a0tdxomm18sfqRGR/zLI2X CvNvv/ajuOELr9uEF1RGPcZSrolkCBTj4Kdkdth5ecSc3GYeB2M2CfXBxqCTHRI9Y2zY e75A== X-Gm-Message-State: ALoCoQm95xySeGdDclPHmpeSrg4vYjQAIziFrDLMq+IbZm5eRE6zPGFReYLj/Muem2LCY165gPi/ X-Received: by 10.224.38.71 with SMTP id a7mr33781088qae.24.1418408629785; Fri, 12 Dec 2014 10:23:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Fri, 12 Dec 2014 10:23:29 -0800 (PST) In-Reply-To: <5476092D.4010406@nostrum.com> References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 12 Dec 2014 19:23:29 +0100 Message-ID: To: Adam Roach Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NNTArdWquaNzelNHVqZxSmaUziI Cc: "rtcweb@ietf.org" , Harald Alvestrand Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 18:23:53 -0000 2014-11-26 18:09 GMT+01:00 Adam Roach : > On 11/26/14 03:15, Daniel-Constantin Mierla wrote: >> >> IMO, mandatory codec revisiting has to be done for all webrtc entities. >> Why not doing it for web browsers when one codec is proved to be royalty >> free? > > > The rationale here is browser accommodation for very constrained "WebRTC > compatible" devices, which will most typically be concerned with browser > interoperation. The example that's been tossed around in this space is th= e > "WebRTC doorbell" -- when someone rings the bell, you navigate to its > interface using WebRTC, and stream an image from a small, embedded camera= . > In these kinds of very-low-cost devices, you're going to likely see hardw= are > video encoding (e.g. do a web search for NVS2200), which will likely be o= ne > codec or another, but not both. > > The goal is continued browser support for such devices in perpetuity. So potential new open source browser vendors will have to deal with H264 license/patent issues even within the next 6 years just because the "goal is continued browser support for [old video devices] in perpetuity". And that goal seems to be more important than making a W3C/IETF standard 100% free of royalties and patents stuff. May I know where in the WG chapter is that goal defined please? --=20 I=C3=B1aki Baz Castillo From nobody Fri Dec 12 10:43:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792031A902B for ; Fri, 12 Dec 2014 10:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zJi55NBwnni for ; Fri, 12 Dec 2014 10:43:15 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFE61A873A for ; Fri, 12 Dec 2014 10:43:13 -0800 (PST) Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail05.adl6.internode.on.net with ESMTP; 13 Dec 2014 05:13:05 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 91CA2FFC51; Sat, 13 Dec 2014 05:13:04 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3rEzM0Ic9bNv; Sat, 13 Dec 2014 05:13:00 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 56522FFBA4; Sat, 13 Dec 2014 05:13:00 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 48AF180470; Sat, 13 Dec 2014 05:13:00 +1030 (ACDT) Date: Sat, 13 Dec 2014 05:13:00 +1030 From: Ron To: John Leslie Message-ID: <20141212184300.GC20986@hex.shelbyville.oz> References: <547511DB.5050100@nostrum.com> <547FC4FD.2050300@andyet.net> <20141204150041.GI10449@hex.shelbyville.oz> <54808198.7030207@andyet.net> <54808719.10402@nostrum.com> <5483B818.7050102@andyet.net> <20141212173415.GH47023@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141212173415.GH47023@verdi> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vLsC5rfVhCgFXf0Mavk8k5p_PRU Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 18:43:17 -0000 On Fri, Dec 12, 2014 at 12:34:15PM -0500, John Leslie wrote: > On Sat, 06 Dec 2014, Peter Saint-Andre - &yet wrote: > > > 2. A trigger that is more general and future-proof. That is: someday > > (perhaps before too much longer on the standardization timescale) we > > will have other alternatives to consider: H.265, VP9, VP10, Daala, and > > who knows what. > > (I'd be amazed if we didn't have at least one of these ready to use > before this document is published as an RFC.) I hope I'll not be mistaken for hacking in to the pedantry game if I say "that depends on how you define 'ready to use'" :) In one sense you'd be correct, but "ready for this spec to use" is a bit more elusive. - If H.264 is the 800 pound gorilla in the room, then H.265 has climbed to the top of the building with Fay Wray. It's troublesome in all the same ways, but orders of magnitude more intensely. And its licencing appears to have already responded to The Cisco Hack, making that a more difficult (or at least much more expensive) "solution" for anyone trying that sort of thing in future. - Both VP9 and H.265 are significantly more computationally expensive than the currently proposed MTI codecs. It seems doubtful that just about any currently available hardware will be able to use them for real-time streaming. - VP10 and Daala are still WIP. Despite holding a BoF in 2012, and there being continued interest, we don't actually have the WG for this established or chartered yet. (and one of the objections to VP8 before "a dumptruck of Nokia IPR" became the excuse du jour was "but it's not a standard!!") - According to the charter of this group, the milestone for delivering this is ... about 2 weeks away ... It obviously won't be the first WG milestone where the whooshing noise was heard by all and enjoyed by some, and I'm not sure what people expect the time before it's delivered really will be now, but I'm kind of doubtful we'll form another WG and complete its work before it does. And other than happy news out of the ISO process for VP8, or something other than coal in our stockings from the H.264 patent holders, that really seems to be the only way we're likely to solve this once and for all now. I think the interesting question is whether or not we do want to say something along those lines as part of a forward-looking rationale, or whether people think it's still just a little too far over the event horizon at this stage. Ron From nobody Fri Dec 12 11:13:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01411A8713 for ; Fri, 12 Dec 2014 11:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6sbW_b6PEmC for ; Fri, 12 Dec 2014 11:13:20 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id B2C101A87BB for ; Fri, 12 Dec 2014 11:13:19 -0800 (PST) Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Dec 2014 14:13:10 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.03.0210.002; Fri, 12 Dec 2014 14:13:10 -0500 From: Gaelle Martin-Cocher To: "Mo Zanaty (mzanaty)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] confirming sense of the room: mti codec Thread-Index: AQHQEJCKBITgiQUj50CzzuygMU2TV5yGgaCAgAWZ93CAAIB/gP//rG2w Date: Fri, 12 Dec 2014 19:13:09 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF3607F5@XMB111CNC.rim.net> References: <92D0D52F3A63344CA478CF12DB0648AADF360327@XMB111CNC.rim.net> In-Reply-To: Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kkXsUfAhVNqWIhtDnAcvn4Fkp0E Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 19:13:26 -0000 -----Original Message----- From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]=20 Sent: Friday, December 12, 2014 12:55 PM To: Gaelle Martin-Cocher; rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec Agreed, from the viewpoint of specifications. But from the viewpoint of imp= lementations, there is often quite a difference between the level of suppor= t when the spec says =B3can=B2 versus =B3MUST=B2. [gmc] but no so much when the spec says should versus must.=20 E.g. WebRTC endpoints must implement at least one of VP8 and H.264 and shou= ld implement the other one.=20 That says: unless you have a very good reasons, you have to implement both.= =20 This allows implementations to evolve from one to two codecs while not chan= ging the spec. I think everybody should be equally unhappy but might actually deliver prod= ucts according to the specs; making the consensus translatable in something= tangible. Would that be acceptable? Mandatory codec agility is even more important than specific mandatory code= cs, but it may take the latter to force the former. [GMC] generally agree. There is quite a few more options to the above one:= Shall implement at least two codecs, one is a defined MTI, the other if up= to you (or is in a list of recommended codecs). The second codec can be a = future looking codec. Other option: browser and non-browser do not have the= same number of codecs to implement. A third option is an asymmetry in the = number of decoders and encoders. My comment was not based on hypothetical concerns or foresight. It was from= direct experience trying to add H.264 into the webrtc.org codebase and Moz= illa=B9s fork. The current support in Firefox barely meets the bar of shipp= able, and webrtc.org support is not shippable at all. (I think your Blackbe= rry colleagues who also started down this path can corroborate this.)=20 [gmc] we are aware of some current limitations in some implementations. It = was stated also by a few that the video codec is currently not the bottlene= ck to launch services, but the state of overall WebRTC implementations in v= arious browsers.=20 There are still many holes, and lots of refactoring is still in progress to= have a truly robust multi-codec media engine where resilience and other as= pects are harmonized for all codecs. The end result will be a platform that= can more easily and rapidly handle VP9, H.265, Daala, netvc, etc. without = lots of additional refactoring or gaps in functionality across codecs. It d= oes require extra effort, but I see it as essential investment that should = not be deferred. Actually implementing multiple codecs can also reveal gaps in specs.=20 [gmc] Agree. We are in a situation where some mobile apps/libraries/SDKs al= ready implement multiple codecs (not necessarily the MTI ones) and are on t= he forefront of "debugging" webRTC for these aspects.=20 Browser wise, well, yes I agree, that may take much more time. Achieving interoperability is also (usually, in some worlds) achieved via c= onformance tests. If these tests are limited in the OTT/WebRTC world, it is not by multiplyin= g MTI functions (whatever they are) that implementations will be better. It= will still be product A attempting to interoperate with e.g. browsers B, C= , product D... hit/miss, try again. Indeed that will take time to verify al= l of WebRTC functions across a large list of implementations. For example, I strongly support your argument for decoding many formats eve= n if you can only encode one or a few. It is a good technical direction. Bu= t try to implement it with current standards, and you will hit some walls. [gmc] Standards are/should be evolving ?=20 Ga=EBlle Mo On 12/12/14, 10:27 AM, Gaelle Martin-Cocher wrote: Multiple codecs can be supported even if there is only a single MTI defined= in WebRTC.=20 This has been confirmed by those who will implement scalable codecs. I am not aware of anyone asking for removing the codec negotiation/capabili= ty discovery even if there is a single MTI. As such supporting multiple codecs is independent from the MTI discussion. The question is not do we need multiple codecs but do we need multiple MTIs= (and which).=20 Ga=EBlle -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Mo Zanaty (mzanaty) Sent: Monday, December 08, 2014 3:42 PM To: Sean Turner; rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec To reiterate another point from the meeting, there are technical advantages= to supporting multiple codecs. Dynamic discovery of local capabilities, ne= gotiation of remote capabilities, understanding how different error resilie= nce mechanisms can work (or not) with different codecs, faster adoption of = new (non-mandatory) codecs, easier path to deprecating old (mandatory) code= cs, etc. All those legs never get exercised effectively in single-codec imp= lementations, leaving land mines in browsers, apps, services and sometimes = even specs. They become easier or free once the groundwork is laid for mult= iple codecs. While some have argued against that extra complexity, I see it= as essential for any important standard. Mo From nobody Fri Dec 12 15:33:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8A01A0025 for ; Fri, 12 Dec 2014 15:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhpVS1VMuODx for ; Fri, 12 Dec 2014 15:33:42 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4381A000D for ; Fri, 12 Dec 2014 15:33:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418427222; x=2282340822; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6kf78Qa3LP+oqFFlwV2MAZ3kVeSqU3fqfWEqqDB80OQ=; b=EAgDqvLz9Vhjbsn4cWh0P+Ts5+2P0kMGQ389pITl95HnUUlAXgj+lzu7kxr93kIu 3djslD2pbCocV6u5X0ERbduSIMlHQp5zjTiKXbYmLbqEadV/FYRCzQNR3zwvX52e wnStpjHg/U0F++4shH+mfVRu0u6ryOLTI4VzEcOs9pMJA5XH0sCTPZGeuJKggaOJ p31groOxMhW4W8SmQI6l5VOHbjIyEY35raGg36t3T7nz5lq9IXUWGvhPL8G8T8g0 XJAS0kOIqJHNZhqd8HUmFkaDsZ8QoTgbq1WEFee6g0uwk2lBjva1aGLs6b+YwPtk QafvtpPZxmdzdndcXOZylg==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 39.28.06819.65B7B845; Fri, 12 Dec 2014 15:33:42 -0800 (PST) X-AuditID: 11973e13-f79656d000001aa3-26-548b7b56dc6c Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id C6.06.05439.C5B7B845; Fri, 12 Dec 2014 15:33:48 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGH00B06TG5LJ70@marigold.apple.com> for rtcweb@ietf.org; Fri, 12 Dec 2014 15:33:41 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <548B047F.9090704@nostrum.com> Date: Fri, 12 Dec 2014 15:33:41 -0800 Content-transfer-encoding: quoted-printable Message-id: <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> References: <548AD22D.7040104@it.aoyama.ac.jp> <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <548B047F.9090704@nostrum.com> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FAYrBtW3R1iMGcev8Xaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKODx5F3PBW7aKk+8uszcwHmDtYuTgkBAwkTg2I7qLkRPIFJO4 cG89WxcjF4eQwF5GiR2zT7JDJIBqFn1khEhMYpK4P+0YlDOfSeLG1h2MIJOYBdQlpkzJBWng FdCTaHrymAkkLCxgK7H1ehBImE1AVeLBnGNg1ZwC2hIXFzKBhFmAwvuWTWAFsZmBwk/eXWCF mGIjcfDaG1aITeeYJL6ePsUIkhAB2nT54QWo22Ql/l08ww5SJCHwkFXi3tN3rBMYhWYhXDQL yUWzkOxYwMi8ilEoNzEzRzczz1QvsaAgJ1UvOT93EyMoVKfbCe9gPL3K6hCjAAejEg/vi9Su ECHWxLLiytxDjNIcLErivMvcukOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MPI/3Hv9A9eE FsWbVraht7zOLvB5+1LcOPG4mjnjs9vbd1RMWDX1vEdJ9v2yVP8lquoGJ5+uEXuQyap2YdPl XSI/0s5MPBCWbrfBytqoPqnZ2SG20vsGw8vLd7cbJM807MrJq6nTv+1m06ggUHD6dUzSioSP nTJFe5u9ZuabW6kIKd/RP1jZo8RSnJFoqMVcVJwIAHhAnGE2AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUi2FDcohtT3R1icG0Hr8Xaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKODx5F3PBW7aKk+8uszcwHmDtYuTkkBAwkTi26CMjhC0mceHe erYuRi4OIYFJTBL3px1jhHDmM0nc2LoDyOHgYBZQl5gyJRekgVdAT6LpyWMmkLCwgK3E1utB IGE2AVWJB3OOgVVzCmhLXFzIBBJmAQrvWzYBbC0zUPjJuwusEFNsJA5ee8MKsekck8TX06fA 7hEB2nT54QV2iNtkJf5dPMM+gZF/FsIRs5AcMQvJ2AWMzKsYBYpScxIrjfUSCwpyUvWS83M3 MYKDqzB4B+OfZVaHGAU4GJV4eCckd4UIsSaWFVfmHmKU4GBWEuG1FO8OEeJNSaysSi3Kjy8q zUktPsQozcGiJM5b8a4xREggPbEkNTs1tSC1CCbLxMEp1cDI9uxe6MWZStMeWflPUL+a8OWs 4rRUa+HP+it+aE9u2rt998Uot451k/76LN3/dWWfxIYKgaCKIFbdf3LM5yW2rmnTujvdRPOX 2jkdO763fv6K75/kPbuk9WjtcfktydKvAg7+dZH7PaHsbpfCbn+JFIUXpo6z+r+x8nS+5lC4 +PjfvLiHu3IKlFiKMxINtZiLihMBZ7+hNyoCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hI4ImA1CuTjxPklSgzqvzr4nd9Y Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 23:33:43 -0000 > On Dec 12, 2014, at 7:06 , Adam Roach wrote: >=20 > On 12/12/14 08:57, I=C3=B1aki Baz Castillo wrote: >> IMHO the door should remain open for, at least, the inclusion of a = new 100% RF video codec. >=20 > Then you already have what you want: there's no way we could close = that door, no matter how hard we tried. Quite. I rather suspect that stating =E2=80=9CIf the situation changes, = we may change this specification=E2=80=9D is stating the obvious. These = forward-looking statements don=E2=80=99t seem to inform implementations, = or constrain or de-constrain the group. I am unclear as to what purpose = they serve. As a humorist once remarked, =E2=80=9Cwhat am I supposed to do about = road-side signs that warn of low-flying aircraft? take my hat off?=E2=80=9D= David Singer Manager, Software Standards, Apple Inc. From nobody Fri Dec 12 15:39:42 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA941A00FF for ; Fri, 12 Dec 2014 15:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kENrUzYOsLCM for ; Fri, 12 Dec 2014 15:39:39 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D749D1A00CD for ; Fri, 12 Dec 2014 15:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418427579; x=2282341179; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=I/pgNk7WUiOaZY61qk0Tnx05z3NGOuLcLJjmYeTLj5o=; b=PQw7OfV3Ebf3tGTM7G8/jhUGdFMCRHY5ip/Gxtdc7ufuQoGHkFGgG0HGI1JaO/sX TtJexoNmeTxcbNA46qTZaBm0l9m/Xev1HzQvLw9IVa/u4DkJfqv8iPk802mOONdh /ArcApEGWNL1PuJq3SRa1dKch9TNHLrMeTuHDX/Ygi5L0DwIJXFzEUN0Bt70vKFe Irji5YjGZjRcuac6hxRa5UK8yPrMyAUk4w2jzA+VgckZ8ZoIEdUXwWGOfMNTQ+6C PDAFTxy6mD4f4uGANyjgd/ygMuO/No+jEpROfdv0M3bwnYsLiKIh/OicvpU8rc50 sPLFnD9kLd1etSdPfgnrzg==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id F9.F3.12074.BBC7B845; Fri, 12 Dec 2014 15:39:39 -0800 (PST) X-AuditID: 11973e12-f79f86d000002f2a-47-548b7cbbaad5 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 0E.DB.06091.B9C7B845; Fri, 12 Dec 2014 15:39:07 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGH00B8LTQ3LJ70@marigold.apple.com> for rtcweb@ietf.org; Fri, 12 Dec 2014 15:39:39 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: Date: Fri, 12 Dec 2014 15:39:38 -0800 Content-transfer-encoding: quoted-printable Message-id: <0AD9F067-0C36-48FD-AE22-AC786FA8718C@apple.com> References: <92D0D52F3A63344CA478CF12DB0648AADF360327@XMB111CNC.rim.net> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUi2FCYqru7pjvE4OseRYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcX/xJ8aCr7wVfR83MjUwtnF3MXJySAiYSDybvZMdwhaTuHBv PVsXIxeHkMA+Ron3v08AORxgRSdueYHUCAlMYpL43uMOYc9nklj1zw6khFlAXWLKlFyQMK+A nkTTk8dMIGFhAVuJrdeDQMJsAqoSD+YcYwSxOQWCJWY/7GIGsVmA4qt+tIBdwCygLfHk3QVW iDE2Eq8OtDBBbHrGKNE8IQvEFgHadPnhBaiLZSX+XTzDDnKxhMBdVol9i26yTWAUmoVw0Swk F81CsmIBI/MqRqHcxMwc3cw8E73EgoKcVL3k/NxNjKAwnW4ntIPx1CqrQ4wCHIxKPLwvUrtC hFgTy4orcw8xSnOwKInzLnfrDhESSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAWGLfMuVCkJTf O/8fL85dmcBgqHT60RGHI6/3cEz4FVZlKHpg/tztsk1qs0U0zDveZaenhe2pZy0yUw3dfGj5 7VMvhTj7NMWWNpdX38i+UB33qn/L2Ybp1emiNesjY79yTdycVM61J042KGWBlPsiqZWVpxd9 SExseWHBvrevq1B73RcOLsUfSizFGYmGWsxFxYkAy3ScjzQCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUi2FDcoju7pjvEYPZHWYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcX/xJ8aCr7wVfR83MjUwtnF3MXJwSAiYSJy45dXFyAlkiklc uLeeDcQWEpjEJPG9xx3Cns8kseqfHUg5s4C6xJQpuSBhXgE9iaYnj5lAwsICthJbrweBhNkE VCUezDnGCGJzCgRLzH7YxQxiswDFV/1oYQexmQW0JZ68u8AKMcZG4tWBFiaITc8YJZonZIHY IkCbLj+8wA5xmazEv4tn2Ccw8s9COGIWkiNmIZm6gJF5FaNAUWpOYqW5XmJBQU6qXnJ+7iZG cFgVpu5gbFxudYhRgINRiYd3QnJXiBBrYllxZe4hRgkOZiURXkvx7hAh3pTEyqrUovz4otKc 1OJDjNIcLErivCHvGkOEBNITS1KzU1MLUotgskwcnFINjAYed1c8nNv5b11eg31ox5t3cq6L Ch4IN7mpOf99rnDr3rzb2/ymmxt83TRrz+b2nc3PE/T6Z7EEyPWsu3VcW21dByd3ZnDg4/cL N3j9OOwWfjdmg7HK+pSm3AL/zTN8liU8mmY437pgonOS/ORtvSmC3hMdhFWEuEwi1N6kR2Wu n5SskXn6iBJLcUaioRZzUXEiAH4qdO4nAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2If991397EKpktp4UZ2REH5kBWg Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 23:39:41 -0000 > On Dec 12, 2014, at 8:32 , I=C3=B1aki Baz Castillo = wrote: >=20 > 2014-12-12 16:27 GMT+01:00 Gaelle Martin-Cocher = : >> The question is not do we need multiple codecs but do we need = multiple MTIs (and which). >=20 > We need MTI codecs, but no patent/license polluted ones. I think hoping for an RF codec is optimistic but may be achieved. = Hoping for a codec which has needs/has no license is definitely further = out on the optimism scale. We can hope for Reasonable licenses, of course, but then we rapidly find = that we don=E2=80=99t have a consensus definition, in the industry, for = what is reasonable. I have struggled with this for years. > That's the > reason of my question. Will those non 100% RF video codecs be removed > as MTI *if* a new 100% RF good video codec appeared? Will we have to > deal with non RF MTI codecs forever? >=20 > The arguments I'm reading in this thread about the no-need for more > MTI codecs in the future could also be applied for the no-need of > defining any MTI codec now. At the end we do have a "codec > negotiation/capability discovery" mechanism, right? My experience is that once something is mandatory in a spec., it can get = very wedged; people say (reasonably) it has to remain mandatory to = ensure interop with the established base. Part of my concern is that it = may lock almost everyone into a state of perpetual unhappiness. For example, it took many years to get 3GPP to move H.263 from mandatory = to only recommended. :-( This is, I admit, at odds with the =E2=80=9Cbe agile=E2=80=9D mood of = the times. YMMV. best wishes of the season! sorry to be dismal. David Singer Manager, Software Standards, Apple Inc. From nobody Fri Dec 12 15:42:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865D61A017C for ; Fri, 12 Dec 2014 15:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXaIxNFmHHE9 for ; Fri, 12 Dec 2014 15:42:33 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7141A0012 for ; Fri, 12 Dec 2014 15:42:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418427753; x=2282341353; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zfbARzHStaaEZK7f0wxr2aGWsynKhyzoZPI2ik8+hqk=; b=eGFLpsJWf2/daAe1h/8wbYEFd+k5Kslj9bu3jHKg63MsqVzRWQAdgj+hT6oxTUxr /4UuSkgIqa3Z0troBnE6DlqJZkg1fEsfEyAd0nYyR0Y4YEkpP6TG9bjObW6rQK9C SCCSZhrTe7UbG87UvKv6VPENhAhUfWIo15UbK7ZcEmXLv1DqlOcMc9lxwXontCOU XtXT2Fbwzt/Ss4cyoSj+wDKPNct/pbPvGr/7fK9ZLnxnarHumwylUgpaYHj0AK/F Ry2cwqZJqVZ84I5vYn7CUWiAjOHwO8TbA+6s4A4JmrdTt+Fpsil65DxOBdQq8aXg wa8I4sN3kTZ4dknuVHY6AA==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id DB.64.12074.96D7B845; Fri, 12 Dec 2014 15:42:33 -0800 (PST) X-AuditID: 11973e12-f79f86d000002f2a-e3-548b7d6910fd Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 06.9D.06091.94D7B845; Fri, 12 Dec 2014 15:42:01 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGH00BCFTUWLJ70@marigold.apple.com> for rtcweb@ietf.org; Fri, 12 Dec 2014 15:42:32 -0800 (PST) Content-type: text/plain; charset=windows-1252 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <92D0D52F3A63344CA478CF12DB0648AADF3607F5@XMB111CNC.rim.net> Date: Fri, 12 Dec 2014 15:42:32 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <92D0D52F3A63344CA478CF12DB0648AADF360327@XMB111CNC.rim.net> <92D0D52F3A63344CA478CF12DB0648AADF3607F5@XMB111CNC.rim.net> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FCYqptZ2x1icHUjn8Xaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOD79GHPBXY6KTSdjGhi/s3UxcnJICJhIfLnxjAnCFpO4cG89 UJyLQ0hgH6PE5uMHmWGKJvydwQ6RmMQkcebPK6iq+UwSiz+eZe1i5OBgFtCTuH9RC6SBF8hs evKYCSQsLGArsfV6EEiYTUBV4sGcY4wgNqeAp8SP+5fYQWwWoPjj1S/B4swC2hJP3l0Am8gr YCPR8FwdYlMzk8TRJ3vA6kUE1CUuP7zADnGbrMS/i2fAbpMQuMsqcXP5ArYJjEKzEC6aheSi WUhWLGBkXsUolJuYmaObmWeil1hQkJOql5yfu4kRFKrT7YR2MJ5aZXWIUYCDUYmH90VqV4gQ a2JZcWXuIUZpDhYlcd7lbt0hQgLpiSWp2ampBalF8UWlOanFhxiZODilGhi7FkYFPi/K25Np +PVD3sNPS9S3PhUX6W1Vv5375ZL41/97ymP3red4tfTZ+pk8jfxO274/cvI72cqx2G/qzf8b fr5cMWGd0BujM716Jzg/TFTra9EJOdm+IFYpr+/Hl7DwM0I5ASk2YgmP9tW93lnS/FKCfcJC vhrjvJc5Bx16TUv+pYZMWKSsxFKckWioxVxUnAgACHgQrjYCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUi2FDcoutZ2x1isH4pt8Xaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOD79GHPBXY6KTSdjGhi/s3UxcnJICJhITPg7gx3CFpO4cG89 UJyLQ0hgEpPEmT+voJz5TBKLP55l7WLk4GAW0JO4f1ELpIEXyGx68pgJJCwsYCux9XoQSJhN QFXiwZxjjCA2p4CnxI/7l8DmswDFH69+CRZnFtCWePLuAthEXgEbiYbn6hCbmpkkjj7ZA1Yv IqAucfnhBajbZCX+XTzDPoGRfxbCEbOQHDELydQFjMyrGAWKUnMSK831EgsKclL1kvNzNzGC Q6swdQdj43KrQ4wCHIxKPLwTkrtChFgTy4orcw8xSnAwK4nwWop3hwjxpiRWVqUW5ccXleak Fh9ilOZgURLnDXnXGCIkkJ5YkpqdmlqQWgSTZeLglGpg3KS6bWLwNyuzEq1n+1mq15Q8Pe/z syNXhe2H4sopU/hnXJTaX1LHeWvthtVKrO4XOuVl3uXxMrJEBwScjFVfGVA4fc6+DmVW55j9 WbxK2Q/jD/Re5MgWSLt0eFuW+8baHa/Nq6/rhCprnVY89kBfMd8gYZa7c76Y+jaZnOcrNdIk mlY0lnAqsRRnJBpqMRcVJwIADsXq4CkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2mlZP8YpbVqw_FpBGnGf82ujleg Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 23:42:34 -0000 > On Dec 12, 2014, at 11:13 , Gaelle Martin-Cocher = wrote: >=20 > Mandatory codec agility is even more important than specific mandatory = codecs, but it may take the latter to force the former. > [GMC] generally agree. There is quite a few more options to the above = one: Shall implement at least two codecs, one is a defined MTI, the = other if up to you (or is in a list of recommended codecs). The second = codec can be a future looking codec. Other option: browser and = non-browser do not have the same number of codecs to implement. A third = option is an asymmetry in the number of decoders and encoders. Yes, indeed. If your goal is to make sure everyone can negotiate, we = don=92t have to say what over, as long as the support is for more than = one. We could also split (as I said before) transmit and receive. Encoders = are harder to do well than decoders, generally. If everyone can decode = multiple codecs, they only need to be able to encode one. This also = exercises negotiation. David Singer Manager, Software Standards, Apple Inc. From nobody Fri Dec 12 15:49:26 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66BC1A0149 for ; Fri, 12 Dec 2014 15:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzJZb9LXeieD for ; Fri, 12 Dec 2014 15:49:22 -0800 (PST) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860DE1A00FF for ; Fri, 12 Dec 2014 15:49:22 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hl2so3343247igb.4 for ; Fri, 12 Dec 2014 15:49:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=f3ttlNIwz0hcIa69IsUDMxvXJzBNeu07S57cIY7ERbg=; b=AW7hw5y3K1UNL95naT8qGC44DT/LuxUsJ45IjFOiGN9CelDLIIfjuKSnsRSjBO3gkm yK0jj9tqeiQhrR6dXJmffT2TqhIWvDgevRnDyYDpHxo/lh+QA9iT1oxdNVKL2MWBEOnt kbvwat5XQTwCB4LXaz1b6XdNgcqdaV8dOTmYETc/gn9nJrnbhC3t5BSx85D+Pbx8YlOd u7cS1R7T2NYcUv26r1Z4MnutkOGiKpIwuov/pzV44RJZ/MYDz2L65KfCKkUT2hNGeA/Y ka/514Oh+dD+TAA76UgEtgIdxr2+MfYncCC0QgxJryRlg5W1cZPUvfB3DtV3Qq1PVazp uhbA== X-Gm-Message-State: ALoCoQkX1bbTmbnstKoeUFyyj8J3kGGO9fAamCUJpBXEENmJ6tYsH0nM2W1pNiUpHv2xn+sq7+o+ X-Received: by 10.107.18.32 with SMTP id a32mr18139515ioj.77.1418428161900; Fri, 12 Dec 2014 15:49:21 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id 5sm289705iom.7.2014.12.12.15.49.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Dec 2014 15:49:21 -0800 (PST) Message-ID: <548B7EFF.5080105@andyet.net> Date: Fri, 12 Dec 2014 16:49:19 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: David Singer , "rtcweb@ietf.org" References: <548AD22D.7040104@it.aoyama.ac.jp> <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> In-Reply-To: <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bpqRyba-aEAuAYAsl-djPJoJOLM Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 23:49:24 -0000 On 12/12/14, 4:33 PM, David Singer wrote: > >> On Dec 12, 2014, at 7:06 , Adam Roach wrote: >> >> On 12/12/14 08:57, Iñaki Baz Castillo wrote: >>> IMHO the door should remain open for, at least, the inclusion of a new 100% RF video codec. >> >> Then you already have what you want: there's no way we could close that door, no matter how hard we tried. > > Quite. I rather suspect that stating “If the situation changes, we may change this specification†is stating the obvious. These forward-looking statements don’t seem to inform implementations, or constrain or de-constrain the group. I am unclear as to what purpose they serve. Right now the spec makes forward-looking statements. To promote the use of non-royalty bearing video codecs, participants in the RTCWEB working group, and any successor working groups in the IETF, intend to monitor the evolving licensing landscape as it pertains to the two mandatory-to- implement codecs. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, the working group plans to revisit the question of which codecs are required for Non-Browsers, with the intention being that the royalty-free codec will remain mandatory to implement, and the other will become optional. These provisions apply to WebRTC Non-Browsers only. There is no plan to revisit the codecs required for WebRTC Browsers. I am now thinking that if we're not going to define how all this is supposed to work (automatic triggers? RFC to replace this one? etc.), then it would be best to remove that text. And yes, any future RFC that has IETF consensus can update or obsolete this one (should it become an RFC), so there's no reason to run through all the scenarios. See you at the NETVC BoF! ;-) Peter -- Peter Saint-Andre CTO @ &yet https://andyet.com/ From nobody Fri Dec 12 16:00:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3641A1AA3 for ; Fri, 12 Dec 2014 16:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBAaI-LbP4Mb for ; Fri, 12 Dec 2014 16:00:43 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2A31A1A9F for ; Fri, 12 Dec 2014 16:00:42 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id r5so6410363qcx.13 for ; Fri, 12 Dec 2014 16:00:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=eg8EClCtglm5LD1ne03Fql8lWVX+jpPx6CmsH/Q0cRM=; b=Z4n5kD4qm7YsFlqnyO+xVkHxUPQX+Fa5w/LyEYgwHBJz0cFVuWrIVyzwhttzG0S1ZU 9Lk8rfKsYFwpIBTMgIUIAhWi0nBgyhLDgQE5kSA/LIlJ+oyHbaqCD7QO/TWoaREvui8L KxbFM6Lk5Zes1XRgEcYbftUjFLR0eBLUBU1LMTDPR1pdWQv68Rsz9ahq6+mauPHddFGz qJry2qxHUJkoi7ApaiFMBi/lGZZ89zcJv8eMfXxKn9MP3G4swksTVHMFrTnOGeAUv04n f8LQaPOwL6oMZfX8NyiFtZkaRHwyXX9IqYkbZM/K5Vg7OnbDgoJFn2/wvYIYGql4kfq3 4ULg== X-Gm-Message-State: ALoCoQnLWw5cfoJsAXXooZwmOWfLoiE4CpIlnnyX1OXiuE8968FrA7E+5X8VrgxOQr78xGvCtw8n X-Received: by 10.140.49.107 with SMTP id p98mr34014133qga.20.1418428842153; Fri, 12 Dec 2014 16:00:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Fri, 12 Dec 2014 16:00:21 -0800 (PST) In-Reply-To: <548B7EFF.5080105@andyet.net> References: <548AD22D.7040104@it.aoyama.ac.jp> <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 13 Dec 2014 01:00:21 +0100 Message-ID: To: "Peter Saint-Andre - &yet" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BEH65jez-3Bqw1iMM0g0FIzpMrY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 13 Dec 2014 00:00:44 -0000 2014-12-13 0:49 GMT+01:00 Peter Saint-Andre - &yet : > To promote the use of non-royalty bearing video codecs, > participants in the RTCWEB working group, and any successor > working groups in the IETF, intend to monitor the evolving > licensing landscape as it pertains to the two mandatory-to- > implement codecs. If compelling evidence arises that one of the > codecs is available for use on a royalty-free basis, the working > group plans to revisit the question of which codecs are required > for Non-Browsers, with the intention being that the royalty-free > codec will remain mandatory to implement, and the other will > become optional. > > These provisions apply to WebRTC Non-Browsers only. There is no > plan to revisit the codecs required for WebRTC Browsers. Clear. H264 mandatory for browsers forever. Congrats patent holders. BTW this is the first specification/standard/draft/RFC that states how future revisions of itself should behave. A clear lock-in IMHO. --=20 I=C3=B1aki Baz Castillo From nobody Fri Dec 12 16:09:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6E81A1AEB for ; Fri, 12 Dec 2014 16:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ia4jQE4yi6B7 for ; Fri, 12 Dec 2014 16:09:41 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98671A1AC2 for ; Fri, 12 Dec 2014 16:09:40 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id i17so6352660qcy.32 for ; Fri, 12 Dec 2014 16:09:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=T6jQVBt1RKIC20mjgAFkhigu0OoaZRYavcxuBLJ79gQ=; b=dvxAiiZwg1aJorSGAvibqSYuwnqBRXgp0d6inJrcbx3zV9VFVl+mPHeFlwjUfvL3mF NifBY9RjY5jOb62vug3e6SwQFW5U0eCwdmd5q6ryvu7gH5jTcbRT5KLpj1D76ieA41qg x9et5niNBhH3tGN9PSbdVus0lT3hRKOBdr4D4ZkWbXwcKApyJ7l+o+0spr1UxyghPzFy 4dB8X2EX7ui7cZqdCRgYrIRM4BecD9IOpZ8oNdD6ie6szJZ/+MO7HRH3trq8NWeULiQB rVgjhMZgbsAzXLMk4tdfX4VomGdo6Eh1AcN6ffzR4cNSD2jAi00CAz4kI6tOVEuacHhq uXtg== X-Gm-Message-State: ALoCoQkw4a+a/vLubODeFnZF0hm7ApdgcVLmjkjw/kYegaSHqxbWNeaS6IAE9QtzA8MvDV6StLup X-Received: by 10.140.92.202 with SMTP id b68mr23984629qge.10.1418429379823; Fri, 12 Dec 2014 16:09:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Fri, 12 Dec 2014 16:09:19 -0800 (PST) In-Reply-To: <20141212173415.GH47023@verdi> References: <547511DB.5050100@nostrum.com> <547FC4FD.2050300@andyet.net> <20141204150041.GI10449@hex.shelbyville.oz> <54808198.7030207@andyet.net> <54808719.10402@nostrum.com> <5483B818.7050102@andyet.net> <20141212173415.GH47023@verdi> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 13 Dec 2014 01:09:19 +0100 Message-ID: To: John Leslie Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/N8Z-Qb6_Jm3WLiMbbZwF6gUQQ2Y Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Finishing up the Video Codec document X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 13 Dec 2014 00:09:43 -0000 2014-12-12 18:34 GMT+01:00 John Leslie : >> 2. A trigger that is more general and future-proof. That is: someday >> (perhaps before too much longer on the standardization timescale) we >> will have other alternatives to consider: H.265, VP9, VP10, Daala, and >> who knows what. > > (I'd be amazed if we didn't have at least one of these ready to use > before this document is published as an RFC.) Too late. --=20 I=C3=B1aki Baz Castillo From nobody Fri Dec 12 16:56:52 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789F91A8867 for ; Fri, 12 Dec 2014 16:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yt6g0xShQg5L for ; Fri, 12 Dec 2014 16:56:48 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C451A884E for ; Fri, 12 Dec 2014 16:56:47 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id dc16so6008585qab.11 for ; Fri, 12 Dec 2014 16:56:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=FGzw+rKxr7lT1Ad3d6SodPYzJ+HA63xzJLQTvrogGv4=; b=IKY/Ix+5oAWyvMobMfWQq5yxBz6j9OO/ED/Kn9sZeGeyLWZzJeZ/zOhvnVHHgOLQEy u9Byqj+YuTGUVhYArRoNmpKcuiroLlWKADK1ID5XO0PRvcY+Jsx4DrH6t4Kx5zPJJtr4 hQVB86AFW3REn1V3ZqGFrJ8JmBQip7ZJk1LwAZq0Iy4mXFiGeeUhRxh0gnQYTehpyF1k E8A3K43LetAKCeyhA9TRYvB2jourg+WwtDhjMGSIzBsDBgUXID/32wJThxqgTi64lL5e vDGbOhLRVXRG4oNt8G5thQQr6l3Tc/FA0zFYLoCNv9Wsh/8q8/qR5K2w9ypqHlD0rLNF B2Tg== X-Gm-Message-State: ALoCoQnJ98Ip7V7z/YnBKF0eS59PodY6DvpMEV7qlinO4/wG6PYZUdR8F5bA5C5CUgPYDZJLSPf+ X-Received: by 10.140.92.202 with SMTP id b68mr24242157qge.10.1418432206593; Fri, 12 Dec 2014 16:56:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Fri, 12 Dec 2014 16:56:25 -0800 (PST) In-Reply-To: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> References: <4114C519-5B41-43B5-8426-E6191398BE4D@cisco.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 13 Dec 2014 01:56:25 +0100 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lo-1fcPmWvnJaRS8fgN6eQszBQ4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for adoption of draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 13 Dec 2014 00:56:50 -0000 > Since a gateway is expected to be deployed where it can be reached with = a static IP address (as seen from the client), a WebRTC gateway does not ne= ed to support full ICE; it therefore MAY implement ICE-Lite only. Even if the only useful statement defined by the draft was that, I say +1. I support this draft so no one can request (again) that all the WebRTC entities MUST support full ICE (which is a resource and time waste in servers). Thanks for this. 2014-12-04 20:29 GMT+01:00 Cullen Jennings (fluffy) : > Having reviewed the fine technical comments on this draft since we asked = for comments, the chairs have noted that multiple people seem to have read = the draft. Given this great news we are going make a call for adoption. > > If you have an opinion, please email the list by Dec 19 and let us know i= f you either: > > A) yes, draft-alvestrand-rtcweb-gateways should be adopted as a WG docume= nt now > > B) no, not right now > > If we get consensus around A we will work with ADs on milestone. Otherwis= e we will encourage the authors to keep working on this draft and continue = using this email list. We may adopt it later or include the text in other d= rafts. > > Thanks, > The Chairs (Cullen, Sean, Ted) > > PS - if you want to send an email that says more than A or B, feel free t= o change the subject, start a new thread etc. > > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 I=C3=B1aki Baz Castillo From nobody Fri Dec 12 19:12:27 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152501A916B for ; Fri, 12 Dec 2014 19:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w20j7hY58GL6 for ; Fri, 12 Dec 2014 19:12:22 -0800 (PST) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id 972401A9147 for ; Fri, 12 Dec 2014 19:12:20 -0800 (PST) Received: from ppp14-2-2-160.lns21.adl2.internode.on.net (HELO mailservice.shelbyville.oz) ([14.2.2.160]) by ipmail05.adl6.internode.on.net with ESMTP; 13 Dec 2014 13:42:19 +1030 Received: from localhost (localhost [127.0.0.1]) by mailservice.shelbyville.oz (Postfix) with ESMTP id 01740FFCCA for ; Sat, 13 Dec 2014 13:42:19 +1030 (ACDT) X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz Received: from mailservice.shelbyville.oz ([127.0.0.1]) by localhost (mailservice.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jiuB7NKSRT7B for ; Sat, 13 Dec 2014 13:42:16 +1030 (ACDT) Received: from hex.shelbyville.oz (hex.shelbyville.oz [192.168.1.6]) by mailservice.shelbyville.oz (Postfix) with ESMTPS id B39A5FF8CD for ; Sat, 13 Dec 2014 13:42:16 +1030 (ACDT) Received: by hex.shelbyville.oz (Postfix, from userid 1000) id A299E80470; Sat, 13 Dec 2014 13:42:16 +1030 (ACDT) Date: Sat, 13 Dec 2014 13:42:16 +1030 From: Ron To: rtcweb@ietf.org Message-ID: <20141213031216.GF20986@hex.shelbyville.oz> References: <548AD22D.7040104@it.aoyama.ac.jp> <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <548B7EFF.5080105@andyet.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RNcxzdBsoIKrq_rIXiXVbGSy36w Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 13 Dec 2014 03:12:25 -0000 On Fri, Dec 12, 2014 at 04:49:19PM -0700, Peter Saint-Andre - &yet wrote: > On 12/12/14, 4:33 PM, David Singer wrote: > > > >>On Dec 12, 2014, at 7:06 , Adam Roach wrote: > >> > >>On 12/12/14 08:57, Iñaki Baz Castillo wrote: > >>>IMHO the door should remain open for, at least, the inclusion of a new 100% RF video codec. > >> > >>Then you already have what you want: there's no way we could close that door, no matter how hard we tried. > > > >Quite. I rather suspect that stating “If the situation changes, we may change this specification†is stating the obvious. These forward-looking statements don’t seem to inform implementations, or constrain or de-constrain the group. I am unclear as to what purpose they serve. > > Right now the spec makes forward-looking statements. > > To promote the use of non-royalty bearing video codecs, > participants in the RTCWEB working group, and any successor > working groups in the IETF, intend to monitor the evolving > licensing landscape as it pertains to the two mandatory-to- > implement codecs. If compelling evidence arises that one of the > codecs is available for use on a royalty-free basis, the working > group plans to revisit the question of which codecs are required > for Non-Browsers, with the intention being that the royalty-free > codec will remain mandatory to implement, and the other will > become optional. > > These provisions apply to WebRTC Non-Browsers only. There is no > plan to revisit the codecs required for WebRTC Browsers. > > I am now thinking that if we're not going to define how all this is supposed > to work (automatic triggers? RFC to replace this one? etc.), then it would > be best to remove that text. > > And yes, any future RFC that has IETF consensus can update or obsolete this > one (should it become an RFC), so there's no reason to run through all the > scenarios. Well, there is still the question of how we're complying with the charter which says: 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. Can we show how we've "tried to avoid that", in the light of having consensus that VP8 is acceptable as MTI? And I still really don't get how we've complied with 6.1.1/6.1.2 of BCP 79, in spirit or letter, if we still *only* have disclosures for VP8. Yes I know some people keep repeating "it's an ISO standard, not an IETF one", but that's not an escape clause BCP 79 offers. If we make H.264 MTI then it becomes a technology required to implement this standard. For which BCP 79 says: Contributors must disclose IPR meeting the description in this section; there are no exceptions to this rule. Ron From nobody Sat Dec 13 08:36:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA331A064C for ; Sat, 13 Dec 2014 08:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9H45EmmoZVF for ; Sat, 13 Dec 2014 08:36:07 -0800 (PST) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [67.18.21.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448F61A0461 for ; Sat, 13 Dec 2014 08:36:07 -0800 (PST) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id 845E5592075C9; Sat, 13 Dec 2014 10:36:06 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway15.websitewelcome.com (Postfix) with ESMTP id 4ABA0592074E3 for ; Sat, 13 Dec 2014 10:36:06 -0600 (CST) Received: from [96.231.218.201] (port=63074 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xzpfp-0001yq-Ck; Sat, 13 Dec 2014 10:36:05 -0600 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Sat, 13 Dec 2014 11:36:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <548AD22D.7040104@it.aoyama.ac.jp> <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> To: =?windows-1252?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.218.201 X-Exim-ID: 1Xzpfp-0001yq-Ck X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [96.231.218.201]:63074 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3y7AaKfgeavtba2vM-5qgbG0Ogw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 13 Dec 2014 16:36:08 -0000 On Dec 12, 2014, at 19:00, I=F1aki Baz Castillo wrote: > 2014-12-13 0:49 GMT+01:00 Peter Saint-Andre - &yet : >> To promote the use of non-royalty bearing video codecs, >> participants in the RTCWEB working group, and any successor >> working groups in the IETF, intend to monitor the evolving >> licensing landscape as it pertains to the two mandatory-to- >> implement codecs. If compelling evidence arises that one of the >> codecs is available for use on a royalty-free basis, the working >> group plans to revisit the question of which codecs are required >> for Non-Browsers, with the intention being that the royalty-free >> codec will remain mandatory to implement, and the other will >> become optional. >>=20 >> These provisions apply to WebRTC Non-Browsers only. There is no >> plan to revisit the codecs required for WebRTC Browsers. >=20 > Clear. H264 mandatory for browsers forever. Congrats patent holders. >=20 > BTW this is the first specification/standard/draft/RFC that states how > future revisions of itself should behave. A clear lock-in IMHO. >=20 Just to be clear: "No plan" does not mean that the requirement is = immutable forever, just that we don't have a plan right now. MTI = requirements in IETF documents can always be updated, and they very = frequently are. In fact, coming from the security area the idea of an MTI for life is = really odd to me. MTI cipher suites get changed often enough that many = security protocols don=92t include the MTI algorithms in the base spec. = For ones that die hard they get the draft names like = draft-ietf-krb-wg-des-die-die-die, which became RFC 6649, that = deprecates the use of DES the original MTI in Kerberos 5. On the flip side, there are plenty of RFCs that either hint at or = specify future requirements (a non exhaustive list): 1) RFCs 4305/4835/7321, RFC 5750 and 5751 use MUST+/-, SHOULD+/-, etc. = to telegraph what algorithms future versions are likely to support. 2) BGP-3/4(RFC 1163/4271) specify that future verions MUST retain the = format of the OPEN and NOTIFICATION messages. 3) LDAP specifications (RFC 1487/1777) indicated new authentication = mechanisms would be included. 4) Diameter (RFC 3588) says future versions may mandate that clients = support SCTP. 5) DOCSIS (RFC 4131) says future versions are expected to support IPv6. 6) NETCONF over TLS (RFC 5539) applies to a particular version but says = it applies to future versions as well and the later MTI cipher suite = MUST be supported. 7) MRCPv2 (RFC6787) includes the following "If in the future voice = biometric providers standardize on such a mechanism, then a future = version of MRCP can mandate it.=94=20 Cheers, spt= From nobody Sat Dec 13 11:15:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7B41A1B39 for ; Sat, 13 Dec 2014 11:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.422 X-Spam-Level: X-Spam-Status: No, score=0.422 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQsesbzW60Lg for ; Sat, 13 Dec 2014 11:15:16 -0800 (PST) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [70.39.232.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E2B51A1A03 for ; Sat, 13 Dec 2014 11:15:16 -0800 (PST) Received: from mail-pd0-f171.google.com ([209.85.192.171]:45263) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1Xzs9k-0007Gb-0L for rtcweb@ietf.org; Sat, 13 Dec 2014 14:15:15 -0500 Received: by mail-pd0-f171.google.com with SMTP id y13so9127942pdi.16 for ; Sat, 13 Dec 2014 11:15:04 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.70.43.138 with SMTP id w10mr37200471pdl.50.1418498104732; Sat, 13 Dec 2014 11:15:04 -0800 (PST) Received: by 10.70.36.205 with HTTP; Sat, 13 Dec 2014 11:15:04 -0800 (PST) In-Reply-To: References: <548AD22D.7040104@it.aoyama.ac.jp> <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> Date: Sat, 13 Dec 2014 14:15:04 -0500 Message-ID: From: Jonathan Rosenberg To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=047d7bfea98aa5b693050a1dd3ba X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net X-Get-Message-Sender-Via: ecbiz71.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4xFMh2S29sL5OFMy9Yprv8_dMR4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 13 Dec 2014 19:15:18 -0000 --047d7bfea98aa5b693050a1dd3ba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support the rough consensus reached in the room in Honolulu. -Jonathan R. On Fri, Dec 12, 2014 at 9:57 AM, I=C3=B1aki Baz Castillo wr= ote: > > 2014-12-12 15:45 GMT+01:00 Adam Roach : > > I think that the future-looking clause is one of the wartiest parts of > this > > proposal. On the other hand, it's the one thing that makes it different > than > > things we've considered in the past, and is clearly a key part of what > > allowed it to gather the support that it has so far. So: ugly, necessar= y, > > and sufficient. > > > > Given that it's sufficient to gain the current level of support, the ne= ed > > for change is unclear. > > > > Given that it's necessary, we can't remove it, or the whole thing falls > > apart. > > > > And, given that it's ugly, making it more expansive would only make the > > proposal qualitatively worse. > > > > There's no point trying to map out large decision trees for the future, > > especially since we've had such a contentious time coming to some > semblance > > of agreement on the current direction. Pushing more future-looking > decisions > > into the text would only serve to give us more things to disagree about= . > > > > And, as you point out, if something comes up in the future that > materially > > changes the landscape, it's completely within the purview of the IETF t= o > > apply rational analysis to make a decision based on the actual facts at > that > > time. > > That would sound really nice if the already chosen MTI codecs were > 100% RF with no licensing/patent issues. That's not the case so IMHO > the door should remain open for, at least, the inclusion of a new 100% > RF video codec. > > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --=20 Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net --047d7bfea98aa5b693050a1dd3ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the rough consensus reached in the room in Honol= ulu.

-Jonathan R.
=
On Fri, Dec 12, 2014 at 9:57 AM, I=C3=B1aki = Baz Castillo <ibc@aliax.net> wrote:
2014-12-12 15:45 GMT+01:00 Adam Roach <adam@nostrum.com>:
> I think that the future-looking clause is one of the wartiest parts of= this
> proposal. On the other hand, it's the one thing that makes it diff= erent than
> things we've considered in the past, and is clearly a key part of = what
> allowed it to gather the support that it has so far. So: ugly, necessa= ry,
> and sufficient.
>
> Given that it's sufficient to gain the current level of support, t= he need
> for change is unclear.
>
> Given that it's necessary, we can't remove it, or the whole th= ing falls
> apart.
>
> And, given that it's ugly, making it more expansive would only mak= e the
> proposal qualitatively worse.
>
> There's no point trying to map out large decision trees for the fu= ture,
> especially since we've had such a contentious time coming to some = semblance
> of agreement on the current direction. Pushing more future-looking dec= isions
> into the text would only serve to give us more things to disagree abou= t.
>
> And, as you point out, if something comes up in the future that materi= ally
> changes the landscape, it's completely within the purview of the I= ETF to
> apply rational analysis to make a decision based on the actual facts a= t that
> time.

That would sound really nice if the already chosen MTI codecs were 100% RF with no licensing/patent issues. That's not the case so IMHO the door should remain open for, at least, the inclusion of a new 100%
RF video codec.


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

____________________________= ___________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net<= /a>
http://www.jdro= sen.net
--047d7bfea98aa5b693050a1dd3ba-- From nobody Sat Dec 13 16:47:20 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4B01A0389 for ; Sat, 13 Dec 2014 16:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-wTLXFXnktf for ; Sat, 13 Dec 2014 16:47:17 -0800 (PST) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872011A01E1 for ; Sat, 13 Dec 2014 16:47:17 -0800 (PST) Received: by mail-qg0-f48.google.com with SMTP id f51so7138690qge.35 for ; Sat, 13 Dec 2014 16:47:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=YrMPaz6opbxht+Wofg0toLwxOwolTtDn9WZp6cL7Ty0=; b=HXgl/tZCAf50w6iqlvQxpf855i1Zc9FLv7thYq5O5TWr2Tz6iMeHdwilzzXQ4Gjm+n EUEKMnCqS2X1+XsXX2v1cWsUbQWq6yRSheR2szPa8tHZPYR1rUxdxijpR7q1f5eu8DhR bkPQv7GGMIF0zdaDJh8FgXF4fNyAUPx8BedTGQE/O6vIW7tEUR9h04Hyj5cIs7QkkHyD ozaBEnTaLDMBHYx1hP5q8817tDyUHW21Lh1DDrVwr/9waSqsfZwNwSM650KI7X7N7KQa tn7sLeIkXZHwIG2UJ3iRoI+P6G2qpJSQbkZW9k3tINkd6kGv3lLg+nCZwf0zlTcHkylS 8MgQ== X-Gm-Message-State: ALoCoQmJecFDa3GnPrfqQDlInQU2qp4gEmlVqvkxQKol97PRZoXT1DvA2tteY0vUqz5LfoTi32D1 X-Received: by 10.140.49.107 with SMTP id p98mr41586589qga.20.1418518036754; Sat, 13 Dec 2014 16:47:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Sat, 13 Dec 2014 16:46:56 -0800 (PST) In-Reply-To: References: <548AD22D.7040104@it.aoyama.ac.jp> <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 14 Dec 2014 01:46:56 +0100 Message-ID: To: Jonathan Rosenberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/T8SRqdXPHYTJZmKR--OgV7RBT88 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 14 Dec 2014 00:47:18 -0000 2014-12-13 20:15 GMT+01:00 Jonathan Rosenberg : > I support the rough consensus reached in the room in Honolulu. Thanks Jonathan. Any other feedback about WebRTC in general? --=20 I=C3=B1aki Baz Castillo From nobody Sat Dec 13 16:58:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5E51A0389 for ; Sat, 13 Dec 2014 16:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_PIydH_7dWJ for ; Sat, 13 Dec 2014 16:58:53 -0800 (PST) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFDD81A036A for ; Sat, 13 Dec 2014 16:58:53 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id s7so6684324qap.6 for ; Sat, 13 Dec 2014 16:58:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=2zWlhjBbrAP7n9RecGO29zi9GVI8EUTGJEyoA66s0gs=; b=XozGQ39c1AoOTqp7UUmsvLlotbbvYXIeg33sbxGwdvqdr/o0H9VwWAoXx6HQY9wAQw a/CmlMw8IPGW4Bbmf2G17t5K1Yp0kdu5FW3fPW4tr7ZPHDfON0eoHO+5A/+8WnwIH9T3 f4kr8ohx89zWI4+NdfD/nvDxFGQLUuTjKUWpFPnru1LViozUEm8x8kOhrG1a2vua6IKF VjZtW5/OtYb8uNiVOPSNR/NAHWA3q39Y6vMfUG2xCsCA6MD3QKJ0pZxd0MY2GgmXVLLu Ti/be/W0I4RJFY+bNt1jpbu/rvZvXUwUolkUQ4ZoYqCNwbEjxEWVdaUwHlE02H0EX3Nd 6RCg== X-Gm-Message-State: ALoCoQlJtefd/WA45u4bLuySRrfjoQFr3kNFG5VHzEf4NmlxftNuA43p05bOhcwaqda/pohifkjr X-Received: by 10.229.37.136 with SMTP id x8mr44323552qcd.30.1418518732936; Sat, 13 Dec 2014 16:58:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Sat, 13 Dec 2014 16:58:32 -0800 (PST) In-Reply-To: References: <548AD22D.7040104@it.aoyama.ac.jp> <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 14 Dec 2014 01:58:32 +0100 Message-ID: To: Sean Turner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MNC3uGw5QRRFKnXNpfy1T7stXcM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 14 Dec 2014 00:58:54 -0000 2014-12-13 17:36 GMT+01:00 Sean Turner : > Just to be clear: "No plan" does not mean that the requirement is immuta= ble forever, just that we don't have a plan right now. MTI requirements in= IETF documents can always be updated, and they very frequently are. That sounds good, but I'm still waiting for a response to my question made yesterday: >> The rationale here is browser accommodation for very constrained "WebRT= C compatible" devices, which will most typically be concerned with browser = interoperation. The example that's been tossed around in this space is the = "WebRTC doorbell" -- when someone rings the bell, you navigate to its inter= face using WebRTC, and stream an image from a small, embedded camera. In th= ese kinds of very-low-cost devices, you're going to likely see hardware vid= eo encoding (e.g. do a web search for NVS2200), which will likely be one co= dec or another, but not both. >> >> The goal is continued browser support for such devices in perpetuity. > May I know where in the WG chapter is that goal defined please? If the above is a real goal of this WG (is it?) then that means that future revisions should respect it ad aternum. This is: even if in the future a new *good* video codec 100% RF appears, implementations MUST still include both VP8 and H264 (and deal with patent/licensing issues, which is a show stopper for certain players in the web ecosystem). --=20 I=C3=B1aki Baz Castillo From nobody Sun Dec 14 19:43:08 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950561A03F9; Sun, 14 Dec 2014 19:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNvIkkShIF4x; Sun, 14 Dec 2014 19:43:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D5A1A038E; Sun, 14 Dec 2014 19:43:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141215034305.14105.51004.idtracker@ietfa.amsl.com> Date: Sun, 14 Dec 2014 19:43:05 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0XANHS-PrROeb_ZnpCSRXoUrxc0 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 03:43:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : STUN Usage for Consent Freshness Authors : Muthu Arul Mozhi Perumal Dan Wing Ram Mohan Ravindranath Tirumaleswar Reddy Martin Thomson Filename : draft-ietf-rtcweb-stun-consent-freshness-10.txt Pages : 9 Date : 2014-12-14 Abstract: To prevent sending excessive traffic to an endpoint, periodic consent needs to be obtained from that remote endpoint. This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 15 02:06:09 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433FD1A1AC3 for ; Mon, 15 Dec 2014 02:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhOwfYiT1Z_7 for ; Mon, 15 Dec 2014 02:06:06 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 4494B1A1AC2 for ; Mon, 15 Dec 2014 02:06:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 322A67C35E8 for ; Mon, 15 Dec 2014 11:06:05 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if5c3uzZWveX for ; Mon, 15 Dec 2014 11:06:03 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:d542:904a:f9e9:3aec] (unknown [IPv6:2001:470:de0a:27:d542:904a:f9e9:3aec]) by mork.alvestrand.no (Postfix) with ESMTPSA id DEFC57C363A for ; Mon, 15 Dec 2014 11:06:02 +0100 (CET) Message-ID: <548EB28A.4040901@alvestrand.no> Date: Mon, 15 Dec 2014 11:06:02 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <548AD22D.7040104@it.aoyama.ac.jp> <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/G8v0v-3USQI7g7_f3zAM86V7ehk Subject: [rtcweb] Please change the subject! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 10:06:08 -0000 On the "confirming sense of the room" thread, there have been lots of messages over the last few days - but only *one* new position stated. Could those who wish to comment further (like the 3 levels of poster below) PLEASE change the subject line? Den 14. des. 2014 01:58, skrev Iñaki Baz Castillo: > 2014-12-13 17:36 GMT+01:00 Sean Turner : >> Just to be clear: "No plan" does not mean that the requirement is immutable forever, just that we don't have a plan right now. MTI requirements in IETF documents can always be updated, and they very frequently are. > > That sounds good, but I'm still waiting for a response to my question > made yesterday: > >>> The rationale here is browser accommodation for very constrained "WebRTC compatible" devices, which will most typically be concerned with browser interoperation. The example that's been tossed around in this space is the "WebRTC doorbell" -- when someone rings the bell, you navigate to its interface using WebRTC, and stream an image from a small, embedded camera. In these kinds of very-low-cost devices, you're going to likely see hardware video encoding (e.g. do a web search for NVS2200), which will likely be one codec or another, but not both. >>> >>> The goal is continued browser support for such devices in perpetuity. > >> May I know where in the WG chapter is that goal defined please? > > > If the above is a real goal of this WG (is it?) then that means that > future revisions should respect it ad aternum. This is: even if in the > future a new *good* video codec 100% RF appears, implementations MUST > still include both VP8 and H264 (and deal with patent/licensing > issues, which is a show stopper for certain players in the web > ecosystem). > > > From nobody Mon Dec 15 05:24:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D6B1A1BE7 for ; Mon, 15 Dec 2014 05:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuKtZjfpVkfi for ; Mon, 15 Dec 2014 05:24:37 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9446A1A1AA9 for ; Mon, 15 Dec 2014 05:24:36 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-60-548ee1126304 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F5.61.04231.211EE845; Mon, 15 Dec 2014 14:24:34 +0100 (CET) Received: from ESESSMB208.ericsson.se ([169.254.8.173]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 14:24:34 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-10.txt Thread-Index: AQHQGBlC0BiuLXvjskuFnB/jAs9l3ZyQonNA Date: Mon, 15 Dec 2014 13:24:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5C7B1D@ESESSMB208.ericsson.se> References: <20141215034305.14105.51004.idtracker@ietfa.amsl.com> In-Reply-To: <20141215034305.14105.51004.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvja7Qw74Qg71L9CzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxq6eNqaC6RIV//76NzC+Fupi5OSQEDCR6FvbwAJhi0lcuLee rYuRi0NI4AijxMYtJ6CcJYwSn49eB6ri4GATsJDo/qcN0iAioC5x+eEFdpCwsECwxNYjwRDh EImvv56yQdhGEk0nloLZLAKqEp/fLmQFKecV8JX4sckfJCwk4Cgxb/05JhCbU8BJ4vOSm+wg NiPQOd9PrQGLMwuIS9x6Mp8J4kwBiSV7zjND2KISLx//Y4WwlSR+bLjEAlGvI7Fg9yc2CFtb YtnC12D1vAKCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG0eLU4uLcdCNjvdSizOTi4vw8 vbzUkk2MwGg4uOW37g7G1a8dDzEKcDAq8fAWiPWFCLEmlhVX5h5ilOZgURLnXXRuXrCQQHpi SWp2ampBalF8UWlOavEhRiYOTqkGxjU5n+yy7AQm7NHhUazoOl+Vxf5613Wbs0ypqXss4iMa ir05Pzyyebpwj3dBucnr/CWrXLanKDkc3WvWIXGywLvKO01h8fuJPAfD5LQ5Lm3abrV49vnS i8X8fy6uffeC/3eyI2dEQ+nRhMlbjnP88kxpnuR448y3iU6fd0ez35iiX3par0QwWYmlOCPR UIu5qDgRAEf0Ov1nAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eb02xSPdfjOLOy8HuSxk6wXE6e0 Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 13:24:40 -0000 Hi, Thank you very much for addressing my comments! :) However, I still have an issue with the text saying: "A WebRTC implementation [I-D.ietf-rtcweb-overview], which implements full ICE, MUST perform consent freshness test using STUN request/ response as described below:" First, I question whether this document should make normative requirements = on WebRTC? Shouldn't some WebRTC document instead mandate the usage? Second, what if a non-WebRTC implementation wants to use the mechanism? The= procedures are described below the text above, so the way I read it they o= nly apply to WebRTC implementations. Third, *IF* the scope of the mechanism is only WebRTC (perhaps it is, and I= have misunderstood), I think we need to have some explicit text indicating= that. Fourth, if you want to use terminology from [I-D.ietf-rtcweb-overview] you = need to make sure it's aligned with that draft. I don't think "WebRTC imple= mentation" exists in draft-rtcweb-overview-13, so you would have to define = that as a browser, non-browser or compatible endpoint (or, use those termin= ologies). Thanks! Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: 15. joulukuuta 2014 5:43 To: i-d-announce@ietf.org Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-10.t= xt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : STUN Usage for Consent Freshness Authors : Muthu Arul Mozhi Perumal Dan Wing Ram Mohan Ravindranath Tirumaleswar Reddy Martin Thomson Filename : draft-ietf-rtcweb-stun-consent-freshness-10.txt Pages : 9 Date : 2014-12-14 Abstract: To prevent sending excessive traffic to an endpoint, periodic consent needs to be obtained from that remote endpoint. This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshness= -10 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Dec 15 05:44:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E431A6FC7 for ; Mon, 15 Dec 2014 05:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u18BOMcrPRuO for ; Mon, 15 Dec 2014 05:44:01 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 18D3E1A6FB5 for ; Mon, 15 Dec 2014 05:43:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id EB3AE7C36D1 for ; Mon, 15 Dec 2014 14:43:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gS-XfOAz5hC for ; Mon, 15 Dec 2014 14:43:51 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:1c71:93e8:8434:4216] (unknown [IPv6:2001:470:de0a:27:1c71:93e8:8434:4216]) by mork.alvestrand.no (Postfix) with ESMTPSA id A89737C35B4 for ; Mon, 15 Dec 2014 14:43:51 +0100 (CET) Message-ID: <548EE596.5090503@alvestrand.no> Date: Mon, 15 Dec 2014 14:43:50 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20141215034305.14105.51004.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D5C7B1D@ESESSMB208.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5C7B1D@ESESSMB208.ericsson.se> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DqzR3ttH9uReqX0QXCHVj26xIHE Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 13:44:04 -0000 Den 15. des. 2014 14:24, skrev Christer Holmberg: > Hi, > > Thank you very much for addressing my comments! :) > > However, I still have an issue with the text saying: > > "A WebRTC implementation [I-D.ietf-rtcweb-overview], which implements > full ICE, MUST perform consent freshness test using STUN request/ > response as described below:" > > > First, I question whether this document should make normative requirements on WebRTC? Shouldn't some WebRTC document instead mandate the usage? > I think this sentence, suitably massaged, belongs in -overview. I'll make sure it gets there. > Second, what if a non-WebRTC implementation wants to use the mechanism? The procedures are described below the text above, so the way I read it they only apply to WebRTC implementations. > > Third, *IF* the scope of the mechanism is only WebRTC (perhaps it is, and I have misunderstood), I think we need to have some explicit text indicating that. > > Fourth, if you want to use terminology from [I-D.ietf-rtcweb-overview] you need to make sure it's aligned with that draft. I don't think "WebRTC implementation" exists in draft-rtcweb-overview-13, so you would have to define that as a browser, non-browser or compatible endpoint (or, use those terminologies). > The correct nomenclature at the moment is "WebRTC endpoint", which contains both browsers and non-browsers. > Thanks! > > Regards, > > Christer > > > > > > > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: 15. joulukuuta 2014 5:43 > To: i-d-announce@ietf.org > Cc: rtcweb@ietf.org > Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-10.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. > > Title : STUN Usage for Consent Freshness > Authors : Muthu Arul Mozhi Perumal > Dan Wing > Ram Mohan Ravindranath > Tirumaleswar Reddy > Martin Thomson > Filename : draft-ietf-rtcweb-stun-consent-freshness-10.txt > Pages : 9 > Date : 2014-12-14 > > Abstract: > To prevent sending excessive traffic to an endpoint, periodic consent > needs to be obtained from that remote endpoint. > > This document describes a consent mechanism using a new Session > Traversal Utilities for NAT (STUN) usage. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness-10 > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 > From nobody Mon Dec 15 05:45:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305291A6F99 for ; Mon, 15 Dec 2014 05:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLTLrXjCZj58 for ; Mon, 15 Dec 2014 05:45:31 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0DBB1A6FCE for ; Mon, 15 Dec 2014 05:45:25 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id f15so10056430lbj.37 for ; Mon, 15 Dec 2014 05:45:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6D3YAJGWZP9qrez+MkmsY4E+42JKsBj/PK+h1sRuTyY=; b=mvTsCe/8T9CH6CyediPUH9p4fa42TX0r71q4et/PpltCrBnftb56sv8sOVJNDrFzS5 i0Yi/W+pL3y5+4bDZtR7M+mDbM33a/fD1zQVCio4ylHQ13rMIIpMdO9JOGYc+ODnxfzi NYgh6qr4HEThT62Fzsk4jQkozgfYNHFUJHyOPgWg/MEpXx7Fyf9ZBn9EAPdKiju23+pr ObGjHzvQY0yzSmNLr35IuUIU9Ega5EO4WLoQqOJDbI8mHQVSrAmDyPEQ3Rqf2818yMAY BR6DMkrkz3NiJkslg0afj7AWbYxLJdeFQCdwjAM86Pd9N8+rrj2EcXwKH2goQknR7j8g +l5Q== X-Gm-Message-State: ALoCoQl8VqqEO2OYY+CTcXPfSZ+bPTJoSMQ8LjhlaKAjnLSygLevGZWQH/8axCg4Ys/F8gpSoGx4 MIME-Version: 1.0 X-Received: by 10.152.45.41 with SMTP id j9mr30765212lam.59.1418651124116; Mon, 15 Dec 2014 05:45:24 -0800 (PST) Received: by 10.25.84.145 with HTTP; Mon, 15 Dec 2014 05:45:24 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5C7B1D@ESESSMB208.ericsson.se> References: <20141215034305.14105.51004.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D5C7B1D@ESESSMB208.ericsson.se> Date: Mon, 15 Dec 2014 08:45:24 -0500 Message-ID: From: Simon Perreault To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c29bca50449c050a4174c6 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/iXwduBcd9-vx4_grFd3PiIuHlj4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 13:45:33 -0000 --001a11c29bca50449c050a4174c6 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 15, 2014 at 8:24 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > However, I still have an issue with the text saying: > > "A WebRTC implementation [I-D.ietf-rtcweb-overview], which > implements > full ICE, MUST perform consent freshness test using STUN request/ > response as described below:" > > > First, I question whether this document should make normative requirements > on WebRTC? Shouldn't some WebRTC document instead mandate the usage? > > Second, what if a non-WebRTC implementation wants to use the mechanism? > The procedures are described below the text above, so the way I read it > they only apply to WebRTC implementations. > > Third, *IF* the scope of the mechanism is only WebRTC (perhaps it is, and > I have misunderstood), I think we need to have some explicit text > indicating that. > > Fourth, if you want to use terminology from [I-D.ietf-rtcweb-overview] you > need to make sure it's aligned with that draft. I don't think "WebRTC > implementation" exists in draft-rtcweb-overview-13, so you would have to > define that as a browser, non-browser or compatible endpoint (or, use those > terminologies). > Fully agreed. Fifth issue: The rtcweb-overview reference would need to be normative (it is currently informative). I suggest to simply remove the whole paragraph and the reference. Simon --001a11c29bca50449c050a4174c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Dec 15, 2014 at 8:24 AM, Christer Holmberg <christer.= holmberg@ericsson.com> wrote:
<= div id=3D":bi" class=3D"a3s" style=3D"overflow:hidden">However, I still hav= e an issue with the text saying:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "A WebRTC implementation [I-D.ietf-rtcweb-= overview], which implements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 full ICE, MUST perform consent freshness test u= sing STUN request/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 response as described below:"


First, I question whether this document should make normative requirements = on WebRTC? Shouldn't some WebRTC document instead mandate the usage?
Second, what if a non-WebRTC implementation wants to use the mechanism? The= procedures are described below the text above, so the way I read it they o= nly apply to WebRTC implementations.

Third, *IF* the scope of the mechanism is only WebRTC (perhaps it is, and I= have misunderstood), I think we need to have some explicit text indicating= that.

Fourth, if you want to use terminology from [I-D.ietf-rtcweb-overview] you = need to make sure it's aligned with that draft. I don't think "= ;WebRTC implementation" exists in draft-rtcweb-overview-13, so you wou= ld have to define that as a browser, non-browser or compatible endpoint (or= , use those terminologies).

Fully agreed.
=

Fifth issue= : The rtcweb-overview reference would need to be normative (it is currently= informative).

I suggest to simply remove the whole paragraph and the reference.<= /div>

Simon<= /div>
--001a11c29bca50449c050a4174c6-- From nobody Mon Dec 15 05:49:35 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9B51A6FC7 for ; Mon, 15 Dec 2014 05:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCUFU9GMQu9H for ; Mon, 15 Dec 2014 05:49:30 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77FCE1A6FC2 for ; Mon, 15 Dec 2014 05:49:30 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-29-548ee6e8c5c3 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F8.BD.04076.8E6EE845; Mon, 15 Dec 2014 14:49:28 +0100 (CET) Received: from ESESSMB208.ericsson.se ([169.254.8.173]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 14:49:27 +0100 From: Christer Holmberg To: Simon Perreault Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-10.txt Thread-Index: AQHQGBlC0BiuLXvjskuFnB/jAs9l3ZyQonNA///3VwCAABGNsA== Date: Mon, 15 Dec 2014 13:49:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5CACA0@ESESSMB208.ericsson.se> References: <20141215034305.14105.51004.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D5C7B1D@ESESSMB208.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+Jvje6LZ30hBtc3ilis/dfObnH9SqgD k8eSJT+ZPP7NecocwBTFZZOSmpNZllqkb5fAlbHrczNrwTGmiqf35rA1MO5h6mLk5JAQMJG4 0v6NHcIWk7hwbz1bFyMXh5DAEUaJn63f2SGcJYwS348sYuli5OBgE7CQ6P6nDdIgIqApsWr+ N7BBzALqEncWn2MHKREWCJbYeiQYoiRE4uuvp2wQtpPEtuXrmEFsFgFViS9PpoG18gr4SjR2 PmSEWHWGUeLg/PtMIHM4BQIl/nwKB6lhBLrt+6k1UKvEJW49mQ91v4DEkj3nmSFsUYmXj/+x QthKEj82XAK7mBnozPW79CFaFSWmdD9kh1grKHFy5hOWCYxis5BMnYXQMQtJxywkHQsYWVYx ihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBMbNwS2/rXYwHnzueIhRgINRiYe3QKwvRIg1say4 MvcQozQHi5I478Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MNoyi7y9VbwuYEJDYyHH Em/e2VNnMB95W51RESk4Vzfnk6KHYsUv095l6uf+FS2YbfKnebXFTmuvlwfDjIP4V5xPX2xk yLAiwn+NV28cm+hsJhEdbrXj9mc3byt3OuSvv2epj/Ky28wbN0f+PMedsbVpwabptvvDYvNn 3/z0Vzf4+fTlzWdXWSixFGckGmoxFxUnAgBFElUyfAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/reM1gNlHQq_Tj3HzggLANDjzr2I Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 13:49:32 -0000 SGksDQoNCj5JIHN1Z2dlc3QgdG8gc2ltcGx5IHJlbW92ZSB0aGUgd2hvbGUgcGFyYWdyYXBoIGFu ZCB0aGUgcmVmZXJlbmNlLg0KDQpUaGF0IGlzIG15IHN1Z2dlc3Rpb24gYWxzbyA6KQ0KDQpBcyBI YXJhbGQgaW5kaWNhdGVkIGhlIHdpbGwgYWRkIHRleHQgdG8gdGhlIG92ZXJ2aWV3IGRvY3VtZW50 IGFib3V0IHRoZSB1c2FnZSwgbm90aGluZyBpcyAibG9zdCIuDQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQoNCg== From nobody Mon Dec 15 06:42:32 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FC51A1B64 for ; Mon, 15 Dec 2014 06:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.508 X-Spam-Level: X-Spam-Status: No, score=-0.508 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, TVD_SPACE_RATIO=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PkkYCM7dTfA for ; Mon, 15 Dec 2014 06:42:29 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 882941A1AB4 for ; Mon, 15 Dec 2014 06:42:29 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 7D1BA23F04E5 for ; Mon, 15 Dec 2014 15:42:28 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.192]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 15:42:28 +0100 From: "Hutton, Andrew" To: "rtcweb@ietf.org" Thread-Topic: rtcweb-transports reference to TRAM discovery Thread-Index: AdAYdVah0SPsel0ORrys7Zw+IDeNbw== Date: Mon, 15 Dec 2014 14:42:27 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF1E63FB08MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PNBObsebGWR5-C_g0YLArqfIy3g Subject: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 14:42:31 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF1E63FB08MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am thinking that https://tools.ietf.org/html/draft-ietf-rtcweb-transports= -07#section-3.4 should include a requirement that a WebRTC Browser MUST sup= port the TURN server discovery as described in https://tools.ietf.org/html/= draft-ietf-tram-turn-server-discovery-00. Andy --_000_9F33F40F6F2CD847824537F3C4E37DDF1E63FB08MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I am thinking that https://tools.ietf= .org/html/draft-ietf-rtcweb-transports-07#section-3.4 should= include a requirement that a WebRTC Browser MUST support the TURN server discovery as described in https://tools.ietf.org/html/draft-ietf-tram-turn-server-d= iscovery-00.
 
 
Andy
 
 --_000_9F33F40F6F2CD847824537F3C4E37DDF1E63FB08MCHP04MSXglobal_-- From nobody Mon Dec 15 06:52:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CD01A1B64 for ; Mon, 15 Dec 2014 06:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjP7BNW9adUL for ; Mon, 15 Dec 2014 06:52:07 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B7201A6FE7 for ; Mon, 15 Dec 2014 06:52:07 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id l18so14556702wgh.26 for ; Mon, 15 Dec 2014 06:52:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3UTExqgkhQ1u3bzXO6sxA80wmsyzpy/eB/7CFivWRT4=; b=0v94XSM7CXi3HQ5UvYhgqTEPXIXWuPra5Z6kHg180k7MhrOBAnMR6Xu/FML3WtJaJX peZMAcDHrK9cpHJJz+vEGNGQr+EPJKIOvEvf/W8xEwVux4niNVv2ed1gacPWiDLRESiP fT9qpoqQ/oun4F1qaow12QljV6f88Uuph9ONoTT5/5LLtTauCnrB3ISiysVgDJkzQvto KWs6In2cJbjdH9xMUZ3ZRHQsXjqVD5L+nFmZZerOYQJFiJLM2IXtd0OK3W/hcSCkm9Rh T7fWV8Nyd0flNoOhItlHfynrr2LxELi0b2eAV3N9KEjBDiXigmqA4+B028+MvQ0cAwJP MKTw== MIME-Version: 1.0 X-Received: by 10.180.211.201 with SMTP id ne9mr31500900wic.30.1418655126184; Mon, 15 Dec 2014 06:52:06 -0800 (PST) Received: by 10.180.76.242 with HTTP; Mon, 15 Dec 2014 06:52:06 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5CACA0@ESESSMB208.ericsson.se> References: <20141215034305.14105.51004.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D5C7B1D@ESESSMB208.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5CACA0@ESESSMB208.ericsson.se> Date: Mon, 15 Dec 2014 20:22:06 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c266d6dae884050a4262df Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nD05z_IXIKR-OGzUAzMdU7uWBco Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 14:52:09 -0000 --001a11c266d6dae884050a4262df Content-Type: text/plain; charset=UTF-8 We discussed this earlier in the WG: http://www.ietf.org/mail-archive/web/rtcweb/current/msg13020.html In fact, -08 had the following non-normative text: A WebRTC implementation [I-D.ietf-rtcweb-overview], which implements full ICE, performs consent freshness test using STUN request/response as described below: I think the text in -10 can be replaced with: A full ICE implementation performs consent freshness test using STUN request/response as described below: And the security-arch / overview documents can specify how it applies to WebRTC. Muthu On Mon, Dec 15, 2014 at 7:19 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > >I suggest to simply remove the whole paragraph and the reference. > > That is my suggestion also :) > > As Harald indicated he will add text to the overview document about the > usage, nothing is "lost". > > Regards, > > Christer > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c266d6dae884050a4262df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We discussed this earlier in the WG:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg13020.html=

In fact, -08 had the following non-normative text= :
=C2=A0 =C2=A0A WebRTC implementatio= n [I-D.ietf-rtcweb-overview], which implements
=C2=A0 =C2=A0full ICE, performs consent freshness test using STUN req= uest/response
=C2=A0 =C2=A0as described b= elow:

I think the text in -10 can be replaced with:
=C2=A0 =C2=A0A full ICE implementatio= n performs consent freshness test using STUN=C2=A0
=C2=A0 =C2=A0request/response as described below:

And the security-= arch / overview documents can specify how it applies to WebRTC.

Muthu

= On Mon, Dec 15, 2014 at 7:19 PM, Christer Holmberg <christer.= holmberg@ericsson.com> wrote:
Hi,

>I suggest to simply remove the whole paragraph and the reference.

That is my suggestion also :)

As Harald indicated he will add text to the overview document about the usa= ge, nothing is "lost".

Regards,

Christer

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--001a11c266d6dae884050a4262df-- From nobody Mon Dec 15 07:45:41 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACDF1A6FFD for ; Mon, 15 Dec 2014 07:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlCKRYYOWHhm for ; Mon, 15 Dec 2014 07:45:37 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B0F1A1BE0 for ; Mon, 15 Dec 2014 07:45:37 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so9461709wiv.13 for ; Mon, 15 Dec 2014 07:45:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=li+NEpsxdAZL6/kD1ajWO713/idhBHlxlD0a+FKN5oc=; b=NIPm69nHfBc9BErm03q46zWLz+nLY5p0hKVaXWU2exi6eXXKAEWoAMN9eKcrB/lFiN bo3nzE2rdXpF1+qninvE4IjIL/Hxp5KEGVUGoj8b7ga68zercUslN1f92CuVK9/Zsny4 gKHFg//JL2GokdILdJ52sSI3mKQobsonWJa4CZ+DpU4hYNPgppFGMoWRT4YM7xtnrrmQ hF78MEZWwatHP0LSIg5AY78fYkh1bsqzdX0sw7rp3nVOiVfRh6QiBODu1M/ZASKo0m5h 74jXb6+TsZutYofFCWTZxYLez8cuK3c0W9XvPgbYw54Yn0sVRC+szL1eSgU+WRBbju13 xprQ== X-Gm-Message-State: ALoCoQn+m3BeZv2bj7w832l8w2i05qM8iZvcsqHwTiA4cXKb9P2T04YFItvZF9JhoLV8JNW4+HGD X-Received: by 10.181.13.42 with SMTP id ev10mr31868692wid.78.1418658334692; Mon, 15 Dec 2014 07:45:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Mon, 15 Dec 2014 07:44:53 -0800 (PST) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> From: Eric Rescorla Date: Mon, 15 Dec 2014 07:44:53 -0800 Message-ID: To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=f46d04388df118ed52050a4322f4 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3I5uD-f79ituUf5DKaUcfhHc3Qs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 15:45:39 -0000 --f46d04388df118ed52050a4322f4 Content-Type: text/plain; charset=UTF-8 I do not believe that this is an appropriate requirement -Ekr On Mon, Dec 15, 2014 at 6:42 AM, Hutton, Andrew wrote: > > I am thinking that > *https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section-3.4* > > should include a requirement that a WebRTC Browser MUST support the TURN > server discovery as described in > *https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00* > . > > > Andy > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --f46d04388df118ed52050a4322f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I do not believe that this is an appropriate requirement
-Ekr


On Mon, Dec 15, 2014 at 6:42 AM, Hutton, An= drew <andrew.hutton@unify.com> wrote:
I am thinking that = https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section-3.4= should include a requirement that a WebRTC Browser MUST support the TURN server discovery as described in https://tools.ietf.org/html/draft-ietf-= tram-turn-server-discovery-00.
=C2=A0
=C2=A0
Andy
=C2=A0

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--f46d04388df118ed52050a4322f4-- From nobody Mon Dec 15 07:49:23 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079D31A7023 for ; Mon, 15 Dec 2014 07:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIi62uqPo4qc for ; Mon, 15 Dec 2014 07:49:21 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8AC71A7016 for ; Mon, 15 Dec 2014 07:49:20 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id f15so10292483lbj.37 for ; Mon, 15 Dec 2014 07:49:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aKR71y7ZzsDu798V8CBdyWOf8dw4UidyWSdLfHrY/Bc=; b=QiqBiJxyIJ8NMSxn5hnD3Q4FmKrthGMuOfq6aLnF4Z9JdIbkq7DSP9kAYxQBaC4r3t pcusUc3/kpqqLjJhe0+SFM4k/lOCaDR4pdKJlM5+6KHPNii1OETe7YgTq/69V3iaFIHv ZnYuNecXHS+IIRdBveaKZzS/7vla9U9xxZcPz8pr9wDsexUuTLoo2Se9quv5jhLDUB+6 +QjWvkmgMbYYdTtY14LJPAZQPrQ7MU6QTa0Nq4dT/owYYdcFq64e9zVGOtInmHAteMgK +tiiekE385VWUiPmJmMNIhEHR3x3J1pLDZSHqc3WQ22+GXoFgTQOM2vGykKingxMmvpw glcQ== X-Gm-Message-State: ALoCoQnRMV1T7jbS+Sj3ml/S0laeO68hG0S1cogQw9iebI0lEqrfdH0czgjHf+eMWT6cgRXr7vRw MIME-Version: 1.0 X-Received: by 10.152.44.129 with SMTP id e1mr11886147lam.43.1418658559216; Mon, 15 Dec 2014 07:49:19 -0800 (PST) Received: by 10.25.84.145 with HTTP; Mon, 15 Dec 2014 07:49:19 -0800 (PST) In-Reply-To: References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> Date: Mon, 15 Dec 2014 10:49:19 -0500 Message-ID: From: Simon Perreault To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e0160bc387ae623050a432ffb Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/55fwriFS7-fIDMdLEsZvB1aqj0U Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 15:49:22 -0000 --089e0160bc387ae623050a432ffb Content-Type: text/plain; charset=UTF-8 On Mon, Dec 15, 2014 at 10:44 AM, Eric Rescorla wrote: > > I do not believe that this is an appropriate requirement Care to say why? Thanks, Simon --089e0160bc387ae623050a432ffb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Dec 15, 2014 at 10:44 AM, Eric Rescorla <ekr@rtfm.com> wr= ote:
I do not believe that this is an appropr= iate requirement

Care to say why?

Thanks,
Simon
--089e0160bc387ae623050a432ffb-- From nobody Mon Dec 15 07:56:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0A61A7021 for ; Mon, 15 Dec 2014 07:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIqrcapRB-5c for ; Mon, 15 Dec 2014 07:56:29 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id C170B1A1AFB for ; Mon, 15 Dec 2014 07:56:28 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id DB1CC1EB851B; Mon, 15 Dec 2014 16:56:27 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.192]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 16:56:27 +0100 From: "Hutton, Andrew" To: Simon Perreault , Eric Rescorla Thread-Topic: [rtcweb] rtcweb-transports reference to TRAM discovery Thread-Index: AdAYdVah0SPsel0ORrys7Zw+IDeNbwAAFj2AAAAnpIAAAkCNAA== Date: Mon, 15 Dec 2014 15:56:26 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E63FD67@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF1E63FD67MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uKN-xfAHMpXGYRf6fsGb9YMxeFE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 15:56:31 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF1E63FD67MCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgQWxzbyB3b25kZXJpbmcgd2h5IGl0IGlzIG5vdCBhcHByb3ByaWF0ZT8NCg0KRjIwIGluIHRo ZSByZXF1aXJlbWVudHMgZHJhZnQgc3RhdGVzOg0KDQpGMjAgICAgIFRoZSBicm93c2VyIG11c3Qg c3VwcG9ydCB0aGUgdXNlIG9mIFNUVU4gYW5kIFRVUk4NCiAgICAgICAgICAgc2VydmVycyB0aGF0 IGFyZSBzdXBwbGllZCBieSBlbnRpdGllcyBvdGhlciB0aGFuDQogICAgICAgICAgIHRoZSB3ZWIg YXBwbGljYXRpb24gKGkuZS4gdGhlIG5ldHdvcmsgcHJvdmlkZXIpLg0KDQpTbyBJIHdhcyB0aGlu a2luZyB0aGUgbmVlZCBmb3Igc3BlY2lmeWluZyB0aGUgZGlzY292ZXJ5IG1ldGhvZCB3b3VsZCBu b3QgYmUgY29udHJvdmVyc2lhbC4NCg0KQW5keQ0KDQoNCkZyb206IFNpbW9uIFBlcnJlYXVsdCBb bWFpbHRvOnNwZXJyZWF1bHRAaml2ZS5jb21dDQpTZW50OiAxNSBEZWNlbWJlciAyMDE0IDE1OjQ5 DQpUbzogRXJpYyBSZXNjb3JsYQ0KQ2M6IEh1dHRvbiwgQW5kcmV3OyBydGN3ZWJAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBydGN3ZWItdHJhbnNwb3J0cyByZWZlcmVuY2UgdG8gVFJB TSBkaXNjb3ZlcnkNCg0KDQpPbiBNb24sIERlYyAxNSwgMjAxNCBhdCAxMDo0NCBBTSwgRXJpYyBS ZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToNCkkgZG8g bm90IGJlbGlldmUgdGhhdCB0aGlzIGlzIGFuIGFwcHJvcHJpYXRlIHJlcXVpcmVtZW50DQoNCkNh cmUgdG8gc2F5IHdoeT8NCg0KVGhhbmtzLA0KU2ltb24NCg== --_000_9F33F40F6F2CD847824537F3C4E37DDF1E63FD67MCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5 bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+JiM0MzsxIEFsc28gd29uZGVyaW5nIHdoeSBpdCBpcyBub3QgYXBwcm9w cmlhdGU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5GMjAgaW4gdGhlIHJlcXVpcmVtZW50cyBkcmFmdCBzdGF0ZXM6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+RjIwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBicm93c2VyIG11c3Qgc3VwcG9ydCB0 aGUgdXNlIG9mIFNUVU4gYW5kIFRVUk48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZXJ2 ZXJzIHRoYXQgYXJlIHN1cHBsaWVkIGJ5IGVudGl0aWVzIG90aGVyIHRoYW48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB0aGUgd2ViIGFwcGxpY2F0aW9uIChpLmUuIHRoZSBuZXR3b3JrIHBy b3ZpZGVyKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIEkgd2FzIHRoaW5raW5nIHRoZSBuZWVkIGZvciBzcGVjaWZ5 aW5nIHRoZSBkaXNjb3ZlcnkgbWV0aG9kIHdvdWxkIG5vdCBiZSBjb250cm92ZXJzaWFsLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+QW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU2ltb24gUGVycmVhdWx0IFttYWls dG86c3BlcnJlYXVsdEBqaXZlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxNSBEZWNlbWJlciAy MDE0IDE1OjQ5PGJyPg0KPGI+VG86PC9iPiBFcmljIFJlc2NvcmxhPGJyPg0KPGI+Q2M6PC9iPiBI dXR0b24sIEFuZHJldzsgcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb cnRjd2ViXSBydGN3ZWItdHJhbnNwb3J0cyByZWZlcmVuY2UgdG8gVFJBTSBkaXNjb3Zlcnk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1v biwgRGVjIDE1LCAyMDE0IGF0IDEwOjQ0IEFNLCBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJt YWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIG5vdCBiZWxp ZXZlIHRoYXQgdGhpcyBpcyBhbiBhcHByb3ByaWF0ZSByZXF1aXJlbWVudDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpDYXJlIHRvIHNheSB3aHk/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5r cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNp bW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_9F33F40F6F2CD847824537F3C4E37DDF1E63FD67MCHP04MSXglobal_-- From nobody Mon Dec 15 08:37:02 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAEA1A6FC4 for ; Mon, 15 Dec 2014 08:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QYh1jEt8DLg for ; Mon, 15 Dec 2014 08:36:58 -0800 (PST) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC251A797C for ; Mon, 15 Dec 2014 08:36:58 -0800 (PST) Received: by mail-ig0-f176.google.com with SMTP id l13so5644815iga.15 for ; Mon, 15 Dec 2014 08:36:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hXbHZtJpX4kZz5VQ+iR/M0eIq23hgESO6yDFfJ8oY34=; b=Q5HqpnYLx2/fOy10/RsEaf6RlF9ylME2iN9cS1FJcn8DGeP3Lncuhs63S2ibX271mO +nLCbXUva/pcp8/sRI4Eb+1VMK2kPZOIjNqlhDVv9M/jEA6UctHqQspL1msbwy2hVtnT G4p0aB4B2S1+0P1/qnuIlqyq8E1W5WHvYmcnIiB4SjLjHL+jJB4Y95I/AUbJaFoJ763B 5bjgrpTXMpE5TEKcoEfjGuCU4Dn2xfkwiYqKRMZRYO1sx+LA26bGqZ2AoMMSZkhEbYDv XqjQQj7m3OlLE4zSi4wQ4rSgOuq3h+fgo1bsc54xt+OhUZ+C8Go3+IZWyo3fjQqwyg1A e0Sw== X-Gm-Message-State: ALoCoQkwVHlwnb0zINLp2egiCaOdaEzBoSKunuQRAkUhRZsxDIveq6htSkUZRR99wMA3logfSzDW X-Received: by 10.50.66.200 with SMTP id h8mr18815321igt.20.1418661418032; Mon, 15 Dec 2014 08:36:58 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id mv6sm2206718igb.10.2014.12.15.08.36.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Dec 2014 08:36:57 -0800 (PST) Message-ID: <548F0E28.8040503@andyet.net> Date: Mon, 15 Dec 2014 09:36:56 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Sean Turner References: <548AD22D.7040104@it.aoyama.ac.jp> <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5C5XDDucCkfDtzpbDQZ66TWbdGo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 16:37:00 -0000 On 12/13/14, 5:58 PM, Iñaki Baz Castillo wrote: > 2014-12-13 17:36 GMT+01:00 Sean Turner : >> Just to be clear: "No plan" does not mean that the requirement is >> immutable forever, just that we don't have a plan right now. MTI >> requirements in IETF documents can always be updated, and they very >> frequently are. > > That sounds good, but I'm still waiting for a response to my > question made yesterday: > >>> The rationale here is browser accommodation for very constrained >>> "WebRTC compatible" devices, which will most typically be >>> concerned with browser interoperation. The example that's been >>> tossed around in this space is the "WebRTC doorbell" -- when >>> someone rings the bell, you navigate to its interface using >>> WebRTC, and stream an image from a small, embedded camera. In >>> these kinds of very-low-cost devices, you're going to likely see >>> hardware video encoding (e.g. do a web search for NVS2200), which >>> will likely be one codec or another, but not both. >>> >>> The goal is continued browser support for such devices in >>> perpetuity. > >> May I know where in the WG chapter is that goal defined please? > > > If the above is a real goal of this WG (is it?) then that means that > future revisions should respect it ad aternum. This is: even if in > the future a new *good* video codec 100% RF appears, implementations > MUST still include both VP8 and H264 (and deal with patent/licensing > issues, which is a show stopper for certain players in the web > ecosystem). The IETF can *always* obsolete one RFC (e.g., one that says "dual-MTI for H.264 and VP8") with another RFC (e.g., one that says "no more dual-MTI for H.264 and VP8, we have much better options now"). That's a core aspect of the Internet Standards Process. Peter -- Peter Saint-Andre CTO @ &yet https://andyet.com/ From nobody Mon Dec 15 11:24:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36141A8763 for ; Mon, 15 Dec 2014 11:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBZ5r1eqY9KY for ; Mon, 15 Dec 2014 11:24:12 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8D61A8760 for ; Mon, 15 Dec 2014 11:24:12 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 90B41C94BF; Mon, 15 Dec 2014 14:24:09 -0500 (EST) Date: Mon, 15 Dec 2014 14:24:09 -0500 From: John Leslie To: Peter Saint-Andre - &yet Message-ID: <20141215192409.GN47023@verdi> References: <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> <548F0E28.8040503@andyet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <548F0E28.8040503@andyet.net> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/17ZIvlv2if5yKEUM7wk6cXuNAeQ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 19:24:13 -0000 Peter Saint-Andre - &yet wrote: > > > The IETF can *always* obsolete one RFC (e.g., one that says "dual-MTI > for H.264 and VP8") with another RFC (e.g., one that says "no more > dual-MTI for H.264 and VP8, we have much better options now"). That's a > core aspect of the Internet Standards Process. This is, of course, true... But we don't obsolete a MTI because "we have much better options": we obsolete a MTI because "nobody's using it anymore". We are all trusting, I hope, that VP9, H.265, etc. will "just be used in preference" as soon as two endpoints support them. I don't expect to revisit the MTI selection... (That is what we want, right?) -- John Leslie From nobody Mon Dec 15 13:37:46 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AF81A0062 for ; Mon, 15 Dec 2014 13:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LchmL4kAEce3 for ; Mon, 15 Dec 2014 13:37:43 -0800 (PST) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F331A0020 for ; Mon, 15 Dec 2014 13:37:43 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hl2so6682802igb.2 for ; Mon, 15 Dec 2014 13:37:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=c9G5c4Z27B8qvtfErCS+edq1U5EpskHXL8VJvAnwT7s=; b=a+as3M+5kPJR6I6mfXNPf0qBGR5BNPWE2GWGsfcfD2/A0R3oavLiTWY7GgRMrIL5ep FnxDmSJyC1cZO+kQ1uL2TXGViBeCsi9M5vSyA6qj6fVpAWhwNpnk++fSF2Mxmhhno2lV /vegohyg2IJO/tkonYI4/wZBQTvV5hiLGLXU8BkMsqzjukgLDY86Oz3ruZherwUrKtpL SOWTDzbLJWAY1k51iLVLLZ6btudpA50Gopkn/AASERaMpJxR/EKrSra/+wEHnmgeawmK VdDuvvUeaWHLJD9/1HQR7xN9Mtj8axIIqoxuZBsrDFqx8VHkCYCa+Yj9IzdtVujH1Go9 1IoA== X-Gm-Message-State: ALoCoQlUbsCDCZXA5+IHJgVVXg2vxhvWgTbAY4DDkBn0N/Yd3zXfuRyRQtNFr4AObZR3RYIPX0lZ X-Received: by 10.107.150.137 with SMTP id y131mr31366864iod.11.1418679462769; Mon, 15 Dec 2014 13:37:42 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id j4sm1738496igx.14.2014.12.15.13.37.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Dec 2014 13:37:42 -0800 (PST) Message-ID: <548F54A5.2060105@andyet.net> Date: Mon, 15 Dec 2014 14:37:41 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Leslie References: <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> In-Reply-To: <20141215192409.GN47023@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7cg2vk2tWdJp81kxer4Q3nU2wsc Cc: rtcweb@ietf.org Subject: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 21:37:44 -0000 On 12/15/14, 12:24 PM, John Leslie wrote: > Peter Saint-Andre - &yet wrote: >> >> >> The IETF can *always* obsolete one RFC (e.g., one that says "dual-MTI >> for H.264 and VP8") with another RFC (e.g., one that says "no more >> dual-MTI for H.264 and VP8, we have much better options now"). That's a >> core aspect of the Internet Standards Process. > > This is, of course, true... > > But we don't obsolete a MTI because "we have much better options": > we obsolete a MTI because "nobody's using it anymore". Actually we can obsolete an MTI for any reason we please, at long as there's IETF consensus to do so. > We are all trusting, I hope, that VP9, H.265, etc. will "just be > used in preference" as soon as two endpoints support them. > > I don't expect to revisit the MTI selection... I do. It's a question of when. > (That is what we > want, right?) Not as far as I can see. Ten years ago if we'd had this discussion, H.261 might have been MTI. Ten years from now, H.264 will seem ancient, too. I fully expect that someone in the IETF (perhaps not us) will revisit the MTI decision once we have better alternatives. Peter From nobody Mon Dec 15 14:03:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E6E1A0167 for ; Mon, 15 Dec 2014 14:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aemZrprqWWN for ; Mon, 15 Dec 2014 14:03:20 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E811A015F for ; Mon, 15 Dec 2014 14:03:19 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id rd18so11652156iec.22 for ; Mon, 15 Dec 2014 14:03:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1l6023rIE6TbV527o2gNpJv/dPJwSe3PzOk59z9aFHY=; b=BOyJJrMtBWi37+xXn0f3EDtOfutEAxYyzVvN/dWHrGrytavQxk2tuHtyJWz1rE3X+b QPRivRO74z/HbSXEfxBXpHfRR3CpyN1pqhyAoyObU6F0v5ypccV8CT7WcLc8O2GsiwqW dvkoJAd+BiYQX7bM4SeQ4f/X01VsQDI0IiLOv4hZRqeOQENsImNei9wfNrTQSXNdMfSW KVQDlgN9e/JFZcrFXBlJM9rTlLVX8VCxpzwziH4/HCv0ArXmCD/7sf4U+QNUWuhwy7VK DK4mYlVZchC/F2WbndL18+mYG2E38rNZ6L/tLAzAZtPhvvQq0kkyyUOkGm7ru2sd2jDC ZbKw== MIME-Version: 1.0 X-Received: by 10.42.11.15 with SMTP id s15mr23214692ics.18.1418680998987; Mon, 15 Dec 2014 14:03:18 -0800 (PST) Received: by 10.42.107.145 with HTTP; Mon, 15 Dec 2014 14:03:18 -0800 (PST) In-Reply-To: <548F54A5.2060105@andyet.net> References: <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> Date: Mon, 15 Dec 2014 14:03:18 -0800 Message-ID: From: Ted Hardie To: "Peter Saint-Andre - &yet" Content-Type: multipart/alternative; boundary=20cf30434866fe8d79050a486861 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DaU_5s1vq6TeIFduGWMsZ5u4MmU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 22:03:22 -0000 --20cf30434866fe8d79050a486861 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Dec 15, 2014 at 1:37 PM, Peter Saint-Andre - &yet wrote: > Not as far as I can see. > > Ten years ago if we'd had this discussion, H.261 might have been MTI. Ten > years from now, H.264 will seem ancient, too. > > I fully expect that someone in the IETF (perhaps not us) will revisit the > MTI decision once we have better alternatives. > > Peter > =E2=80=8BThe nice thing is that our current model allows us to have nice th= ings right away; as soon as they are in common, they may be selected by negotiation. What the MTI gives us is a way to avoid interoperability failure. So the key question isn't really "Is there something better?" but "Is the current MTI so bad that folks aren't willing to use it, so we are once again at risk of interoperability failure?". Whenever we are at risk of interoperability failure, the IETF may have to revisit the question. But the future group will have an option we lack: if nothing else seems more likely to be adopted, it can fall back on the current MTI. That may make the calculus a bit easier; we may also have enough interoperability with some later codec that the answer will be obvious. I have no crystal ball, but I certainly hope we will not have to go through this whole experience again. regards, Ted --20cf30434866fe8d79050a486861 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 15, 2014 at 1:37 PM= , Peter Saint-Andre - &yet <peter@andyet.net> wrote:
Not as far as I can se= e.

Ten years ago if we'd had this discussion, H.261 might have been MTI. T= en years from now, H.264 will seem ancient, too.

I fully expect that someone in the IETF (perhaps not us) will revisit the M= TI decision once we have better alternatives.

Peter

=E2=80=8BThe nice thing is that ou= r current model allows us to have nice things right away; as soon as they a= re in common, they may be selected by negotiation.=C2=A0 What the MTI gives= us is a way to avoid interoperability failure.=C2=A0 So the key question i= sn't really "Is there something better?" but "Is the cur= rent MTI so bad that folks aren't willing to use it, so we are once aga= in at risk of interoperability failure?".=C2=A0

Whenever we are at risk of interoperability failure, the IETF may have to= revisit the question.=C2=A0 But the future group will have an option we la= ck:=C2=A0 if nothing else seems more likely to be adopted, it can fall back= on the current MTI.=C2=A0 That may make the calculus a bit easier; we may = also have enough interoperability with some later codec that the answer wil= l be obvious.=C2=A0 I have no crystal ball, but I certainly hope we will no= t have to go through this whole experience again.

regards,

Te= d


=C2=A0
--20cf30434866fe8d79050a486861-- From nobody Mon Dec 15 14:18:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FCC1A01CB for ; Mon, 15 Dec 2014 14:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfjFAVfO-xCz for ; Mon, 15 Dec 2014 14:18:12 -0800 (PST) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C63B1A01A8 for ; Mon, 15 Dec 2014 14:18:12 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id y20so11723899ier.32 for ; Mon, 15 Dec 2014 14:18:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Wp2ZBDOfzoscXdb5gtx1K1Knp+3OF1jH/IPkzxYE2lI=; b=TIU8Mjf7QqnqN1xKXhfnnzmSp4o+HZVaRkVGDogpW/GAY2EfNbj7m1xWoGqyY5ujbL yDfzhOP81RWjZ1s/6ZgkmwB/xd67pfHEc5YGjkzDGQwmQ9Bj+TM4/guQrqClDu+d0SOj N+lF0rX/qXC0ykrqrQ3JGCQtWGlNb27WRxzTBFvcb4N7+EZQMTSN1L5+icgHLS6gPMJK EPVjh+vqi9YWmCOrd+r3GbFT96TFDBuj/7Hi5OI7maTayoRmFk9msPZAXfhNDr1U0nSD qQHYGl7bQWDXVBmSh2c8QQRSSzV0K+SJ2jUQe9z9Sne9DQvR6chwry6p3rn2iyWuJp8q LQWw== X-Gm-Message-State: ALoCoQlWWgE1Gy35hQgcGpU2m1niZGMGKN1kg/99hNB3jf3H3L1GLUiAZdZOYVFVeb2PC2Oungc/ X-Received: by 10.50.153.109 with SMTP id vf13mr20134463igb.41.1418681891521; Mon, 15 Dec 2014 14:18:11 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id d138sm5292652iod.37.2014.12.15.14.18.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Dec 2014 14:18:10 -0800 (PST) Message-ID: <548F5E22.2040605@andyet.net> Date: Mon, 15 Dec 2014 15:18:10 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ted Hardie References: <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GqoIqLhCdrvOR7xcmUdXF47nFSE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 22:18:13 -0000 On 12/15/14, 3:03 PM, Ted Hardie wrote: > On Mon, Dec 15, 2014 at 1:37 PM, Peter Saint-Andre - &yet > > wrote: > > Not as far as I can see. > > Ten years ago if we'd had this discussion, H.261 might have been > MTI. Ten years from now, H.264 will seem ancient, too. > > I fully expect that someone in the IETF (perhaps not us) will > revisit the MTI decision once we have better alternatives. > > Peter > > > ​The nice thing is that our current model allows us to have nice things > right away; as soon as they are in common, they may be selected by > negotiation. What the MTI gives us is a way to avoid interoperability > failure. So the key question isn't really "Is there something better?" > but "Is the current MTI so bad that folks aren't willing to use it, so > we are once again at risk of interoperability failure?". Some folks have expressed a concern that whatever we choose as an MTI codec now must always be an MTI codec. I'm trying to allay that concern by saying that yes, indeed, we can change our MTI codec(s) in the future if we please (naturally, keeping interoperability in mind at that future time). Peter From nobody Mon Dec 15 14:22:25 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7AD01A0461 for ; Mon, 15 Dec 2014 14:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9jy4ZvbPAoC for ; Mon, 15 Dec 2014 14:22:18 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7148A1A065C for ; Mon, 15 Dec 2014 14:22:16 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBFMM7Kw064796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2014 16:22:10 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <548F5F0E.4050100@nostrum.com> Date: Mon, 15 Dec 2014 16:22:06 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , Ted Hardie References: <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> In-Reply-To: <548F5E22.2040605@andyet.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CV2Bzy1drSxnVY7sen-QpZxuHl4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 22:22:20 -0000 On 12/15/14 16:18, Peter Saint-Andre - &yet wrote: > Some folks have expressed a concern that whatever we choose as an MTI > codec now must always be an MTI codec. I'm trying to allay that > concern by saying that yes, indeed, we can change our MTI codec(s) in > the future if we please (naturally, keeping interoperability in mind > at that future time). I agree 100%, but I don't think we need to get consensus on what this effort might look like 10 years in the future. Let's leave tomorrow's battles for tomorrow, or we'll never make progress. /a From nobody Mon Dec 15 14:24:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8AC1A0461 for ; Mon, 15 Dec 2014 14:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQx30daS02pY for ; Mon, 15 Dec 2014 14:24:30 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 89E981A0252 for ; Mon, 15 Dec 2014 14:24:30 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id A49CFC94BD; Mon, 15 Dec 2014 17:24:27 -0500 (EST) Date: Mon, 15 Dec 2014 17:24:27 -0500 From: John Leslie To: Peter Saint-Andre - &yet Message-ID: <20141215222427.GO47023@verdi> References: <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <548F54A5.2060105@andyet.net> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WLvwMrfOUaPU4qzDiayva8P30aY Cc: rtcweb@ietf.org Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 22:24:32 -0000 Peter Saint-Andre - &yet wrote: > On 12/15/14, 12:24 PM, John Leslie wrote: >> >> >> But we don't obsolete a MTI because "we have much better options": >> we obsolete a MTI because "nobody's using it anymore". > > Actually we can obsolete an MTI for any reason we please, at long as > there's IETF consensus to do so. Technically, we "can"... In actual practice, though, as long as someone pipes up during Last-Call saying "These folks are still using that!", we generally back down from declaring things "Obsolete". >> We are all trusting, I hope, that VP9, H.265, etc. will "just be >> used in preference" as soon as two endpoints support them. >> >> I don't expect to revisit the MTI selection... > > I do. It's a question of when. Well, Peter _is_ younger than me... ;^) But this is a sign of a pretty serious disconnect between "old-fogies" and "young-turks" that I'd like to call attention to: Young-Turks want to "do it right" and have a standard ensure the best possible outcome; old-fogies have been-there, done-that, and gotten-the-T-shirt -- and things never ended up the way we expected. Old-fogies view the world as a continuum where small changes add up to big progress over time, but too-large changes get mired and wander in the weeds, tiring everybody and usually leave misguided folks as the last-men-standing. A wise friend once told me that the true problem with democracy is that the results are unstable: when the electorate wants a change, the resultant changes goes too far; and walking it back to the middle "stable-ground" takes too long. This is a big part of why I "just don't get the hint" when the majority disagrees with me -- and I prize the IETF consensus-process whenever we can get it to work. And it's why I would have been perfectly happy with H.261 as the Mandatory-To-Implement codec. We cannot be effective if we have to turn around next month and say that VP9 must replace VP8 as MTI or H.265 must replace H.264. Market forces _really_can_ be trusted to get the better codec(s) used in preference to whatever we designate as MTI. >> (That is what we want, right?) > > Not as far as I can see. I honestly believe this "compromise" is getting majority approval because folks are _really_ tired of the MTI discussions. But there _are_ young-turks who believe the MTI question is _so_ important that we have to discuss it every IETF-week until we reach consensus-by-exhaustion. "Are we there yet?" -- John Leslie From nobody Mon Dec 15 14:25:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243461A19FA for ; Mon, 15 Dec 2014 14:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4yH9YBUVVq9 for ; Mon, 15 Dec 2014 14:24:57 -0800 (PST) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0A31A047A for ; Mon, 15 Dec 2014 14:24:57 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id l13so6410055iga.8 for ; Mon, 15 Dec 2014 14:24:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6yqluzpdULDuqcBrB49XnFCIIlfnbd2qaQwaflEHsZM=; b=YDFEUctxqPbb4WHJoQ7RW7a3Khv6uHxVrYB5UW4B1Rl4hF3VoygEIr9gmEFEQVa7IX xEu6xtV1d5+8S6Iu21vv6IJIkF56pVzHH5k0rpjmR9Z+E79cWAMs0NJMb4w1p4knQzRu fMovqG+W1uQ/OfgNW2sjqilu3ptlxlgTuMLafnhbi27KN9Ni0+8c019D7znkfLb7aGiv 1fn3K3rS8i6QwrFao33Ns309yZoBpwXPnZflT+VQ6dyIOudYXaH/4PmrQGrkMdU7rxJ8 3tkFf69rI66zYpXP5FwWdRCsNLlvxqhh+qT0BNVTro5OF4LpYiMlezqPqgdIQVuSON9y SKeQ== X-Gm-Message-State: ALoCoQlS7YsZCPc8k0IyKc45ucGS00hPZBUWeWUA0oygjGlW1Fyvdt0JGSdNPn4ZEIIpFDR1FZCL X-Received: by 10.50.55.65 with SMTP id q1mr20165223igp.17.1418682297172; Mon, 15 Dec 2014 14:24:57 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id q7sm5508718igx.9.2014.12.15.14.24.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Dec 2014 14:24:56 -0800 (PST) Message-ID: <548F5FB8.9010300@andyet.net> Date: Mon, 15 Dec 2014 15:24:56 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adam Roach , Ted Hardie References: <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> In-Reply-To: <548F5F0E.4050100@nostrum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0Ij49BWAZnWRm95811NQeQr0QOQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 22:24:59 -0000 On 12/15/14, 3:22 PM, Adam Roach wrote: > On 12/15/14 16:18, Peter Saint-Andre - &yet wrote: >> Some folks have expressed a concern that whatever we choose as an MTI >> codec now must always be an MTI codec. I'm trying to allay that >> concern by saying that yes, indeed, we can change our MTI codec(s) in >> the future if we please (naturally, keeping interoperability in mind >> at that future time). > > I agree 100%, but I don't think we need to get consensus on what this > effort might look like 10 years in the future. Let's leave tomorrow's > battles for tomorrow, or we'll never make progress. Yes, that's why I'm now saying to leave out all future-oriented text. Those who want to influence better MTI decisions in the future can get involved with building better codecs today. :-) Peter From nobody Mon Dec 15 14:44:03 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAA21A1EF5 for ; Mon, 15 Dec 2014 14:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voxFiW-YW-NO for ; Mon, 15 Dec 2014 14:43:54 -0800 (PST) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116D21A1B4A for ; Mon, 15 Dec 2014 14:43:53 -0800 (PST) Received: by mail-vc0-f169.google.com with SMTP id hy10so6101356vcb.0 for ; Mon, 15 Dec 2014 14:43:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nnqBTEKwXaA5GEIIa8IWf9/c0Bv1CrnNmrolVwhJSE0=; b=lX15sok2D7Cq3Y6FLgyaoldvdHnbWF51H4Y9QFvyxGKvJ78PGR06u87cgWJ2Mp+E9W lIK5BoLgqJ6bH/fZ26qC1ipvpg4pPBrK/XtvJoZkdsTG7w/bErRNmuTOIUQXqgXbwONm de5O6lmgHgvSUcqjZ5TdDJ0PWOcPU6P7kol+rCTLoateQYjfRpQl9Pc7mGBGGlL+JNjk OwP6l2JKt2mWIGUNMLr3aigf0Cd7yRcZi4lm+Gk3bh0+86psLHAFuE6VLAfXGTUrXzFE 0FEWUU2ewaEJxKR8z1Bt+4JvOUixFknmdTihel9b2Qf+k8y37ztvxdnMmNQX04UoI+9i 351Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nnqBTEKwXaA5GEIIa8IWf9/c0Bv1CrnNmrolVwhJSE0=; b=EZAHNeNLyzycllIqt9V3a471YolkAQ+L/Pvn5gFPxsF1YzkDnGwPVurVm0a5v6/VgT hJMZLD8V+GhlDCVd6P7Y0WltkqFkA4sQQwwvDqL+vu/DC1ZnVIWOtdXSxRdbtL2XO2gE ZOfwZ33uQvH/t+3aecmuGLcqVWOpPgUwMHu0zI6dE7ZutfPti4AAD3HJKg8stzAlbx1/ 36UeCs1OSAVIF1l0Ua1jfjDk0FoPl1zJvPqVU+Vfh7+Byyo1BNP7q5TM9fNCpX/rCGpo ntW8xuBDPKIacLumRfNFjMnx6xdVvG1H9mb8LmqhqYX+DllRpEJPuGIqlkm1i70DW4fh w1LA== X-Gm-Message-State: ALoCoQlTtmgHgEHPDxVE51TUn6JNahpC8PIZOkpqbLowtf/Uao4vEKyXOhfBSPoqP5ADWAovvd+r X-Received: by 10.220.143.16 with SMTP id s16mr21462729vcu.53.1418683433084; Mon, 15 Dec 2014 14:43:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.10.229 with HTTP; Mon, 15 Dec 2014 14:43:32 -0800 (PST) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E63FD67@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E63FD67@MCHP04MSX.global-ad.net> From: Justin Uberti Date: Mon, 15 Dec 2014 14:43:32 -0800 Message-ID: To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=047d7b33db6a142080050a48fa5c Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Yh6KZHtbNaHWtF1AULzHVLd3kK8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 22:43:55 -0000 --047d7b33db6a142080050a48fa5c Content-Type: text/plain; charset=UTF-8 I think making it a requirement is probably premature until we have a WG document that explains what should happen when you discover one of these network-provided TURN servers. Once https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04 is accepted as a WG doc, we can add a requirement for support for RETURN and server discovery. Unclear whether it needs to be MUST-strength until we get some implementation feedback though. On Mon, Dec 15, 2014 at 7:56 AM, Hutton, Andrew wrote: > > +1 Also wondering why it is not appropriate? > > > > F20 in the requirements draft states: > > > > F20 The browser must support the use of STUN and TURN > > servers that are supplied by entities other than > > the web application (i.e. the network provider). > > > > So I was thinking the need for specifying the discovery method would not > be controversial. > > > > Andy > > > > > > *From:* Simon Perreault [mailto:sperreault@jive.com] > *Sent:* 15 December 2014 15:49 > *To:* Eric Rescorla > *Cc:* Hutton, Andrew; rtcweb@ietf.org > *Subject:* Re: [rtcweb] rtcweb-transports reference to TRAM discovery > > > > > > On Mon, Dec 15, 2014 at 10:44 AM, Eric Rescorla wrote: > > I do not believe that this is an appropriate requirement > > > Care to say why? > > > > Thanks, > > Simon > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b33db6a142080050a48fa5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think making it a requirement is probably premature unti= l we have a WG document that explains what should happen when you discover = one of these network-provided TURN servers. Once=C2=A0https://tools.ietf.org/h= tml/draft-schwartz-rtcweb-return-04 is accepted as a WG doc, we can add= a requirement for support for RETURN and server discovery.=C2=A0

<= /div>
Unclear whether it needs to be MUST-strength until we get some im= plementation feedback though.

On Mon, Dec 15, 2014 at 7:56 AM, Hutton, Andrew <andrew.hutton@unify.com> wrote:

+1 Also wondering why it = is not appropriate?

=C2=A0

F20 in the requirements d= raft states:

=C2=A0

F20=C2=A0=C2=A0=C2=A0=C2=A0 The browser must support the use of= STUN and TURN

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 se= rvers that are supplied by entities other than

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 th= e web application (i.e. the network provider).

=C2=A0

So I was thinking the nee= d for specifying the discovery method would not be controversial.=

=C2=A0

Andy=

=C2=A0

=C2=A0

From: Simon Pe= rreault [mailto:sp= erreault@jive.com]
Sent: 15 December 2014 15:49
To: Eric Rescorla
Cc: Hutton, Andrew; rtcweb@ietf.org
Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery<= u>

=C2=A0

=C2=A0

On Mon, Dec 15, 2014 at 10:44 AM, Eric Rescorla <= ekr@rtfm.com> wrot= e:

I do not believe that this is an appropriate require= ment


Care to say why?

=C2=A0

Thanks,

Simon


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--047d7b33db6a142080050a48fa5c-- From nobody Mon Dec 15 14:45:19 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE821A01CB for ; Mon, 15 Dec 2014 14:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gU-AcKuDiJj for ; Mon, 15 Dec 2014 14:45:15 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 622261A0248 for ; Mon, 15 Dec 2014 14:45:05 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBFMj10r066609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2014 16:45:01 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <548F646C.1050406@nostrum.com> Date: Mon, 15 Dec 2014 16:45:00 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , Ted Hardie References: <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> In-Reply-To: <548F5FB8.9010300@andyet.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/3lHhrRsW9oxtZ3ybrVuJRfyo53M Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 22:45:17 -0000 On 12/15/14 16:24, Peter Saint-Andre - &yet wrote: > On 12/15/14, 3:22 PM, Adam Roach wrote: >> On 12/15/14 16:18, Peter Saint-Andre - &yet wrote: >>> Some folks have expressed a concern that whatever we choose as an MTI >>> codec now must always be an MTI codec. I'm trying to allay that >>> concern by saying that yes, indeed, we can change our MTI codec(s) in >>> the future if we please (naturally, keeping interoperability in mind >>> at that future time). >> >> I agree 100%, but I don't think we need to get consensus on what this >> effort might look like 10 years in the future. Let's leave tomorrow's >> battles for tomorrow, or we'll never make progress. > > Yes, that's why I'm now saying to leave out all future-oriented text. I take the point, but there is one key future-looking component of the current accord. Leaving it undocumented basically violates the agreement that many people have signed up for. As I pointed out in a previous message, this particular little wart is necessary [1], even if untidy. Which basically points to a need to document this intention (which, as Sean pointed out, has a non-trivial body of precedent), and to hold the line against documenting any further intended decision trees. I suppose we could, without harm, document obvious points of IETF process like "RFCs can be obsoleted by other RFCs, and those new RFCs can say anything that the IETF comes to consensus around," but I doubt it's useful to do so, and it seems somewhat outside the purview of this WG to do so anyway. /a ____ [1] To put a finer point on the necessity I mention here: in the straw poll last year, this option *without* the forward-looking provision received a mere 9% of participants supporting it, with 53% actively opposing it. The forward-looking provision is basically the "special sauce" that makes this approach palatable for some significant number of WG participants. From nobody Mon Dec 15 14:53:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F451A1F04 for ; Mon, 15 Dec 2014 14:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzQ0XUSyfSBl for ; Mon, 15 Dec 2014 14:53:30 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C631A1F02 for ; Mon, 15 Dec 2014 14:53:25 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id x12so15791859wgg.38 for ; Mon, 15 Dec 2014 14:53:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cPw/gAvV1ZANR0zR1IeQBPbrbKU5O7Oeqzqjn8q5wvM=; b=F+KqF3HUyoNzRIfTSy5YxuLDbPSJrdP6PnYCLfSxBhctvfDxcIk00RTCxwVsL/iFra 3iV/1L7MqZs/Axx9FIjf24W16Hrytk4HFZbYkIsULmim8v18ryMiU/UWBxO6t9DfxMJO 7JgCgYkoPDtdGeWpZhQDVNssekjC7LK1OFHLLlOa40MxcGB9c5VF7/bOgc9Q/EEwIpR7 Kp2vGzDwdWLrYWIfw5feYGyL9ziyTXtho5RcnREdov71BZND8zauT3bCLMfFEw0QzcNj 791M2imPEx3d4ga6bTpA/zoxgzJLp9k2RaKI6hVRlSqM11F6GZb+n6ZKkmsaucFb7VWi IRUA== X-Received: by 10.180.221.201 with SMTP id qg9mr35447236wic.29.1418684004297; Mon, 15 Dec 2014 14:53:24 -0800 (PST) Received: from Saturns-MBP.fritz.box ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id n5sm14887082wic.6.2014.12.15.14.53.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Dec 2014 14:53:23 -0800 (PST) Message-ID: <548F6661.3020407@gmail.com> Date: Mon, 15 Dec 2014 23:53:21 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Peter Saint-Andre - &yet , Ted Hardie References: <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> In-Reply-To: <548F5E22.2040605@andyet.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NBGma5lC0YrtsbJEChnZucMS9k8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.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: Mon, 15 Dec 2014 22:53:32 -0000 On 15/12/14 23:18, Peter Saint-Andre - &yet wrote: > On 12/15/14, 3:03 PM, Ted Hardie wrote: >> On Mon, Dec 15, 2014 at 1:37 PM, Peter Saint-Andre - &yet >> > wrote: >> >> Not as far as I can see. >> >> Ten years ago if we'd had this discussion, H.261 might have been >> MTI. Ten years from now, H.264 will seem ancient, too. >> >> I fully expect that someone in the IETF (perhaps not us) will >> revisit the MTI decision once we have better alternatives. >> >> Peter >> >> >> ​The nice thing is that our current model allows us to have nice things >> right away; as soon as they are in common, they may be selected by >> negotiation. What the MTI gives us is a way to avoid interoperability >> failure. So the key question isn't really "Is there something better?" >> but "Is the current MTI so bad that folks aren't willing to use it, so >> we are once again at risk of interoperability failure?". > > Some folks have expressed a concern that whatever we choose as an MTI > codec now must always be an MTI codec. I'm trying to allay that > concern by saying that yes, indeed, we can change our MTI codec(s) in > the future if we please (naturally, keeping interoperability in mind > at that future time). > Perhaps that concern was created by the phrasing of the current proposal/draft that MTI is not going to be revisited for browsers. On the other hand, if this is going to be adopted (not to be misinterpreted, I don't agree with this proposal), is a quite "ugly" compromise, probably the most unclean rough consensus so far, nothing that is backed up with technical merits. I find it more fair to make it explicit that this was a "last resort" compromise, with a trigger for revisiting. It will accelerate the process for a RF codec, when having a clear benefit out of it -- what interest would be to push money on a new RF codec when you have to implement a paid one anyhow. Moreover, IETF has an affinity of stating backward compatibility (see RFC3261/SIP doing that for RFC2543), there will be always enough people asking for that to get in the same kind of debate like here. Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From nobody Mon Dec 15 17:23:57 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC801A016B for ; Mon, 15 Dec 2014 17:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gA3NSGK4sHVB for ; Mon, 15 Dec 2014 17:23:51 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB801A0140 for ; Mon, 15 Dec 2014 17:23:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11077; q=dns/txt; s=iport; t=1418693031; x=1419902631; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=pMjU8hwSrkbHcuP8lbVrYAbxmIQENY6oFPZN5XEW+oQ=; b=AUgdNC6V75RiThquCV6KXPYkD2Egm2/s5BpFGk1kBhz/PoSD/rIcjtPY ERmJQkIXt+8TtUxthVbxXV4ZNlsIG94dRhBaZp53GySjES4UcZbLVbQWo iVq1XIQaFRcGnkIrEhsWMxSYFsLzmTAyHEJTMXx7CWD94GbNilRRhyjAI U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYFANiIj1StJA2E/2dsb2JhbABagkNDUljFYAEJhShKAoEiFgEBAQEBfYQMAQEBAwEBAQFrCxALEQQBAQEnBycfCQgGE4gkCA3UcgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEj24EBgGDFoETBYk+jTOFeYs+IoQNHTCCQwEBAQ X-IronPort-AV: E=Sophos;i="5.07,583,1413244800"; d="scan'208,217";a="106015524" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP; 16 Dec 2014 01:23:50 +0000 Received: from [10.24.106.80] ([10.24.106.80]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sBG1Ni9T029555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Dec 2014 01:23:48 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_897224CE-BC1B-4802-89FD-FD167644F9C3" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E63FD67@MCHP04MSX.global-ad.net> Date: Mon, 15 Dec 2014 17:23:43 -0800 Message-Id: References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E63FD67@MCHP04MSX.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ERAYWnTdj7iJBM33PFZHEyaG29Y Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 01:23:54 -0000 --Apple-Mail=_897224CE-BC1B-4802-89FD-FD167644F9C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 15, 2014, at 7:56 AM, Hutton, Andrew = wrote: > +1 Also wondering why it is not appropriate? > =20 > F20 in the requirements draft states: > =20 > F20 The browser must support the use of STUN and TURN > servers that are supplied by entities other than > the web application (i.e. the network provider). > =20 > So I was thinking the need for specifying the discovery method would = not be controversial. Note that draft-ietf-tram-turn-server-discovery only discovers TURN = servers. If we need to discover STUN servers, too -- and I think we do = -- we need that document to expand its scope or a second document. I recently attended a talk where Matt Peterson presented Burning Man's = network. That network assigns RFC6598 addresses to each Burning Man = "camp", and their ISP provides CGN'd addresses to Burning Man. Each = camp operates its own WiFi network, and we can all reasonably assume = they are using typical consumer or SMB NAPT devices for those networks = (e.g., D-Link, Linksys, Ubiquity, etc.). To avoid tromboning = camp-to-camp WebRTC traffic to their ISP's CGN, they would benefit from = a STUN and a TURN server within the Burning Man network. His = presentation can be found at = https://www.nanog.org/meetings/nanog62/agenda (PDF and video). -d > =20 > Andy > =20 > =20 > From: Simon Perreault [mailto:sperreault@jive.com]=20 > Sent: 15 December 2014 15:49 > To: Eric Rescorla > Cc: Hutton, Andrew; rtcweb@ietf.org > Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery > =20 > =20 > On Mon, Dec 15, 2014 at 10:44 AM, Eric Rescorla wrote: > I do not believe that this is an appropriate requirement >=20 > Care to say why? > =20 > Thanks, > Simon > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_897224CE-BC1B-4802-89FD-FD167644F9C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Dec 15, 2014, at 7:56 AM, Hutton, = Andrew <andrew.hutton@unify.com> = wrote:

+1 Also wondering why it is not = appropriate?
 
F20 in the requirements draft = states:
 
F20     The browser must support the use of = STUN and TURN
           = servers that are supplied by entities other = than
           the = web application (i.e. the network provider).
 
So I was thinking the = need for specifying the discovery method would not be = controversial.

No= te that draft-ietf-tram-turn-server-discovery only discovers TURN = servers.  If we need to discover STUN servers, too -- and I think = we do -- we need that document to expand its scope or a second = document.

I recently attended a talk where Matt = Peterson presented Burning Man's network.  That network assigns = RFC6598 addresses to each Burning Man "camp", and their ISP provides = CGN'd addresses to Burning Man.  Each camp operates its own WiFi = network, and we can all reasonably assume they are using typical = consumer or SMB NAPT devices for those networks (e.g., D-Link, Linksys, = Ubiquity, etc.).  To avoid tromboning camp-to-camp WebRTC traffic = to their ISP's CGN, they would benefit from a STUN and a TURN server = within the Burning Man network.  His presentation can be found = at https://www.nanog.o= rg/meetings/nanog62/agenda (PDF and = video).

-d


 
Andy
 
 
From: Simon Perreault [mailto:sperreault@jive.com] 
Sent: 15 December 2014 = 15:49
To: Eric= Rescorla
Cc: Hutton, Andrew; rtcweb@ietf.org
Subject: Re: [rtcweb] = rtcweb-transports reference to TRAM = discovery
 
 
On = Mon, Dec 15, 2014 at 10:44 AM, Eric Rescorla <ekr@rtfm.com> = wrote:
I do not = believe that this is an appropriate = requirement

Care to say why?
 
Thanks,
Simon
____________________= ___________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb

= --Apple-Mail=_897224CE-BC1B-4802-89FD-FD167644F9C3-- From nobody Tue Dec 16 03:07:33 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988B31A1A7D for ; Tue, 16 Dec 2014 03:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhUnuOG_gZ1l for ; Tue, 16 Dec 2014 03:07:29 -0800 (PST) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200C11A1A6F for ; Tue, 16 Dec 2014 03:07:29 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id c9so10243079qcz.10 for ; Tue, 16 Dec 2014 03:07:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=kbE7Ej1Axwg/kIZJ10OefX0AGCn5pmMhq5+jXzfK1hU=; b=KiNZtrs8QZYTJkFNRoKmtmQmRp3h73906sa/gR5oAJ0VdQy8BKhRbg/rdbxAXfIIDE HdMXfH+c8U0alIxdD7FC6AF6Tl2nmr9o4Pt7l/xOCveHLYOakTk/r4aXsjSVfXLeKnWw fk5cY4r25iEG4aQVwH6LWwzMhf+4cKjuGYYit7SmyWwc7ijTI13STnxPIpVIqMzNFV7/ 6aMJkLjAt47nev+FzDDjd4ZC/0mgWmnkKUCN3s/ohaPp5KQj09dMHZRqb2nKsisrltXW ZLG7CN5zEEDf3w/RubHtYfjEROlQlP2/wDitF82hI5KjzfyJ0XYUfVrQ4nONiTY8xa2m QHFA== X-Gm-Message-State: ALoCoQmRahkX2EzlJJaJK9yEhqbUucVvpr7AarMrcoZnoVVX20os+xMpv9opHgg6Xwkvy1Sv4Ad3 X-Received: by 10.229.99.134 with SMTP id u6mr14923200qcn.10.1418728048189; Tue, 16 Dec 2014 03:07:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.26.135 with HTTP; Tue, 16 Dec 2014 03:07:08 -0800 (PST) In-Reply-To: References: <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 16 Dec 2014 12:07:08 +0100 Message-ID: To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YoXHy8w45GDrL-3VuBZFCcOr2x0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 11:07:31 -0000 2014-12-15 23:03 GMT+01:00 Ted Hardie : > The nice thing is that our current model allows us to have nice things ri= ght > away; as soon as they are in common, they may be selected by negotiation. > What the MTI gives us is a way to avoid interoperability failure. So the > key question isn't really "Is there something better?" but "Is the curren= t > MTI so bad that folks aren't willing to use it, so we are once again at r= isk > of interoperability failure?". > > Whenever we are at risk of interoperability failure, the IETF may have to > revisit the question. But the future group will have an option we lack: = if > nothing else seems more likely to be adopted, it can fall back on the > current MTI. That may make the calculus a bit easier; we may also have > enough interoperability with some later codec that the answer will be > obvious. I have no crystal ball, but I certainly hope we will not have t= o > go through this whole experience again. Hi Ted, No mention to "royalty free", "licensing" or "patents" in your comment, but just concerns about "what users use" and "interoperability" and "fall back to current MTI codecs". > but "Is the current MTI so bad that folks aren't willing to use it, so we= are once again at risk > of interoperability failure?". And is it better to depend on Cisco's benevolence forever and forcing vendors and service providers to any kind of patent trolling from now on? I cannot understand how you do not mention anything about these important subjects. --=20 I=C3=B1aki Baz Castillo From nobody Tue Dec 16 07:03:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877041A1B75 for ; Tue, 16 Dec 2014 07:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5h7mn4asq4H for ; Tue, 16 Dec 2014 07:03:07 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 67BD41A1B0C for ; Tue, 16 Dec 2014 07:03:06 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id E91D3C94A9; Tue, 16 Dec 2014 10:03:03 -0500 (EST) Date: Tue, 16 Dec 2014 10:03:03 -0500 From: John Leslie To: Adam Roach Message-ID: <20141216150303.GT47023@verdi> References: <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <548F646C.1050406@nostrum.com> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MWStOVic48LPK6JHOC8I1xxL2JY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 15:03:20 -0000 Adam Roach wrote: > On 12/15/14 16:24, Peter Saint-Andre - &yet wrote: >> On 12/15/14, 3:22 PM, Adam Roach wrote: >>> >>> I agree 100%, but I don't think we need to get consensus on what this >>> effort might look like 10 years in the future. Let's leave tomorrow's >>> battles for tomorrow, or we'll never make progress. >> >> Yes, that's why I'm now saying to leave out all future-oriented text. > > I take the point, but there is one key future-looking component of the > current accord. Leaving it undocumented basically violates the agreement > that many people have signed up for... This bothers me enough, even after sleeping on it, to comment: We are watching a model of "back room deals" such as the US Congress uses. I strongly believe we should reject this model. (That doesn't mean we need to reject the consensus called by a WGC.) The US Congress typically includes the text of every "important" lobbyist in the final bill; and expects the congress-critters to vote for it pretty much sight-unseen. The "leadership" tells the individual members what to vote for. Here, not only do we have Adam Roach defending the back-room deal, we have the WGCs failing to post an "official" version of the text we are consenting to. I cry "TILT"! Let's have the WGC calling consensus publish the text we're being asked to consent to. And I strongly recommend all of us read Pete Resnick's RFC 7282 "On Consensus and Humming in the IETF", especally Section 3. I have heard a lot of points raised relating to this consensus call. I have not heard much discussion about how to accomodate those concerns. Instead we hear "Take it or leave it: this is the only deal which can get enough votes!" Granted, Pete's RFC is strictly Informational: it cannot override RFC 2418, which says: ] ] Consensus can be determined by a show of hands, humming, or any other ] means on which the WG agrees (by rough consensus, of course). Note ] that 51% of the working group does not qualify as "rough consensus" ] and 99% is better than rough. It is up to the Chair to determine if ] rough consensus has been reached. Thus this is not a "process appeal" -- the WGCs are entitled to say "A strong majority agrees with the consensus of the Hawaii session" and say that is consensus. But I might appeal if they don't tell us what text we're agreeing to until _after_ declaring consensus. And I really do recommend we all try to follow Pete Resnick's advice on consensus rather than turn this into an exercise in voting. The word "consensus" _does_ have a meaning quite different from "2/3 vote". -- John Leslie From nobody Tue Dec 16 07:08:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878951A1AF2 for ; Tue, 16 Dec 2014 07:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYsO8OWcjQsr for ; Tue, 16 Dec 2014 07:08:43 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63601A1B06 for ; Tue, 16 Dec 2014 07:08:42 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so12752930wid.17 for ; Tue, 16 Dec 2014 07:08:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=f0MzB3gv4I7G10JcHfBhIX/sywkSkWN36CDp20k+G44=; b=cMeGuffRTeqBksEZwvrgC/SxXNIvQMh+b0uFdO/xsLO6VZ7BIFJN8wWKSk8u4nJj48 qDPP8HU+wMXKgQqNAQsFj5E2q+mcbCbdlhFF7U5p/4XfHnPqJ5LCjsN3x2jWWobVWe/Q MPs0q4tkE4epG8Fkrk2IiVb9fQ22UAUjFlDiKjLDgnVQAW7ovaX1611qwMwqkgUSRVvL uZ/jaqA/F7FwwdtjPJsllr9J7yMM1cEF8ZiNcFcsNKGPsnxVhFS2PwmVud0OjD9E+VSc Ly14Y+9mFYwtAqWcoj2yrRCqxLR6PMmiUyAHYm8WyDV7aJDp6m6FAQX1ny9HWQSc/dWN 7geA== X-Gm-Message-State: ALoCoQnmsskNjrYqrTEdiutLhvn3LGwOct9OUD/MW/uj4ZUL1l9/tZsOl4IdWFMAO/nVolZjfFWt X-Received: by 10.180.84.98 with SMTP id x2mr5561210wiy.14.1418742521070; Tue, 16 Dec 2014 07:08:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Tue, 16 Dec 2014 07:08:00 -0800 (PST) In-Reply-To: <20141216150303.GT47023@verdi> References: <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> From: Eric Rescorla Date: Tue, 16 Dec 2014 07:08:00 -0800 Message-ID: To: John Leslie Content-Type: multipart/alternative; boundary=f46d044401b2ff17ff050a56bb27 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2LMEY_ciI0MVcPC9wIC4csXOvQQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 15:08:45 -0000 --f46d044401b2ff17ff050a56bb27 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 16, 2014 at 7:03 AM, John Leslie wrote: > > Adam Roach wrote: > > On 12/15/14 16:24, Peter Saint-Andre - &yet wrote: > >> On 12/15/14, 3:22 PM, Adam Roach wrote: > >>> > >>> I agree 100%, but I don't think we need to get consensus on what this > >>> effort might look like 10 years in the future. Let's leave tomorrow's > >>> battles for tomorrow, or we'll never make progress. > >> > >> Yes, that's why I'm now saying to leave out all future-oriented text. > > > > I take the point, but there is one key future-looking component of the > > current accord. Leaving it undocumented basically violates the agreement > > that many people have signed up for... > > This bothers me enough, even after sleeping on it, to comment: > > We are watching a model of "back room deals" such as the US Congress > uses. I strongly believe we should reject this model. > > (That doesn't mean we need to reject the consensus called by a WGC.) > > The US Congress typically includes the text of every "important" > lobbyist in the final bill; and expects the congress-critters to vote > for it pretty much sight-unseen. The "leadership" tells the individual > members what to vote for. > > Here, not only do we have Adam Roach defending the back-room deal, we > have the WGCs failing to post an "official" version of the text we are > consenting to. > > I cry "TILT"! Let's have the WGC calling consensus publish the > text we're being asked to consent to. > Huh? The relevant text is here: https://tools.ietf.org/html/draft-ietf-rtcweb-video-03#section-5 -Ekr --f46d044401b2ff17ff050a56bb27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 16, 2014 at 7:03 AM, John Leslie <john@jlc.net> w= rote:
Adam Roach <adam@nostrum.com> wrote:
> On 12/15/14 16:24, Peter Saint-Andre - &yet wrote:
>> On 12/15/14, 3:22 PM, Adam Roach wrote:
>>>
>>> I agree 100%, but I don't think we= need to get consensus on what this
>>> effort might look like 10 years in the future. Let's leave= tomorrow's
>>> battles for tomorrow, or we'll never make progress.
>>
>> Yes, that's why I'm now saying to leave out all future-ori= ented text.
>
> I take the point, but there is one key future-looking component of the=
> current accord. Leaving it undocumented basically violates the agreeme= nt
> that many people have signed up for...

=C2=A0 =C2=A0This bothers me enough, even after sleeping on it, to comment:=

=C2=A0 =C2=A0We are watching a model of "back room deals" such as= the US Congress
uses. I strongly believe we should reject this model.

=C2=A0 =C2=A0(That doesn't mean we need to reject the consensus called = by a WGC.)

=C2=A0 =C2=A0The US Congress typically includes the text of every "imp= ortant"
lobbyist in the final bill; and expects the congress-critters to vote
for it pretty much sight-unseen. The "leadership" tells the indiv= idual
members what to vote for.

=C2=A0 =C2=A0Here, not only do we have Adam Roach defending the back-room d= eal, we
have the WGCs failing to post an "official" version of the text w= e are
consenting to.

=C2=A0 =C2=A0I cry "TILT"! Let's have the WGC calling consens= us publish the
text we're being asked to consent to.

Huh? The relevant text is here:


-Ekr

--f46d044401b2ff17ff050a56bb27-- From nobody Tue Dec 16 07:21:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28131A1B4E for ; Tue, 16 Dec 2014 07:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IE0ccLXGZmkC for ; Tue, 16 Dec 2014 07:21:03 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 224A71A1B22 for ; Tue, 16 Dec 2014 07:21:02 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 667D4C94A8; Tue, 16 Dec 2014 10:21:00 -0500 (EST) Date: Tue, 16 Dec 2014 10:21:00 -0500 From: John Leslie To: Eric Rescorla Message-ID: <20141216152100.GU47023@verdi> References: <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HVj5Io7IuLMKjQIJvtbjydP-yys Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 15:21:05 -0000 Eric Rescorla wrote: > On Tue, Dec 16, 2014 at 7:03 AM, John Leslie wrote: > >> I cry "TILT"! Let's have the WGC calling consensus publish the >> text we're being asked to consent to. > > Huh? The relevant text is here: > > https://tools.ietf.org/html/draft-ietf-rtcweb-video-03#section-5 Perhaps it is; perhaps not: we'd have to listen to the audio to be sure. Even after hearing the audio once, I'm not quite sure... Besides, Eric isn't the WGC calling consensus. -- John Leslie From nobody Tue Dec 16 07:35:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE151A1BB1 for ; Tue, 16 Dec 2014 07:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhugBzk0Rayi for ; Tue, 16 Dec 2014 07:35:18 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id DAE831A1BAA for ; Tue, 16 Dec 2014 07:35:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 2658C7C372D for ; Tue, 16 Dec 2014 16:35:17 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TTFphhgnAw1 for ; Tue, 16 Dec 2014 16:35:16 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:a83c:7992:ce6b:24b3]) by mork.alvestrand.no (Postfix) with ESMTPSA id 09AEF7C3711 for ; Tue, 16 Dec 2014 16:35:15 +0100 (CET) Message-ID: <54905132.40105@alvestrand.no> Date: Tue, 16 Dec 2014 16:35:14 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> In-Reply-To: <20141216152100.GU47023@verdi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/I3WwceL9qDdxavMiWDFy9v_0MjI Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 15:35:20 -0000 On 12/16/2014 04:21 PM, John Leslie wrote: > Eric Rescorla wrote: >> On Tue, Dec 16, 2014 at 7:03 AM, John Leslie wrote: >> >>> I cry "TILT"! Let's have the WGC calling consensus publish the >>> text we're being asked to consent to. >> Huh? The relevant text is here: >> >> https://tools.ietf.org/html/draft-ietf-rtcweb-video-03#section-5 > Perhaps it is; perhaps not: we'd have to listen to the audio to be > sure. Even after hearing the audio once, I'm not quite sure... If the chairs say that the text in video-03 section 5 is the text they think they're calling consensus on, I'm happy to have consensus called on that. It's close enough to what I believe we agreed on in Honolulu that I'm willing to consider the changes from what I remember editorial (the biggest difference I see offhand is the indentation of the future-pointing section, but there might have been grammar changes too.) I agree that having the consensus-calling chair state that this text is what he's calling consensus on would be beneficial. From nobody Tue Dec 16 07:36:58 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6891A1BB7 for ; Tue, 16 Dec 2014 07:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfA_wLpLhu-k for ; Tue, 16 Dec 2014 07:36:49 -0800 (PST) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259D61A1BB1 for ; Tue, 16 Dec 2014 07:36:49 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so12657500wiw.14 for ; Tue, 16 Dec 2014 07:36:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=++kubQNiixsG9PGMdTffemWWcd+O2jSCgyboeWiMhls=; b=XrH17o0ZtwUNg/eLZoMcn+Rs2PRjCYZHzre0nJ1uq/UCA1j703ha+7QvWyfZ+YZZkh smWDxb1Crgd0nDcKnvjuqPZEW0yDS/N1MywO0OerXXxkE8ycpeD6Gg2xMQv4v4uv06xo gYpnSPQhBzmFsZHkg8j+bcTO763+bBLk5rWJU2uDS1xEOqFCaGPaJqWM35Lo3JghbKaH rS0j0+iLlkYfW8093ql0M54QkP2Do/8NoQVBxgMaUXXTFpgAXIyW/p+Cpd2kLW9PNUuG 5c/zVYjCRA+Z27MRDl4u0nSCPhvkeviMpGxBpnCIihLjQcAae3AMgu48WqG6G9a2aX5t c/6g== X-Gm-Message-State: ALoCoQnaCQt8K7ZOQ+Gu6icTbd36K7lDDdND4HkxvBdnNsWni+jWrFlDTXLWeEi/41FqiIgw3N3d X-Received: by 10.180.205.163 with SMTP id lh3mr5868244wic.63.1418744207897; Tue, 16 Dec 2014 07:36:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Tue, 16 Dec 2014 07:36:07 -0800 (PST) In-Reply-To: <20141216152100.GU47023@verdi> References: <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> From: Eric Rescorla Date: Tue, 16 Dec 2014 07:36:07 -0800 Message-ID: To: John Leslie Content-Type: multipart/alternative; boundary=001a11c381be8a0e40050a57206c Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/q4YC2J1UHPfPO8WNsWaecqYCirY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 15:36:56 -0000 --001a11c381be8a0e40050a57206c Content-Type: text/plain; charset=UTF-8 On Tue, Dec 16, 2014 at 7:21 AM, John Leslie wrote: > > Eric Rescorla wrote: > > On Tue, Dec 16, 2014 at 7:03 AM, John Leslie wrote: > > > >> I cry "TILT"! Let's have the WGC calling consensus publish the > >> text we're being asked to consent to. > > > > Huh? The relevant text is here: > > > > https://tools.ietf.org/html/draft-ietf-rtcweb-video-03#section-5 > > Perhaps it is; perhaps not: we'd have to listen to the audio to be > sure. Even after hearing the audio once, I'm not quite sure... > Again, huh? The version that was discussed in Honolulu is on the slides here: http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf on page 14. The text isn't exactly the same but it's substantively the same as what's in the draft. Needless to say, having WG consensus on the substance and letting the editor wordsmith the text is totally normal IETF process. I haven't heard anyone who was at HNL and in favor of the text on the slides object that Adam's text in the draft doesn't reflect those slides. Besides, Eric isn't the WGC calling consensus. > No, the chairs did here: http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html And this message clearly points to the slides above. -Ekr --001a11c381be8a0e40050a57206c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 16, 2014 at 7:21 AM, John Leslie <john@jlc.net> w= rote:
Eric Rescorla <ekr@rtfm.com> wrote:
> On Tue, Dec 16, 2014 at 7:03 AM, John Leslie <john@jlc.net> wrote:
>
>> I cry "TILT"! Let's have the= WGC calling consensus publish the
>> text we're being asked to consent to.
>
> Huh? The relevant text is here:
>
> https://tools.ietf.org/html/draft-ietf-rtcweb-vide= o-03#section-5

=C2=A0 =C2=A0Perhaps it is; perhaps not: we'd have to listen to = the audio to be
sure. Even after hearing the audio once, I'm not quite sure...

Again, huh?

The versio= n that was discussed in Honolulu is on the slides here:
--001a11c381be8a0e40050a57206c-- From nobody Tue Dec 16 08:25:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8EF1A1BA4 for ; Tue, 16 Dec 2014 08:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_-Ptvs71EGD for ; Tue, 16 Dec 2014 08:25:37 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 96DDC1A1B30 for ; Tue, 16 Dec 2014 08:25:37 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id A9290C94A9; Tue, 16 Dec 2014 11:25:34 -0500 (EST) Date: Tue, 16 Dec 2014 11:25:34 -0500 From: John Leslie To: Eric Rescorla Message-ID: <20141216162534.GV47023@verdi> References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zx-qIwbg1gFrbU8qlJlxzfNpHnU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 16:25:41 -0000 Eric Rescorla wrote: > On Tue, Dec 16, 2014 at 7:21 AM, John Leslie wrote: > >> Perhaps it is; perhaps not: we'd have to listen to the audio to be >> sure. Even after hearing the audio once, I'm not quite sure... > > Again, huh? No, "still". > The version that was discussed in Honolulu is on the slides here: > > http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf > > on page 14. The text isn't exactly the same but it's substantively > the same as what's in the draft. You prove my point... > Needless to say, having WG consensus on the substance and letting the > editor wordsmith the text is totally normal IETF process. In some cases, yes. IMHO, this is not one of them. YMMV... > I haven't heard anyone who was at HNL and in favor of the text on the > slides object that Adam's text in the draft doesn't reflect those > slides. Probably you haven't... > Besides, Eric isn't the WGC calling consensus. > > No, the chairs did here: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html ] ] From: Sean Turner ] At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion ] about codecs, which I dubbed "the great codec compromise." ] The compromise text that was discussed appears in slides 12-14 at [4] ] (which is a slight editorial variation of the text proposed at [2]). ] ] This message serves to confirm the sense of the room. Actually, as I read this more carefully, that isn't a consensus call. Sean goes on to dismiss the objections he heard in the room: ] ] In the room, I heard the following objections and responses (and I'm ] paraphrasing here), which I'll take the liberty of categorizing as ] IPR, Time, and Trigger: ] ] 1) IPR: ] Objections: There are still IPR concerns which may restrict what a ] particular organization feels comfortable with including in their ] browser implementations. ] Response: IPR concerns on this topic are well known. There is even a ] draft summarizing the current IPR status for VP8: ] draft-benham-rtcweb-vp8litigation. The sense of the room was still ] that adopting the compromise text was appropriate. Sean is stating his view of consensus-of-the-room. ] 2) Time: ] 2.1) Time to consider decision: ] Objection: The decision to consider the compromise proposal at this ] meeting was provided on short notice and did not provide some the ] opportunity to attend in person. ] Response: Six months ago the chairs made it clear discussion would be ] revisited @ IETF 91. The first agenda proposal for the WG included this ] topic, and the topic was never removed by the chairs. More importantly, ] all decisions are confirmed on list; in person attendance is not ] required to be part of the process. Sean is defending the action of the WGCs. ] 2.2) Time to consider text: ] Objection: The proposed text [2] is too new to be considered. ] Response: The requirement for browsers to support both VP8 and H.264 ] was among the options in the straw poll conducted more than six months ] ago. All decisions are confirmed on list so there will be ample time ] to discuss the proposal. Sean is specifically saying the text should be discussed on-list. ] 3) Trigger: ] Objection: The "trigger" sentence [3] is all kinds of wrong because ] it's promising that the future IETF will update this specification. ] Response: Like any IETF proposal, an RFC that documents the current ] proposal can be changed through the consensus process at any other time. Sean is specifically saying the "trigger" should be discussed on-list. ] After the discussion, some clarifying questions about the hums, and ] typing the hum questions on the screen, there was rough consensus in ] the room to add (aka "shove") the proposed text into ] draft-ietf-rtcweb-video. In keeping with IETF process, I am confirming ] this consensus call on the list. This _is_ calling for consensus. But Sean omitted saying _what_ text; and agreed that the exact text may not have been clear to those in the room. ] If anyone has any other issues that they would like to raise please do ] by December 19th. (And folks have been doing so.) I have asked on-list for the exact text before raising my issues, since my issues relate to the text, not the choosing to have two MTIs. > And this message clearly points to the slides above. I don't find it helpful to attack the people who raise issues. YMMV. But what EKR thinks really doesn't matter. He is not a WGC. -- John Leslie From nobody Tue Dec 16 08:53:45 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE361A1B05 for ; Tue, 16 Dec 2014 08:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9HjUeuFWJi2 for ; Tue, 16 Dec 2014 08:53:31 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A389D1A6FDF for ; Tue, 16 Dec 2014 08:53:29 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id x12so17919497wgg.10 for ; Tue, 16 Dec 2014 08:53:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/LSLTBZXzVtNlIUljHYSxlU3Jepnk38Hd/f49Z+WQ3U=; b=VrRbgWt99NXIqtcd/iM+cow7Vu0/eeh5iyfCMu/RoLz0Yi/Tctj36PjJPlif0AyEPZ zc4KiB7SepL8L9F2ZZPffPqjNkE9g1X3FfKki79rGkxLh5YWcVWbRYu4VNJflkQR7my5 N291Bd6R0Q5rCIWlwmmyPC7Zw5MOONG2ZRqAsbOKppeZsz2tQpk4A0QE4GeGAXFhAp5z DowZgsIgvt7oUln8dXpHvBKC2SGzDV74ZXnCZsqyV/iWpR/mP/kO6hdf5TXsc3ykaN1F Q7iX+fMmLPN3jM1kUDk15M3bzd9/fdnJDuoQR192M0iWbNmiXlCSR02w8B9VjNHcnp6F EfNw== X-Gm-Message-State: ALoCoQn57CoDconxUKojy2y5fFztTftl43Ys5THXKNECO3w/Zvp3eckf9Z255ZVfr0HRagr3KxYE X-Received: by 10.180.211.34 with SMTP id mz2mr6376168wic.56.1418748807489; Tue, 16 Dec 2014 08:53:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Tue, 16 Dec 2014 08:52:47 -0800 (PST) In-Reply-To: <20141216162534.GV47023@verdi> References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> From: Eric Rescorla Date: Tue, 16 Dec 2014 08:52:47 -0800 Message-ID: To: John Leslie Content-Type: multipart/alternative; boundary=001a11c37e02b25d5e050a583250 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xq0wjNeUZL0cDCsW_FUH_5zgFmQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 16:53:38 -0000 --001a11c37e02b25d5e050a583250 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 16, 2014 at 8:25 AM, John Leslie wrote: > > Eric Rescorla wrote: > > On Tue, Dec 16, 2014 at 7:21 AM, John Leslie wrote: > > Needless to say, having WG consensus on the substance and letting the > > editor wordsmith the text is totally normal IETF process. > > In some cases, yes. IMHO, this is not one of them. YMMV... Indeed it does, since I have *never* heard of such a case where the editor had no discretion to change the text in purely editorial ways (subject to WG consensus of course). Feel free to cite one if you have one. > I haven't heard anyone who was at HNL and in favor of the text on the > > slides object that Adam's text in the draft doesn't reflect those > > slides. > > Probably you haven't... To the best of my knowledge it hasn't happened. Can you cite anyone who has so objected. > > > Besides, Eric isn't the WGC calling consensus. > > > > No, the chairs did here: > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html > ] > ] From: Sean Turner > ] At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion > ] about codecs, which I dubbed "the great codec compromise." > ] The compromise text that was discussed appears in slides 12-14 at [4] > ] (which is a slight editorial variation of the text proposed at [2]). > ] > ] This message serves to confirm the sense of the room. > > Actually, as I read this more carefully, that isn't a consensus call. > Sean goes on to dismiss the objections he heard in the room: > He's addressing them. What exactly is the problem with this? > ] 3) Trigger: > ] Objection: The "trigger" sentence [3] is all kinds of wrong because > ] it's promising that the future IETF will update this specification. > ] Response: Like any IETF proposal, an RFC that documents the current > ] proposal can be changed through the consensus process at any other time. > > Sean is specifically saying the "trigger" should be discussed > on-list. > I don't read this this way at all, Rather he's saying that in the future we can update the RFC. But yes, we can discuss the trigger on-list. Do you have some substantive objection that wasn't raised in HNL and/or hasn't been discussed to death here? > ] After the discussion, some clarifying questions about the hums, and > ] typing the hum questions on the screen, there was rough consensus in > ] the room to add (aka "shove") the proposed text into > ] draft-ietf-rtcweb-video. In keeping with IETF process, I am confirming > ] this consensus call on the list. > > This _is_ calling for consensus. > > But Sean omitted saying _what_ text; and agreed that the exact text > may not have been clear to those in the room. > Huh? The "proposed text" that was discussed in HNL is on the slide and that's what's being referred to here. Adam edited text which is substantially the same into the draft. > ] If anyone has any other issues that they would like to raise please do > ] by December 19th. > > (And folks have been doing so.) > > I have asked on-list for the exact text before raising my issues, > since my issues relate to the text, not the choosing to have two MTIs. > As I pointed out in my original message, that text is in Adam's draft. Again, it's totally procedurally regular to have rough consensus on text in the WG meeting and on the list and then have the editor edit in substantively the same text to the draft. If you think there is some respect in which those two blocks of text are not in fact the same, please point to it. Otherwise, this is just dilatory. > And this message clearly points to the slides above. > > I don't find it helpful to attack the people who raise issues. YMMV. > But what EKR thinks really doesn't matter. He is not a WGC. > Ironic that you would complain about "attack"s in a thread where you started out by attacking Adam Roach and here say "what EKR thinks really doesn't matter" -Ekr --001a11c37e02b25d5e050a583250 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 16, 2014 at 8:25 AM, John Leslie <john@jlc.net> wrote:Eric Rescorla <ekr@rtfm.com> wrote:
> On Tue, Dec 16, 2014 at 7:21 AM, John Leslie <john@jlc.net> wrote:
> Needless to say, having WG consensus on the substance and letting the<= br> > editor wordsmith the text is totally normal IETF process.

=C2=A0 =C2=A0In some cases, yes. IMHO, this is not one of them. YMMV= ...

Indeed it does, since I have *never* he= ard of such a case where
the editor had no discretion to change t= he text in purely editorial
ways (subject to WG consensus of cour= se). Feel free to cite one
if you have one.

<= div>
> I haven't heard anyone who was at HNL and in favor of the text on = the
> slides object that Adam's text in the draft doesn't reflect th= ose
> slides.

=C2=A0 =C2=A0Probably you haven't...

=
To the best of my knowledge it hasn't happened. Can you cite anyon= e
who has so objected.

=C2=A0

> Besides, Eric isn't the WGC calling consensus.
>
> No, the chairs did here:
> http://www.ietf.org/mail-archive/web/rtcweb/curre= nt/msg13696.html
]
] From: Sean Turner <turners at ieca.com>
] At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion
] about codecs, which I dubbed "the great codec compromise."
] The compromise text that was discussed appears in slides 12-14 at [4]
] (which is a slight editorial variation of the text proposed at [2]).
]
] This message serves to confirm the sense of the room.

=C2=A0 =C2=A0Actually, as I read this more carefully, that isn't a cons= ensus call.
Sean goes on to dismiss the objections he heard in the room:

He's addressing them. What exactly is the problem= with this?


] 3) Trigger:
] Objection: The "trigger" sentence [3] is all kinds of wrong bec= ause
] it's promising that the future IETF will update this specification. ] Response: Like any IETF proposal, an RFC that documents the current
] proposal can be changed through the consensus process at any other time.<= br>
=C2=A0 =C2=A0Sean is specifically saying the "trigger" should be = discussed
on-list.

I don't read this this way= at all, Rather he's saying that in the future we
can update = the RFC. But yes, we can discuss the trigger on-list. Do you
have= some substantive objection that wasn't raised in HNL and/or
= hasn't been discussed to death here?

=C2=A0
] After the discussion, some clarifying questions about the hums, and
] typing the hum questions on the screen, there was rough consensus in
] the room to add (aka "shove") the proposed text into
] draft-ietf-rtcweb-video. In keeping with IETF process, I am confirming ] this consensus call on the list.

=C2=A0 =C2=A0This _is_ calling for consensus.

=C2=A0 =C2=A0But Sean omitted saying _what_ text; and agreed that the exact= text
may not have been clear to those in the room.

Huh? The "proposed text" that was discussed in HNL is on t= he slide and
that's what's being referred to here. Adam e= dited text which is substantially
the same into the draft.
<= div>

=C2=A0
] If anyone has any other issues that they would like to raise please do ] by December 19th.

=C2=A0 =C2=A0(And folks have been doing so.)

=C2=A0 =C2=A0I have asked on-list for the exact text before raising my issu= es,
since my issues relate to the text, not the choosing to have two MTIs.
<= /blockquote>

As I pointed out in my original message, th= at text is in Adam's draft.

Again, it's to= tally procedurally regular to have rough consensus on text in
the= WG meeting and on the list and then have the editor edit in substantively<= /div>
the same text to the draft. If you think there is some respect in= which those
two blocks of text are not in fact the same, please = point to it. Otherwise,
this is just dilatory.


> And this message clearly points to the slides above.

=C2=A0 =C2=A0I don't find it helpful to attack the people who ra= ise issues. YMMV.

=C2=A0 =C2=A0But what EKR thinks really doesn't matter. He is not a WGC= .

Ironic that you would complain about = "attack"s in a thread where you
started out by attackin= g Adam Roach and here say "what EKR thinks
really doesn'= t matter"

-Ekr
--001a11c37e02b25d5e050a583250-- From nobody Tue Dec 16 09:03:16 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242091A6FD5 for ; Tue, 16 Dec 2014 09:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUZCf2QAL_LK for ; Tue, 16 Dec 2014 09:03:10 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2A31A6FDB for ; Tue, 16 Dec 2014 09:03:08 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 50BE0C94BE; Tue, 16 Dec 2014 12:03:06 -0500 (EST) Date: Tue, 16 Dec 2014 12:03:06 -0500 From: John Leslie To: "rtcweb@ietf.org" Message-ID: <20141216170306.GX47023@verdi> References: <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IUPW9zT0I7STOY5X6fTFCNFua44 Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 17:03:13 -0000 Eric Rescorla wrote: > > > > Ironic that you would complain about "attack"s in a thread where you > started out by attacking Adam Roach and here say "what EKR thinks > really doesn't matter" Folks, please excuse me for deciding not to respond. -- John Leslie From nobody Tue Dec 16 09:40:47 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704F21A701D for ; Tue, 16 Dec 2014 09:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ha_mPS2WJ03l for ; Tue, 16 Dec 2014 09:40:40 -0800 (PST) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5951A701A for ; Tue, 16 Dec 2014 09:40:40 -0800 (PST) Received: by mail-vc0-f175.google.com with SMTP id hy10so6665228vcb.34 for ; Tue, 16 Dec 2014 09:40:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HswboJgASv6fUuAZ94MtJPzfb8E8Keic7oQ3SPgBBsM=; b=KN9UP42o7eK7IOcB0cexT06lQP5c8yHiRGIdrJ+KuFtRP9bKM5E3qEe7jW23i80n/8 oCGD8VVWt1161C0l/HolfFyQMt12HWpecBwTo4ALSNtOcvaWY/eCeMTYXnP7QYqzUCqu Fk4k77k3hQXNGiA13bFs+/3mBPp4NzXLG7aHednqGRSYgCXNG7Jy0ajlN3aA0P1smdRy Eqx3tTJGsNjyXzsx2eNfV8Ad4psFLUwFJbKn8+v0C1A2HbsjGCGDgST/qU1DU/b3rfbO LHY20LfXp4QFDpcNd3rPjGmNnTlgf5LupHYFCXwXgAx93pnEYlJ07zs+uLjB6Wxf5a0x IfhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HswboJgASv6fUuAZ94MtJPzfb8E8Keic7oQ3SPgBBsM=; b=YxRT7KXTlKeVPrRO6iF5MrZZwW4tbDrI5EVrAf1xKI2w6kiD/WYoDqNvaKKJfBs4LG uf8fsQihjhDvAB4j1/6EsA98u7hVty0/Oj7KZDGkY87SxCkOVm8TbcQ2qZjGSfsAZ4WQ zc/+sjyFGXiYW3l1OEeEh3rHRNuIPPa/LO+cG6GiKryhoU1P+cUS0HGZsiwa0/rLmR1U 8WyWb6EnRre9/oWatc4S2KeixZHyzqOpCp1wixRUx9VxOUIBLA3Gi9jdGAIOf79pHSYj rcGdqVTz1v5B9mSoGjjshALgdYcvdhaDNr2Y5csOUFY2ElhS2h149D8oHN/jLwlWSAsK aw3g== X-Gm-Message-State: ALoCoQlsFME4GtGzDnESk2upsoh6zEclZQE4MejhnEyKpGakwUlY4qMyDcZz5U8V8m1WYPGlZeqI X-Received: by 10.53.1.134 with SMTP id bg6mr19603484vdd.37.1418751639111; Tue, 16 Dec 2014 09:40:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.10.229 with HTTP; Tue, 16 Dec 2014 09:40:18 -0800 (PST) In-Reply-To: References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E63FD67@MCHP04MSX.global-ad.net> From: Justin Uberti Date: Tue, 16 Dec 2014 09:40:18 -0800 Message-ID: To: =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Content-Type: multipart/alternative; boundary=001a1135f22c796cee050a58db00 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/i2EDTUhnV1HDevC-RpEH9BBhmmk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 17:40:42 -0000 --001a1135f22c796cee050a58db00 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Given that TURN servers can be used for STUN, is there a need to autodiscover STUN-only servers? On Mon, Dec 15, 2014 at 5:23 PM, =F0=9F=94=93Dan Wing wro= te: > > > On Dec 15, 2014, at 7:56 AM, Hutton, Andrew > wrote: > > +1 Also wondering why it is not appropriate? > > F20 in the requirements draft states: > > F20 The browser must support the use of STUN and TURN > servers that are supplied by entities other than > the web application (i.e. the network provider). > > So I was thinking the need for specifying the discovery method would not > be controversial. > > > Note that draft-ietf-tram-turn-server-discovery only discovers TURN > servers. If we need to discover STUN servers, too -- and I think we do -= - > we need that document to expand its scope or a second document. > > I recently attended a talk where Matt Peterson presented Burning Man's > network. That network assigns RFC6598 addresses to each Burning Man > "camp", and their ISP provides CGN'd addresses to Burning Man. Each camp > operates its own WiFi network, and we can all reasonably assume they are > using typical consumer or SMB NAPT devices for those networks (e.g., > D-Link, Linksys, Ubiquity, etc.). To avoid tromboning camp-to-camp WebRT= C > traffic to their ISP's CGN, they would benefit from a STUN and a TURN > server within the Burning Man network. His presentation can be found at > https://www.nanog.org/meetings/nanog62/agenda (PDF and video). > > -d > > > > Andy > > > *From:* Simon Perreault [mailto:sperreault@jive.com = ] > > *Sent:* 15 December 2014 15:49 > *To:* Eric Rescorla > *Cc:* Hutton, Andrew; rtcweb@ietf.org > *Subject:* Re: [rtcweb] rtcweb-transports reference to TRAM discovery > > > On Mon, Dec 15, 2014 at 10:44 AM, Eric Rescorla wrote: > I do not believe that this is an appropriate requirement > > Care to say why? > > Thanks, > Simon > _______________________________________________ > 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 > > --001a1135f22c796cee050a58db00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Given that TURN servers can be used for STUN, is there a n= eed to autodiscover STUN-only servers?

=
On Mon, Dec 15, 2014 at 5:23 PM, =F0=9F=94=93Dan= Wing <dwing@cisco.com> wrote:
<= div style=3D"word-wrap:break-word">
On Dec 15= , 2014, at 7:56 AM, Hutton, Andrew <andrew.hutton@unify.com> wrote:

+1 Also wondering why it i= s not appropriate?
=C2=A0
F20 in the requirements = draft states:
=C2= =A0
F20=C2=A0=C2=A0=C2=A0=C2=A0 The browser must support the use = of STUN and TURN
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 servers that are supplied by entities other tha= n
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 the web application (i.e. the network provider).=
=C2=A0
So I was thinking the need for specifying the discover= y method would not be controversial.
<= div>
Note that draft-ietf-tram-turn-server-discovery o= nly discovers TURN servers.=C2=A0 If we need to discover STUN servers, too = -- and I think we do -- we need that document to expand its scope or a seco= nd document.

I recently attended a talk where Matt= Peterson presented Burning Man's network.=C2=A0 That network assigns R= FC6598 addresses to each Burning Man "camp", and their ISP provid= es CGN'd addresses to Burning Man.=C2=A0 Each camp operates its own WiF= i network, and we can all reasonably assume they are using typical consumer= or SMB NAPT devices for those networks (e.g., D-Link, Linksys, Ubiquity, e= tc.).=C2=A0 To avoid tromboning camp-to-camp WebRTC traffic to their ISP= 9;s CGN, they would benefit from a STUN and a TURN server within the Burnin= g Man network.=C2=A0 His presentation can be found at=C2=A0https://www.nan= og.org/meetings/nanog62/agenda (PDF and video).

-d

=
=C2=A0
Andy
=C2=A0
=C2=A0
From:=C2=A0S= imon Perreault [ma= ilto:sperreault@jive.com]=C2=A0
Sent:=C2= =A015 December 2014 15:49
To:=C2=A0Eric Resco= rla
Cc:=C2=A0Hutton, Andrew; rtcweb@ietf.org
Subject:= =C2=A0Re: [rtcweb] rtcweb-transports reference to TRAM discovery<= /u>
=C2=A0<= /u>
=C2=A0
On Mon, Dec 15, 2014 at 10:44 AM, Eric Rescorla <ekr@rtfm.com> wrote:
I do not believe that this is an appropriate requirement

Care to say why?<= u>
=C2=A0
Thanks,
Simon
_______________________________________________
rtcweb ma= iling list
rtcweb@i= etf.org
https://www.ietf.org/mailman/listinfo/rtcweb


_________________________________________= ______
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--001a1135f22c796cee050a58db00-- From nobody Tue Dec 16 11:17:06 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2981A8722 for ; Tue, 16 Dec 2014 11:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTjcTH1yi5YZ for ; Tue, 16 Dec 2014 11:17:02 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB0F1A1B99 for ; Tue, 16 Dec 2014 11:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12846; q=dns/txt; s=iport; t=1418757422; x=1419967022; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=Q3HCT+f0ZtquBZAGPfjwbBJd/+VEtUre+90OSVEsNzI=; b=FQlCSV4IJ2x3hYhGt//zsiPoWDTM0x9utk20nDGFjPnWFcdEt72cbQlA x+1zCDbtnmrYmqqugdUE478II9FV+qO6Ai+A6Mgva1Uys6kJ05jNN4VeQ f3+fB91xwvdv8/3OIn/n7goWqYH7JE0xm0iew0DTRSa3H5xvIVCILXVqh 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwFAMCEkFStJA2I/2dsb2JhbABagkNDUliDBsJoAQmFKEoCgRwWAQEBAQF9hAwBAQEDAQEBASBLCwULCQIOAwQBAQEnAwICJx8JCAYTiCQIDaIFnGiWKwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEj24EBgGCaC6BEwWEJgKFFo0zhXmLQCKEDR0wgkMBAQE X-IronPort-AV: E=Sophos;i="5.07,588,1413244800"; d="scan'208,217";a="380753801" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP; 16 Dec 2014 19:16:53 +0000 Received: from [10.24.103.149] ([10.24.103.149]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBGJGpi6019077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Dec 2014 19:16:52 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_4658D63F-FC96-45FC-BAE5-9F3C37BB5AFF" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Tue, 16 Dec 2014 11:16:55 -0800 Message-Id: References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E63FD67@MCHP04MSX.global-ad.net> To: Justin Uberti X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/h4ZITbak_nqU_ymSJzIRI6zuIWM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 19:17:04 -0000 --Apple-Mail=_4658D63F-FC96-45FC-BAE5-9F3C37BB5AFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 16, 2014, at 9:40 AM, Justin Uberti wrote: > Given that TURN servers can be used for STUN, is there a need to = autodiscover STUN-only servers? I am not aware of spec encouraging such implementations, and I don't = know if everyone implementing WebRTC clients is going to be aware that = TURN servers can provide useful information about the mapped IP address. = Perhaps it just needs a few sentences in an appropriate spec? -d >=20 > On Mon, Dec 15, 2014 at 5:23 PM, =F0=9F=94=93Dan Wing = wrote: >=20 > On Dec 15, 2014, at 7:56 AM, Hutton, Andrew = wrote: >=20 >> +1 Also wondering why it is not appropriate? >> =20 >> F20 in the requirements draft states: >> =20 >> F20 The browser must support the use of STUN and TURN >> servers that are supplied by entities other than >> the web application (i.e. the network provider). >> =20 >> So I was thinking the need for specifying the discovery method would = not be controversial. >=20 > Note that draft-ietf-tram-turn-server-discovery only discovers TURN = servers. If we need to discover STUN servers, too -- and I think we do = -- we need that document to expand its scope or a second document. >=20 > I recently attended a talk where Matt Peterson presented Burning Man's = network. That network assigns RFC6598 addresses to each Burning Man = "camp", and their ISP provides CGN'd addresses to Burning Man. Each = camp operates its own WiFi network, and we can all reasonably assume = they are using typical consumer or SMB NAPT devices for those networks = (e.g., D-Link, Linksys, Ubiquity, etc.). To avoid tromboning = camp-to-camp WebRTC traffic to their ISP's CGN, they would benefit from = a STUN and a TURN server within the Burning Man network. His = presentation can be found at = https://www.nanog.org/meetings/nanog62/agenda (PDF and video). >=20 > -d >=20 >=20 >> =20 >> Andy >> =20 >> =20 >> From: Simon Perreault [mailto:sperreault@jive.com]=20 >> Sent: 15 December 2014 15:49 >> To: Eric Rescorla >> Cc: Hutton, Andrew; rtcweb@ietf.org >> Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery >> =20 >> =20 >> On Mon, Dec 15, 2014 at 10:44 AM, Eric Rescorla wrote: >> I do not believe that this is an appropriate requirement >>=20 >> Care to say why? >> =20 >> Thanks, >> Simon >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 --Apple-Mail=_4658D63F-FC96-45FC-BAE5-9F3C37BB5AFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Dec 16, 2014, at 9:40 AM, Justin = Uberti <juberti@google.com> = wrote:

Given that TURN servers can be used = for STUN, is there a need to autodiscover STUN-only = servers?

I am not aware of spec = encouraging such implementations, and I don't know if everyone = implementing WebRTC clients is going to be aware that TURN servers can = provide useful information about the mapped IP address.  Perhaps it = just needs a few sentences in an appropriate = spec?

-d



On= Mon, Dec 15, 2014 at 5:23 PM, =F0=9F=94=93Dan Wing <dwing@cisco.com> wrote:

On Dec 15, 2014, at 7:56 AM, Hutton, Andrew <andrew.hutton@unify.com> = wrote:

+1 Also wondering why it is not = appropriate?
 
F20 in the requirements draft states:
 
F20     The = browser must support the use of STUN and = TURN
           = servers that are supplied by entities other = than
           the = web application (i.e. the network = provider).
 
So I was thinking the need for specifying the discovery method would = not be = controversial.

N= ote that draft-ietf-tram-turn-server-discovery only discovers TURN = servers.  If we need to discover STUN servers, too -- and I think = we do -- we need that document to expand its scope or a second = document.

I recently attended a talk where Matt = Peterson presented Burning Man's network.  That network assigns = RFC6598 addresses to each Burning Man "camp", and their ISP provides = CGN'd addresses to Burning Man.  Each camp operates its own WiFi = network, and we can all reasonably assume they are using typical = consumer or SMB NAPT devices for those networks (e.g., D-Link, Linksys, = Ubiquity, etc.).  To avoid tromboning camp-to-camp WebRTC traffic = to their ISP's CGN, they would benefit from a STUN and a TURN server = within the Burning Man network.  His presentation can be found = at https://www.nanog.org/meetings/nanog62/agenda (PDF = and video).

-d


 
Andy
 
 
From: = Simon Perreault [mailto:sperreault@jive.com] 
Sent: 15 December 2014 = 15:49
To: Eric = Rescorla
Cc: Hutton, Andrew; rtcweb@ietf.org
Subject: Re: [rtcweb] rtcweb-transports reference to TRAM = discovery
 
 
On Mon, = Dec 15, 2014 at 10:44 AM, Eric Rescorla <ekr@rtfm.com> wrote:
I do not believe that this is an appropriate = requirement

Care to = say why?
 
Thanks,
Simon
_______________________________________________
rtcweb = mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb<= /div>


____________________________________= ___________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


= --Apple-Mail=_4658D63F-FC96-45FC-BAE5-9F3C37BB5AFF-- From nobody Tue Dec 16 11:26:24 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415011A8713 for ; Tue, 16 Dec 2014 11:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJY8iccYBgU6 for ; Tue, 16 Dec 2014 11:26:20 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id D2CA31A86EC for ; Tue, 16 Dec 2014 11:26:19 -0800 (PST) Received: from xct107cnc.rim.net ([10.65.161.207]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 16 Dec 2014 14:26:14 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT107CNC.rim.net ([fe80::b815:71ef:9f8f:e07c%16]) with mapi id 14.03.0210.002; Tue, 16 Dec 2014 14:26:13 -0500 From: Gaelle Martin-Cocher To: Eric Rescorla , John Leslie Thread-Topic: [rtcweb] revisiting MTI Thread-Index: AQHQGK9hz+EPVQM3202R+pzBLk6Ke5yRiFAAgAAEJwCAAAEZAIAAAMsAgAAFmwCAARFEgIAAAWIAgAADogCAAAQ5gIAADdEAgAAHm4D//9TVIA== Date: Tue, 16 Dec 2014 19:26:13 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF363463@XMB111CNC.rim.net> References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> In-Reply-To: Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: multipart/alternative; boundary="_000_92D0D52F3A63344CA478CF12DB0648AADF363463XMB111CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/oPxuuWAATVAON3MuAPztgMvicfg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 19:26:22 -0000 --_000_92D0D52F3A63344CA478CF12DB0648AADF363463XMB111CNCrimnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEVyaWMgUmVzY29ybGENClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDE2LCAyMDE0IDExOjUz IEFNDQpUbzogSm9obiBMZXNsaWUNCkNjOiBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb cnRjd2ViXSByZXZpc2l0aW5nIE1USQ0KDQoNCiAgIFNlYW4gaXMgc3BlY2lmaWNhbGx5IHNheWlu ZyB0aGUgInRyaWdnZXIiIHNob3VsZCBiZSBkaXNjdXNzZWQNCm9uLWxpc3QuDQoNCkkgZG9uJ3Qg cmVhZCB0aGlzIHRoaXMgd2F5IGF0IGFsbCwgUmF0aGVyIGhlJ3Mgc2F5aW5nIHRoYXQgaW4gdGhl IGZ1dHVyZSB3ZQ0KY2FuIHVwZGF0ZSB0aGUgUkZDLiBCdXQgeWVzLCB3ZSBjYW4gZGlzY3VzcyB0 aGUgdHJpZ2dlciBvbi1saXN0LiBEbyB5b3UNCmhhdmUgc29tZSBzdWJzdGFudGl2ZSBvYmplY3Rp b24gdGhhdCB3YXNuJ3QgcmFpc2VkIGluIEhOTCBhbmQvb3INCmhhc24ndCBiZWVuIGRpc2N1c3Nl ZCB0byBkZWF0aCBoZXJlPw0KDQogSSB0aGluayB3aGF0IGhhcyBub3QgYmVlbiBkaXNjdXNzZWQg aXMgYSBkaWZmZXJlbnRpYXRlZCB0ZXh0IGZvciBib3RoIGNvZGVjcy4NClZQOCB0byBiZSBkZXBy ZWNhdGVkIGlmIGZhaWxpbmcgdG8gbWVldCBSRiBzdGF0ZW1lbnRzIGZyb20gcHJvcG9uZW50cw0K SDI2NCB0byBiZSBkZXByZWNhdGVkIHdoZW4gbm90IHVzZWQgYW55bW9yZSBieSBsZWdhY3kgc2Vy dmljZXMgaW4gYWNjb3JkYW5jZSB3aXRoIEgyNjQgcHJvcG9uZW50cyBzdGF0ZW1lbnRzDQoNCkdh w6tsbGUNCg0KDQo= --_000_92D0D52F3A63344CA478CF12DB0648AADF363463XMB111CNCrimnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjo3MC44NXB0 IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRGVjZW1i ZXIgMTYsIDIwMTQgMTE6NTMgQU08YnI+DQo8Yj5Ubzo8L2I+IEpvaG4gTGVzbGllPGJyPg0KPGI+ Q2M6PC9iPiBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJd IHJldmlzaXRpbmcgTVRJPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJm5ic3A7ICZuYnNwO1NlYW4gaXMgc3BlY2lm aWNhbGx5IHNheWluZyB0aGUgJnF1b3Q7dHJpZ2dlciZxdW90OyBzaG91bGQgYmUgZGlzY3Vzc2Vk PGJyPg0Kb24tbGlzdC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgcmVhZCB0aGlzIHRoaXMgd2F5IGF0IGFsbCwgUmF0 aGVyIGhlJ3Mgc2F5aW5nIHRoYXQgaW4gdGhlIGZ1dHVyZSB3ZTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y2FuIHVwZGF0ZSB0aGUgUkZDLiBCdXQg eWVzLCB3ZSBjYW4gZGlzY3VzcyB0aGUgdHJpZ2dlciBvbi1saXN0LiBEbyB5b3U8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmhhdmUgc29tZSBzdWJz dGFudGl2ZSBvYmplY3Rpb24gdGhhdCB3YXNuJ3QgcmFpc2VkIGluIEhOTCBhbmQvb3I8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmhhc24ndCBiZWVu IGRpc2N1c3NlZCB0byBkZWF0aCBoZXJlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ SSB0aGluayB3aGF0IGhhcyBub3QgYmVlbiBkaXNjdXNzZWQgaXMgYSBkaWZmZXJlbnRpYXRlZCB0 ZXh0IGZvciBib3RoIGNvZGVjcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5WUDgg dG8gYmUgZGVwcmVjYXRlZCBpZiBmYWlsaW5nIHRvIG1lZXQgUkYgc3RhdGVtZW50cyBmcm9tIHBy b3BvbmVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SDI2NCB0byBiZSBkZXByZWNh dGVkIHdoZW4gbm90IHVzZWQgYW55bW9yZSBieSBsZWdhY3kgc2VydmljZXMgaW4gYWNjb3JkYW5j ZSB3aXRoIEgyNjQgcHJvcG9uZW50cyBzdGF0ZW1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5HYcOrbGxlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_92D0D52F3A63344CA478CF12DB0648AADF363463XMB111CNCrimnet_-- From nobody Tue Dec 16 11:31:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FC51A8727 for ; Tue, 16 Dec 2014 11:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuKFcinnMBH4 for ; Tue, 16 Dec 2014 11:31:51 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 945151A8713 for ; Tue, 16 Dec 2014 11:31:50 -0800 (PST) Received: from smtp-pop.rim.net (HELO XCT103CNC.rim.net) ([10.65.161.203]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 16 Dec 2014 14:31:44 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT103CNC.rim.net ([fe80::b8:d5e:26a5:f4d6%17]) with mapi id 14.03.0210.002; Tue, 16 Dec 2014 14:31:43 -0500 From: Gaelle Martin-Cocher To: Eric Rescorla , John Leslie Thread-Topic: [rtcweb] revisiting MTI Thread-Index: AQHQGK9hz+EPVQM3202R+pzBLk6Ke5yRiFAAgAAEJwCAAAEZAIAAAMsAgAAFmwCAARFEgIAAAWIAgAADogCAAAQ5gIAADdEAgAAHm4D//9Il8A== Date: Tue, 16 Dec 2014 19:31:42 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF3634AA@XMB111CNC.rim.net> References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> In-Reply-To: Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: multipart/alternative; boundary="_000_92D0D52F3A63344CA478CF12DB0648AADF3634AAXMB111CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GNeNF69GIG4yHgCgj300BNdgJzs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 19:31:54 -0000 --_000_92D0D52F3A63344CA478CF12DB0648AADF3634AAXMB111CNCrimnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIGxpdHRsZSBjb25maWRlbmNlIHRoYXQgdGhlIGNob2ljZSBiZXR3ZWVuIEgyNjUgYW5k IFZQOSB3aWxsIGJlIGVhc2llciB0aGFuIGl0IGlzIHRvZGF5IGJldHdlZW4gVlA4IGFuZCBIMjY0 Lg0KQXJlIHdlIGdvaW5nIHRvIG11bHRpcGx5IHNpbWlsYXJseSBwZXJmb3JtaW5nIGNvZGVjcyAg Z29pbmcgZm9yd2FyZCAoaW4gdGhlIHNwZWMgb3IgaW4gcHJhY3RpY2UpIG9yIGJlIHN0dWNrIHdp dGggbWFuZGF0b3J5IGxvdyBwZXJmb3JtaW5nIGNvZGVjcyBiZWNhdXNlIHdlIGNhbm5vdCBtYWtl IGJldHRlciBkZWNpc2lvbj8NClRpbWUgZnJhbWUgZm9yIEgyNjUgLyBWUDkgIGlzIHVwIHRvIHR3 byB5ZWFycyBmcm9tIG5vdw0KQW5kIHBvc3NpYmx5IHRoZSB0aW1lZnJhbWUgZm9yIEguMjY2L0Rh bGFhIGlzIGZvdXIgeWVhcnMgZnJvbSBub3cNCg0KVGhpcyBpcyBvbmUgbW9yZSBkcmF3YmFjayBv ZiB0aGUgcHJvcG9zZWQgdGV4dCBmb3IgTVRJLCBub3Qgb25seSBpdCBtdWx0aXBsaWVzIGVuY29k ZXJzIGFuZCBkZWNvZGVycyB0byBiZSBzdXBwb3J0ZWQgYnV0ICBjYW4gcHJldmVudCB0aGUgZXZv bHV0aW9uIG9mIHdlYnJ0YyB0b3dhcmQgbW9yZSBhZHZhbmNlcyBjb2RlY3MuIChhc3N1bWluZyB3 ZSB3aWxsIG5vdCByZXF1aXJlIDQgb3IgNiBlbmNvZGVycyBhbmQgNCBvciA2IGRlY29kZXJzIHRv IGJlIHN1cHBvcnRlZCBieSBldmVyeSBzaW5nbGUgZW5kcG9pbnRzLiBUd28gTVRJIHNlZW1zIGxh cmdlbHkgZW5vdWdoLCBubz8pLg0KDQpHYcOrbGxlDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0 Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDog VHVlc2RheSwgRGVjZW1iZXIgMTYsIDIwMTQgMTE6NTMgQU0NClRvOiBKb2huIExlc2xpZQ0KQ2M6 IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIHJldmlzaXRpbmcgTVRJDQoN Ck9uIFR1ZSwgRGVjIDE2LCAyMDE0IGF0IDg6MjUgQU0sIEpvaG4gTGVzbGllIDxqb2huQGpsYy5u ZXQ8bWFpbHRvOmpvaG5AamxjLm5ldD4+IHdyb3RlOg0KRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0u Y29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToNCj4gT24gVHVlLCBEZWMgMTYsIDIwMTQg YXQgNzoyMSBBTSwgSm9obiBMZXNsaWUgPGpvaG5AamxjLm5ldDxtYWlsdG86am9obkBqbGMubmV0 Pj4gd3JvdGU6DQo+IE5lZWRsZXNzIHRvIHNheSwgaGF2aW5nIFdHIGNvbnNlbnN1cyBvbiB0aGUg c3Vic3RhbmNlIGFuZCBsZXR0aW5nIHRoZQ0KPiBlZGl0b3Igd29yZHNtaXRoIHRoZSB0ZXh0IGlz IHRvdGFsbHkgbm9ybWFsIElFVEYgcHJvY2Vzcy4NCg0KICAgSW4gc29tZSBjYXNlcywgeWVzLiBJ TUhPLCB0aGlzIGlzIG5vdCBvbmUgb2YgdGhlbS4gWU1NVi4uLg0KDQpJbmRlZWQgaXQgZG9lcywg c2luY2UgSSBoYXZlICpuZXZlciogaGVhcmQgb2Ygc3VjaCBhIGNhc2Ugd2hlcmUNCnRoZSBlZGl0 b3IgaGFkIG5vIGRpc2NyZXRpb24gdG8gY2hhbmdlIHRoZSB0ZXh0IGluIHB1cmVseSBlZGl0b3Jp YWwNCndheXMgKHN1YmplY3QgdG8gV0cgY29uc2Vuc3VzIG9mIGNvdXJzZSkuIEZlZWwgZnJlZSB0 byBjaXRlIG9uZQ0KaWYgeW91IGhhdmUgb25lLg0KDQoNCj4gSSBoYXZlbid0IGhlYXJkIGFueW9u ZSB3aG8gd2FzIGF0IEhOTCBhbmQgaW4gZmF2b3Igb2YgdGhlIHRleHQgb24gdGhlDQo+IHNsaWRl cyBvYmplY3QgdGhhdCBBZGFtJ3MgdGV4dCBpbiB0aGUgZHJhZnQgZG9lc24ndCByZWZsZWN0IHRo b3NlDQo+IHNsaWRlcy4NCg0KICAgUHJvYmFibHkgeW91IGhhdmVuJ3QuLi4NCg0KVG8gdGhlIGJl c3Qgb2YgbXkga25vd2xlZGdlIGl0IGhhc24ndCBoYXBwZW5lZC4gQ2FuIHlvdSBjaXRlIGFueW9u ZQ0Kd2hvIGhhcyBzbyBvYmplY3RlZC4NCg0KDQoNCj4gQmVzaWRlcywgRXJpYyBpc24ndCB0aGUg V0dDIGNhbGxpbmcgY29uc2Vuc3VzLg0KPg0KPiBObywgdGhlIGNoYWlycyBkaWQgaGVyZToNCj4g aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50L21zZzEz Njk2Lmh0bWwNCl0NCl0gRnJvbTogU2VhbiBUdXJuZXIgPHR1cm5lcnMgYXQgaWVjYS5jb208aHR0 cDovL2llY2EuY29tPj4NCl0gQXQgdGhlIDJuZCBSVEN3ZWIgV0cgc2Vzc2lvbiBAIElFVEYgOTEs IHdlIGhhZCBhIGxpdmVseSBkaXNjdXNzaW9uDQpdIGFib3V0IGNvZGVjcywgd2hpY2ggSSBkdWJi ZWQgInRoZSBncmVhdCBjb2RlYyBjb21wcm9taXNlLiINCl0gVGhlIGNvbXByb21pc2UgdGV4dCB0 aGF0IHdhcyBkaXNjdXNzZWQgYXBwZWFycyBpbiBzbGlkZXMgMTItMTQgYXQgWzRdDQpdICh3aGlj aCBpcyBhIHNsaWdodCBlZGl0b3JpYWwgdmFyaWF0aW9uIG9mIHRoZSB0ZXh0IHByb3Bvc2VkIGF0 IFsyXSkuDQpdDQpdIFRoaXMgbWVzc2FnZSBzZXJ2ZXMgdG8gY29uZmlybSB0aGUgc2Vuc2Ugb2Yg dGhlIHJvb20uDQoNCiAgIEFjdHVhbGx5LCBhcyBJIHJlYWQgdGhpcyBtb3JlIGNhcmVmdWxseSwg dGhhdCBpc24ndCBhIGNvbnNlbnN1cyBjYWxsLg0KU2VhbiBnb2VzIG9uIHRvIGRpc21pc3MgdGhl IG9iamVjdGlvbnMgaGUgaGVhcmQgaW4gdGhlIHJvb206DQoNCkhlJ3MgYWRkcmVzc2luZyB0aGVt LiBXaGF0IGV4YWN0bHkgaXMgdGhlIHByb2JsZW0gd2l0aCB0aGlzPw0KDQoNCl0gMykgVHJpZ2dl cjoNCl0gT2JqZWN0aW9uOiBUaGUgInRyaWdnZXIiIHNlbnRlbmNlIFszXSBpcyBhbGwga2luZHMg b2Ygd3JvbmcgYmVjYXVzZQ0KXSBpdCdzIHByb21pc2luZyB0aGF0IHRoZSBmdXR1cmUgSUVURiB3 aWxsIHVwZGF0ZSB0aGlzIHNwZWNpZmljYXRpb24uDQpdIFJlc3BvbnNlOiBMaWtlIGFueSBJRVRG IHByb3Bvc2FsLCBhbiBSRkMgdGhhdCBkb2N1bWVudHMgdGhlIGN1cnJlbnQNCl0gcHJvcG9zYWwg Y2FuIGJlIGNoYW5nZWQgdGhyb3VnaCB0aGUgY29uc2Vuc3VzIHByb2Nlc3MgYXQgYW55IG90aGVy IHRpbWUuDQoNCiAgIFNlYW4gaXMgc3BlY2lmaWNhbGx5IHNheWluZyB0aGUgInRyaWdnZXIiIHNo b3VsZCBiZSBkaXNjdXNzZWQNCm9uLWxpc3QuDQoNCkkgZG9uJ3QgcmVhZCB0aGlzIHRoaXMgd2F5 IGF0IGFsbCwgUmF0aGVyIGhlJ3Mgc2F5aW5nIHRoYXQgaW4gdGhlIGZ1dHVyZSB3ZQ0KY2FuIHVw ZGF0ZSB0aGUgUkZDLiBCdXQgeWVzLCB3ZSBjYW4gZGlzY3VzcyB0aGUgdHJpZ2dlciBvbi1saXN0 LiBEbyB5b3UNCmhhdmUgc29tZSBzdWJzdGFudGl2ZSBvYmplY3Rpb24gdGhhdCB3YXNuJ3QgcmFp c2VkIGluIEhOTCBhbmQvb3INCmhhc24ndCBiZWVuIGRpc2N1c3NlZCB0byBkZWF0aCBoZXJlPw0K DQoNCl0gQWZ0ZXIgdGhlIGRpc2N1c3Npb24sIHNvbWUgY2xhcmlmeWluZyBxdWVzdGlvbnMgYWJv dXQgdGhlIGh1bXMsIGFuZA0KXSB0eXBpbmcgdGhlIGh1bSBxdWVzdGlvbnMgb24gdGhlIHNjcmVl biwgdGhlcmUgd2FzIHJvdWdoIGNvbnNlbnN1cyBpbg0KXSB0aGUgcm9vbSB0byBhZGQgKGFrYSAi c2hvdmUiKSB0aGUgcHJvcG9zZWQgdGV4dCBpbnRvDQpdIGRyYWZ0LWlldGYtcnRjd2ViLXZpZGVv LiBJbiBrZWVwaW5nIHdpdGggSUVURiBwcm9jZXNzLCBJIGFtIGNvbmZpcm1pbmcNCl0gdGhpcyBj b25zZW5zdXMgY2FsbCBvbiB0aGUgbGlzdC4NCg0KICAgVGhpcyBfaXNfIGNhbGxpbmcgZm9yIGNv bnNlbnN1cy4NCg0KICAgQnV0IFNlYW4gb21pdHRlZCBzYXlpbmcgX3doYXRfIHRleHQ7IGFuZCBh Z3JlZWQgdGhhdCB0aGUgZXhhY3QgdGV4dA0KbWF5IG5vdCBoYXZlIGJlZW4gY2xlYXIgdG8gdGhv c2UgaW4gdGhlIHJvb20uDQoNCkh1aD8gVGhlICJwcm9wb3NlZCB0ZXh0IiB0aGF0IHdhcyBkaXNj dXNzZWQgaW4gSE5MIGlzIG9uIHRoZSBzbGlkZSBhbmQNCnRoYXQncyB3aGF0J3MgYmVpbmcgcmVm ZXJyZWQgdG8gaGVyZS4gQWRhbSBlZGl0ZWQgdGV4dCB3aGljaCBpcyBzdWJzdGFudGlhbGx5DQp0 aGUgc2FtZSBpbnRvIHRoZSBkcmFmdC4NCg0KDQoNCl0gSWYgYW55b25lIGhhcyBhbnkgb3RoZXIg aXNzdWVzIHRoYXQgdGhleSB3b3VsZCBsaWtlIHRvIHJhaXNlIHBsZWFzZSBkbw0KXSBieSBEZWNl bWJlciAxOXRoLg0KDQogICAoQW5kIGZvbGtzIGhhdmUgYmVlbiBkb2luZyBzby4pDQoNCiAgIEkg aGF2ZSBhc2tlZCBvbi1saXN0IGZvciB0aGUgZXhhY3QgdGV4dCBiZWZvcmUgcmFpc2luZyBteSBp c3N1ZXMsDQpzaW5jZSBteSBpc3N1ZXMgcmVsYXRlIHRvIHRoZSB0ZXh0LCBub3QgdGhlIGNob29z aW5nIHRvIGhhdmUgdHdvIE1USXMuDQoNCkFzIEkgcG9pbnRlZCBvdXQgaW4gbXkgb3JpZ2luYWwg bWVzc2FnZSwgdGhhdCB0ZXh0IGlzIGluIEFkYW0ncyBkcmFmdC4NCg0KQWdhaW4sIGl0J3MgdG90 YWxseSBwcm9jZWR1cmFsbHkgcmVndWxhciB0byBoYXZlIHJvdWdoIGNvbnNlbnN1cyBvbiB0ZXh0 IGluDQp0aGUgV0cgbWVldGluZyBhbmQgb24gdGhlIGxpc3QgYW5kIHRoZW4gaGF2ZSB0aGUgZWRp dG9yIGVkaXQgaW4gc3Vic3RhbnRpdmVseQ0KdGhlIHNhbWUgdGV4dCB0byB0aGUgZHJhZnQuIElm IHlvdSB0aGluayB0aGVyZSBpcyBzb21lIHJlc3BlY3QgaW4gd2hpY2ggdGhvc2UNCnR3byBibG9j a3Mgb2YgdGV4dCBhcmUgbm90IGluIGZhY3QgdGhlIHNhbWUsIHBsZWFzZSBwb2ludCB0byBpdC4g T3RoZXJ3aXNlLA0KdGhpcyBpcyBqdXN0IGRpbGF0b3J5Lg0KDQoNCj4gQW5kIHRoaXMgbWVzc2Fn ZSBjbGVhcmx5IHBvaW50cyB0byB0aGUgc2xpZGVzIGFib3ZlLg0KDQogICBJIGRvbid0IGZpbmQg aXQgaGVscGZ1bCB0byBhdHRhY2sgdGhlIHBlb3BsZSB3aG8gcmFpc2UgaXNzdWVzLiBZTU1WLg0K DQogICBCdXQgd2hhdCBFS1IgdGhpbmtzIHJlYWxseSBkb2Vzbid0IG1hdHRlci4gSGUgaXMgbm90 IGEgV0dDLg0KDQpJcm9uaWMgdGhhdCB5b3Ugd291bGQgY29tcGxhaW4gYWJvdXQgImF0dGFjayJz IGluIGEgdGhyZWFkIHdoZXJlIHlvdQ0Kc3RhcnRlZCBvdXQgYnkgYXR0YWNraW5nIEFkYW0gUm9h Y2ggYW5kIGhlcmUgc2F5ICJ3aGF0IEVLUiB0aGlua3MNCnJlYWxseSBkb2Vzbid0IG1hdHRlciIN Cg0KLUVrcg0K --_000_92D0D52F3A63344CA478CF12DB0648AADF3634AAXMB111CNCrimnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjo3MC44NXB0 IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGhhdmUg bGl0dGxlIGNvbmZpZGVuY2UgdGhhdCB0aGUgY2hvaWNlIGJldHdlZW4gSDI2NSBhbmQgVlA5IHdp bGwgYmUgZWFzaWVyIHRoYW4gaXQgaXMgdG9kYXkgYmV0d2VlbiBWUDggYW5kIEgyNjQuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXJlIHdlIGdvaW5nIHRvIG11bHRpcGx5IHNpbWls YXJseSBwZXJmb3JtaW5nIGNvZGVjcyAmbmJzcDtnb2luZyBmb3J3YXJkIChpbiB0aGUgc3BlYyBv ciBpbiBwcmFjdGljZSkgb3IgYmUgc3R1Y2sgd2l0aCBtYW5kYXRvcnkgbG93IHBlcmZvcm1pbmcg Y29kZWNzIGJlY2F1c2Ugd2UNCiBjYW5ub3QgbWFrZSBiZXR0ZXIgZGVjaXNpb24/IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaW1lIGZyYW1lIGZvciBIMjY1IC8gVlA5ICZuYnNwO2lz IHVwIHRvIHR3byB5ZWFycyBmcm9tIG5vdw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkFuZCBwb3NzaWJseSB0aGUgdGltZWZyYW1lIGZvciBILjI2Ni9EYWxhYSBpcyBmb3VyIHllYXJz IGZyb20gbm93PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGlzIG9uZSBtb3JlIGRyYXdiYWNrIG9mIHRoZSBwcm9w b3NlZCB0ZXh0IGZvciBNVEksIG5vdCBvbmx5IGl0IG11bHRpcGxpZXMgZW5jb2RlcnMgYW5kIGRl Y29kZXJzIHRvIGJlIHN1cHBvcnRlZCBidXQgJm5ic3A7Y2FuIHByZXZlbnQgdGhlIGV2b2x1dGlv biBvZiB3ZWJydGMNCiB0b3dhcmQgbW9yZSBhZHZhbmNlcyBjb2RlY3MuIChhc3N1bWluZyB3ZSB3 aWxsIG5vdCByZXF1aXJlIDQgb3IgNiBlbmNvZGVycyBhbmQgNCBvciA2IGRlY29kZXJzIHRvIGJl IHN1cHBvcnRlZCBieSBldmVyeSBzaW5nbGUgZW5kcG9pbnRzLiBUd28gTVRJIHNlZW1zIGxhcmdl bHkgZW5vdWdoLCBubz8pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+R2HDq2xsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4g VHVlc2RheSwgRGVjZW1iZXIgMTYsIDIwMTQgMTE6NTMgQU08YnI+DQo8Yj5Ubzo8L2I+IEpvaG4g TGVzbGllPGJyPg0KPGI+Q2M6PC9iPiBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtydGN3ZWJdIHJldmlzaXRpbmcgTVRJPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIERlYyAxNiwgMjAxNCBhdCA4OjI1IEFN LCBKb2huIExlc2xpZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvaG5AamxjLm5ldCIgdGFyZ2V0PSJf YmxhbmsiPmpvaG5AamxjLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZt LmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBPbiBUdWUsIERlYyAx NiwgMjAxNCBhdCA3OjIxIEFNLCBKb2huIExlc2xpZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvaG5A amxjLm5ldCI+am9obkBqbGMubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBOZWVkbGVzcyB0byBzYXksIGhhdmlu ZyBXRyBjb25zZW5zdXMgb24gdGhlIHN1YnN0YW5jZSBhbmQgbGV0dGluZyB0aGU8YnI+DQomZ3Q7 IGVkaXRvciB3b3Jkc21pdGggdGhlIHRleHQgaXMgdG90YWxseSBub3JtYWwgSUVURiBwcm9jZXNz Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtJbiBzb21lIGNhc2VzLCB5ZXMuIElNSE8sIHRoaXMg aXMgbm90IG9uZSBvZiB0aGVtLiBZTU1WLi4uPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbmRlZWQgaXQgZG9lcywgc2luY2UgSSBo YXZlICpuZXZlciogaGVhcmQgb2Ygc3VjaCBhIGNhc2Ugd2hlcmU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBlZGl0b3IgaGFkIG5vIGRpc2Ny ZXRpb24gdG8gY2hhbmdlIHRoZSB0ZXh0IGluIHB1cmVseSBlZGl0b3JpYWw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndheXMgKHN1YmplY3QgdG8g V0cgY29uc2Vuc3VzIG9mIGNvdXJzZSkuIEZlZWwgZnJlZSB0byBjaXRlIG9uZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aWYgeW91IGhhdmUgb25l LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsgSSBoYXZlbid0IGhlYXJkIGFueW9uZSB3aG8gd2FzIGF0IEhOTCBhbmQgaW4g ZmF2b3Igb2YgdGhlIHRleHQgb24gdGhlPGJyPg0KJmd0OyBzbGlkZXMgb2JqZWN0IHRoYXQgQWRh bSdzIHRleHQgaW4gdGhlIGRyYWZ0IGRvZXNuJ3QgcmVmbGVjdCB0aG9zZTxicj4NCiZndDsgc2xp ZGVzLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtQcm9iYWJseSB5b3UgaGF2ZW4ndC4uLjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VG8gdGhlIGJlc3Qgb2YgbXkga25vd2xlZGdlIGl0IGhhc24ndCBoYXBwZW5lZC4gQ2FuIHlvdSBj aXRlIGFueW9uZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+d2hvIGhhcyBzbyBvYmplY3RlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7IEJlc2lkZXMsIEVyaWMg aXNuJ3QgdGhlIFdHQyBjYWxsaW5nIGNvbnNlbnN1cy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBObywg dGhlIGNoYWlycyBkaWQgaGVyZTo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9ydGN3ZWIvY3VycmVudC9tc2cxMzY5Ni5odG1sIiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1 cnJlbnQvbXNnMTM2OTYuaHRtbDwvYT48YnI+DQpdPGJyPg0KXSBGcm9tOiBTZWFuIFR1cm5lciAm bHQ7dHVybmVycyBhdCA8YSBocmVmPSJodHRwOi8vaWVjYS5jb20iIHRhcmdldD0iX2JsYW5rIj5p ZWNhLmNvbTwvYT4mZ3Q7PGJyPg0KXSBBdCB0aGUgMm5kIFJUQ3dlYiBXRyBzZXNzaW9uIEAgSUVU RiA5MSwgd2UgaGFkIGEgbGl2ZWx5IGRpc2N1c3Npb248YnI+DQpdIGFib3V0IGNvZGVjcywgd2hp Y2ggSSBkdWJiZWQgJnF1b3Q7dGhlIGdyZWF0IGNvZGVjIGNvbXByb21pc2UuJnF1b3Q7PGJyPg0K XSBUaGUgY29tcHJvbWlzZSB0ZXh0IHRoYXQgd2FzIGRpc2N1c3NlZCBhcHBlYXJzIGluIHNsaWRl cyAxMi0xNCBhdCBbNF08YnI+DQpdICh3aGljaCBpcyBhIHNsaWdodCBlZGl0b3JpYWwgdmFyaWF0 aW9uIG9mIHRoZSB0ZXh0IHByb3Bvc2VkIGF0IFsyXSkuPGJyPg0KXTxicj4NCl0gVGhpcyBtZXNz YWdlIHNlcnZlcyB0byBjb25maXJtIHRoZSBzZW5zZSBvZiB0aGUgcm9vbS48YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7QWN0dWFsbHksIGFzIEkgcmVhZCB0aGlzIG1vcmUgY2FyZWZ1bGx5LCB0aGF0 IGlzbid0IGEgY29uc2Vuc3VzIGNhbGwuPGJyPg0KU2VhbiBnb2VzIG9uIHRvIGRpc21pc3MgdGhl IG9iamVjdGlvbnMgaGUgaGVhcmQgaW4gdGhlIHJvb206PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZSdzIGFkZHJlc3NpbmcgdGhl bS4gV2hhdCBleGFjdGx5IGlzIHRoZSBwcm9ibGVtIHdpdGggdGhpcz88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KXSAzKSBU cmlnZ2VyOjxicj4NCl0gT2JqZWN0aW9uOiBUaGUgJnF1b3Q7dHJpZ2dlciZxdW90OyBzZW50ZW5j ZSBbM10gaXMgYWxsIGtpbmRzIG9mIHdyb25nIGJlY2F1c2U8YnI+DQpdIGl0J3MgcHJvbWlzaW5n IHRoYXQgdGhlIGZ1dHVyZSBJRVRGIHdpbGwgdXBkYXRlIHRoaXMgc3BlY2lmaWNhdGlvbi48YnI+ DQpdIFJlc3BvbnNlOiBMaWtlIGFueSBJRVRGIHByb3Bvc2FsLCBhbiBSRkMgdGhhdCBkb2N1bWVu dHMgdGhlIGN1cnJlbnQ8YnI+DQpdIHByb3Bvc2FsIGNhbiBiZSBjaGFuZ2VkIHRocm91Z2ggdGhl IGNvbnNlbnN1cyBwcm9jZXNzIGF0IGFueSBvdGhlciB0aW1lLjxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDtTZWFuIGlzIHNwZWNpZmljYWxseSBzYXlpbmcgdGhlICZxdW90O3RyaWdnZXImcXVvdDsg c2hvdWxkIGJlIGRpc2N1c3NlZDxicj4NCm9uLWxpc3QuPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbid0IHJlYWQgdGhpcyB0 aGlzIHdheSBhdCBhbGwsIFJhdGhlciBoZSdzIHNheWluZyB0aGF0IGluIHRoZSBmdXR1cmUgd2U8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNhbiB1 cGRhdGUgdGhlIFJGQy4gQnV0IHllcywgd2UgY2FuIGRpc2N1c3MgdGhlIHRyaWdnZXIgb24tbGlz dC4gRG8geW91PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5oYXZlIHNvbWUgc3Vic3RhbnRpdmUgb2JqZWN0aW9uIHRoYXQgd2Fzbid0IHJhaXNlZCBp biBITkwgYW5kL29yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5oYXNuJ3QgYmVlbiBkaXNjdXNzZWQgdG8gZGVhdGggaGVyZT88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5dIEFmdGVy IHRoZSBkaXNjdXNzaW9uLCBzb21lIGNsYXJpZnlpbmcgcXVlc3Rpb25zIGFib3V0IHRoZSBodW1z LCBhbmQ8YnI+DQpdIHR5cGluZyB0aGUgaHVtIHF1ZXN0aW9ucyBvbiB0aGUgc2NyZWVuLCB0aGVy ZSB3YXMgcm91Z2ggY29uc2Vuc3VzIGluPGJyPg0KXSB0aGUgcm9vbSB0byBhZGQgKGFrYSAmcXVv dDtzaG92ZSZxdW90OykgdGhlIHByb3Bvc2VkIHRleHQgaW50bzxicj4NCl0gZHJhZnQtaWV0Zi1y dGN3ZWItdmlkZW8uIEluIGtlZXBpbmcgd2l0aCBJRVRGIHByb2Nlc3MsIEkgYW0gY29uZmlybWlu Zzxicj4NCl0gdGhpcyBjb25zZW5zdXMgY2FsbCBvbiB0aGUgbGlzdC48YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7VGhpcyBfaXNfIGNhbGxpbmcgZm9yIGNvbnNlbnN1cy48YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7QnV0IFNlYW4gb21pdHRlZCBzYXlpbmcgX3doYXRfIHRleHQ7IGFuZCBhZ3JlZWQg dGhhdCB0aGUgZXhhY3QgdGV4dDxicj4NCm1heSBub3QgaGF2ZSBiZWVuIGNsZWFyIHRvIHRob3Nl IGluIHRoZSByb29tLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SHVoPyBUaGUgJnF1b3Q7cHJvcG9zZWQgdGV4dCZxdW90OyB0aGF0 IHdhcyBkaXNjdXNzZWQgaW4gSE5MIGlzIG9uIHRoZSBzbGlkZSBhbmQ8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYXQncyB3aGF0J3MgYmVpbmcg cmVmZXJyZWQgdG8gaGVyZS4gQWRhbSBlZGl0ZWQgdGV4dCB3aGljaCBpcyBzdWJzdGFudGlhbGx5 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUg c2FtZSBpbnRvIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl0gSWYgYW55b25lIGhhcyBhbnkgb3RoZXIgaXNz dWVzIHRoYXQgdGhleSB3b3VsZCBsaWtlIHRvIHJhaXNlIHBsZWFzZSBkbzxicj4NCl0gYnkgRGVj ZW1iZXIgMTl0aC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7KEFuZCBmb2xrcyBoYXZlIGJlZW4g ZG9pbmcgc28uKTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtJIGhhdmUgYXNrZWQgb24tbGlzdCBm b3IgdGhlIGV4YWN0IHRleHQgYmVmb3JlIHJhaXNpbmcgbXkgaXNzdWVzLDxicj4NCnNpbmNlIG15 IGlzc3VlcyByZWxhdGUgdG8gdGhlIHRleHQsIG5vdCB0aGUgY2hvb3NpbmcgdG8gaGF2ZSB0d28g TVRJcy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFzIEkgcG9pbnRlZCBvdXQgaW4gbXkgb3JpZ2luYWwgbWVzc2FnZSwgdGhhdCB0 ZXh0IGlzIGluIEFkYW0ncyBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdhaW4sIGl0J3MgdG90YWxseSBwcm9jZWR1cmFsbHkgcmVn dWxhciB0byBoYXZlIHJvdWdoIGNvbnNlbnN1cyBvbiB0ZXh0IGluPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgV0cgbWVldGluZyBhbmQgb24g dGhlIGxpc3QgYW5kIHRoZW4gaGF2ZSB0aGUgZWRpdG9yIGVkaXQgaW4gc3Vic3RhbnRpdmVseTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIHNh bWUgdGV4dCB0byB0aGUgZHJhZnQuIElmIHlvdSB0aGluayB0aGVyZSBpcyBzb21lIHJlc3BlY3Qg aW4gd2hpY2ggdGhvc2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnR3byBibG9ja3Mgb2YgdGV4dCBhcmUgbm90IGluIGZhY3QgdGhlIHNhbWUsIHBs ZWFzZSBwb2ludCB0byBpdC4gT3RoZXJ3aXNlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhpcyBpcyBqdXN0IGRpbGF0b3J5LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsg QW5kIHRoaXMgbWVzc2FnZSBjbGVhcmx5IHBvaW50cyB0byB0aGUgc2xpZGVzIGFib3ZlLjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDtJIGRvbid0IGZpbmQgaXQgaGVscGZ1bCB0byBhdHRhY2sgdGhl IHBlb3BsZSB3aG8gcmFpc2UgaXNzdWVzLiBZTU1WLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO0J1 dCB3aGF0IEVLUiB0aGlua3MgcmVhbGx5IGRvZXNuJ3QgbWF0dGVyLiBIZSBpcyBub3QgYSBXR0Mu PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Jcm9uaWMgdGhhdCB5b3Ugd291bGQgY29tcGxhaW4gYWJvdXQgJnF1b3Q7YXR0YWNrJnF1 b3Q7cyBpbiBhIHRocmVhZCB3aGVyZSB5b3U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnN0YXJ0ZWQgb3V0IGJ5IGF0dGFja2luZyBBZGFtIFJvYWNo IGFuZCBoZXJlIHNheSAmcXVvdDt3aGF0IEVLUiB0aGlua3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlYWxseSBkb2Vzbid0IG1hdHRlciZxdW90 OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t RWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_92D0D52F3A63344CA478CF12DB0648AADF3634AAXMB111CNCrimnet_-- From nobody Tue Dec 16 11:32:15 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526A81A873A for ; Tue, 16 Dec 2014 11:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7oZwSViymg7 for ; Tue, 16 Dec 2014 11:32:01 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2760B1A872C for ; Tue, 16 Dec 2014 11:32:01 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id h11so13673080wiw.3 for ; Tue, 16 Dec 2014 11:32:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HMT5guDEUmYelcdruk0Id8qaSU1GuOqcU0FfiGtWuKk=; b=KNvHvYJYY+xDde/2guqWShnb+TLFv0VIt9lKeQuK6Wp4gl+4IkPwSImC8JqWbvsftE Y8bjlqq2E+2E3sXwMWxKsZ7YHlLX3jiB6Af3JUEa4CpTtkcyxMqS3tuGoSaElVq2q97p 4/LaLK+HKgVijMGrqFwdM8ZER3n3NpVvVt8MfuAVBw8aYBk7xiOIgkI+oYrmXnP//3nN GlwnHH9ZKWLQgfJeQr1KrM2zuBeFu54TObigm1yMBlqSBJnpjY5YHkkIG21XQqsEx1Qr ggn/WDcLwaIzalYuX1fCOtSqgkNNvW8OsY6PdISyN7AJMnY8flV/50TllG5dVlcZWS1H QyTQ== X-Gm-Message-State: ALoCoQmrK0/X5K9pr5inb9sI+gsB7f5VKiQ0yg3h/fbAxAAvIENqj1yTOfkCQAmiecOa9/T78kLT X-Received: by 10.180.84.98 with SMTP id x2mr7434037wiy.14.1418758319962; Tue, 16 Dec 2014 11:31:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Tue, 16 Dec 2014 11:31:19 -0800 (PST) In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF363463@XMB111CNC.rim.net> References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> <92D0D52F3A63344CA478CF12DB0648AADF363463@XMB111CNC.rim.net> From: Eric Rescorla Date: Tue, 16 Dec 2014 11:31:19 -0800 Message-ID: To: Gaelle Martin-Cocher Content-Type: multipart/alternative; boundary=f46d044401b2af15bc050a5a6991 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Hv-54arsZ9NsUCx-38itFYXtsg4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 19:32:06 -0000 --f46d044401b2af15bc050a5a6991 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 16, 2014 at 11:26 AM, Gaelle Martin-Cocher < gmartincocher@blackberry.com> wrote: > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Eric > Rescorla > *Sent:* Tuesday, December 16, 2014 11:53 AM > *To:* John Leslie > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] revisiting MTI > > > > > Sean is specifically saying the "trigger" should be discussed > on-list. > > > > I don't read this this way at all, Rather he's saying that in the future we > > can update the RFC. But yes, we can discuss the trigger on-list. Do you > > have some substantive objection that wasn't raised in HNL and/or > > hasn't been discussed to death here? > > > > I think what has not been discussed is a differentiated text for both > codecs. > > VP8 to be deprecated if failing to meet RF statements from proponents > > H264 to be deprecated when not used anymore by legacy services in > accordance with H264 proponents statements > > > I would not be in favor of either of these changes. -Ekr --f46d044401b2af15bc050a5a6991 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 16, 2014 at 11:26 AM, Gaelle Martin-Cocher <gma= rtincocher@blackberry.com> wrote:

=C2=A0

From: rtcweb [= mailto:rtcweb-= bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Tuesday, December 16, 2014 11:53 AM
To: John Leslie
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] revisiting MTI

=C2=A0


=C2=A0 =C2=A0Sean is specifically saying the "trigger" should be = discussed
on-list.

=C2=A0

I don't read this this way at all, Rather he'= ;s saying that in the future we

can update the RFC. But yes, we can discuss the trig= ger on-list. Do you

have some substantive objection that wasn't rais= ed in HNL and/or

hasn't been discussed to death here?

=C2=A0

=C2=A0I think what has= not been discussed is a differentiated text for both codecs.

VP8 to be deprecated if f= ailing to meet RF statements from proponents

H264 to be deprecated whe= n not used anymore by legacy services in accordance with H264 proponents st= atements



I would not be in favor of either of these changes= .

-Ekr
--f46d044401b2af15bc050a5a6991-- From nobody Tue Dec 16 11:32:44 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D529E1A8734 for ; Tue, 16 Dec 2014 11:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsAHLeaHj5sB for ; Tue, 16 Dec 2014 11:32:33 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E081A8713 for ; Tue, 16 Dec 2014 11:32:33 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id x12so18310406wgg.39 for ; Tue, 16 Dec 2014 11:32:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eZNF6oSurkWqRhUSjdk9jAF5x5qyN0nuCy4aIoKWJZY=; b=BeTYFFUyIreziBAko/QcOiaQbT7YOUBa/e//VO/yRqT7RuBKRp3RqrSWzmbd8f2WOO o/ZPM/cjqWS0cogm84YEW0kJ64cZkVPuPyJQnShES/Bmu4YQ41vliNQVsYmMxoR5Eake 0Ju99ljY8gcbV2P8Nw47HBS2QSv4+yt+WodE9JNzOcuQQC2S1DLHNw7dd8f1KZiACRJp 1KkkQOckhWNYOQeYLR6VzdRj1ot670Hs9sNaGZRgI9olrKgkUThOJNuyTSuBp5ToTWAv K4ANBLrFK1RUjEbJE6T+u4WZmQ2v1l7AOzD8+T02dOZOtI4DnB9edQP81GVOlrGIVOtk qikQ== X-Gm-Message-State: ALoCoQlsqEfv9JcDxb29idxRZ/DxCu0IK91APOexl1cnnV7YvXw52AuyEE1RrzpZDRuf96Oi2oU+ X-Received: by 10.180.91.136 with SMTP id ce8mr7570504wib.29.1418758352239; Tue, 16 Dec 2014 11:32:32 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com. [74.125.82.53]) by mx.google.com with ESMTPSA id ej10sm3290609wib.2.2014.12.16.11.32.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Dec 2014 11:32:31 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id l18so18016788wgh.26 for ; Tue, 16 Dec 2014 11:32:30 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.2.75 with SMTP id 11mr53762088wjs.78.1418758350725; Tue, 16 Dec 2014 11:32:30 -0800 (PST) Received: by 10.217.191.202 with HTTP; Tue, 16 Dec 2014 11:32:30 -0800 (PST) In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF363463@XMB111CNC.rim.net> References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> <92D0D52F3A63344CA478CF12DB0648AADF363463@XMB111CNC.rim.net> Date: Tue, 16 Dec 2014 14:32:30 -0500 Message-ID: From: Roman Shpount To: Gaelle Martin-Cocher Content-Type: multipart/alternative; boundary=047d7b3a834c846cbd050a5a6b5f Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/uad_gxCptAm9ORFTKI_EVtjPgqA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 19:32:40 -0000 --047d7b3a834c846cbd050a5a6b5f Content-Type: text/plain; charset=UTF-8 On Tue, Dec 16, 2014 at 2:26 PM, Gaelle Martin-Cocher < gmartincocher@blackberry.com> wrote: > > > > I think what has not been discussed is a differentiated text for both > codecs. > > VP8 to be deprecated if failing to meet RF statements from proponents > > H264 to be deprecated when not used anymore by legacy services in > accordance with H264 proponents statements > > > How about VP8 to be depreciated if it fails to pass the ISO or other standardization process or if licensing is confirmed in court to be a non royalty free. H264 to be depreciated if VP8 passes the standardization process and confirmed to be royalty free, unless H264 becomes royalty free as well? _____________ Roman Shpount --047d7b3a834c846cbd050a5a6b5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Dec 16, 2014 at 2:26 PM, Gaelle Martin-Cocher <gmartincoche= r@blackberry.com> wrote:

=C2=A0

=C2=A0I think w= hat has not been discussed is a differentiated text for both codecs.=

VP8 to be deprecated if failing to meet RF s= tatements from proponents

H264 to be deprecated when not used anymore = by legacy services in accordance with H264 proponents statements<= /u>


=C2=A0
How about=C2=A0
VP8 to be depreciated = if it fails to pass the ISO or other standardization process or if licensin= g is confirmed in court to be a non royalty free.
H264 to be depr= eciated if VP8 passes the standardization process and confirmed to be royal= ty free, unless H264 becomes royalty free as well?
_____________
Roman Shpount
=C2=A0
--047d7b3a834c846cbd050a5a6b5f-- From nobody Tue Dec 16 11:33:22 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8891A8732 for ; Tue, 16 Dec 2014 11:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eERgqKL343mN for ; Tue, 16 Dec 2014 11:33:14 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C72951A872F for ; Tue, 16 Dec 2014 11:33:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418758390; x=2282671990; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uXgwAkKhsQxr8Q2I0Ub4MCCEnHbpRnUCXK2exRhcP6w=; b=Af7nnCclQSYtTZv+SfZjiZjcQyIrbfbVSy/qk7g0ogpuCLBqgN51MUOVr8f/qjVf DOaQUZBJ182mOy85RP7wlZZMkSazwdLiw9DKkKKs1agjxYaQyN9W6NkVmlindcUg AmKwoMo+3EVQ7sGtcUv6/S+wSP6OMCG4GTWTpVhDkzmWV13BqMeOH3dv/iRmJ0HD hv8cEGwT2tpYVCFlSqUGhWa+xuVUgh/dyaFqBy2BRfr3m016GOcotXluhkDqYjgH qO9JwqS01e+jqXiAbR4siPW6q52a3N+AzKsRhOVkJLbA2W1rkj3uYDFvD2zMtU6p XDpDjip5Up6JlKGQubHsJw==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 6F.44.07917.6F880945; Tue, 16 Dec 2014 11:33:10 -0800 (PST) X-AuditID: 11973e13-f794a6d000001eed-ce-549088f6706b Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 34.AC.06123.8F880945; Tue, 16 Dec 2014 11:33:12 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGO00JZGWZ98000@marigold.apple.com> for rtcweb@ietf.org; Tue, 16 Dec 2014 11:33:09 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <54905132.40105@alvestrand.no> Date: Tue, 16 Dec 2014 11:33:09 -0800 Content-transfer-encoding: quoted-printable Message-id: <5B1166AB-A2EA-4F83-ABB2-8947D044B159@apple.com> References: <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <54905132.40105@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FAYofutY0KIwcPFvBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4+eHTuaCZv6KpVt7mRoYu3m6GDk5JARMJP62rWGFsMUkLtxb z9bFyMUhJLCXUeL2kgOMMEVPli5lhEhMYpI4fuoSlDOfSeLd7SNMXYwcHMwC6hJTpuSCNPAK 6Ek0PXnMBGILC6hI7N99gh3EZhNQlXgw5xjYUE4BbYnlu06C1bAAxQ+d/gtWwywgLPH98T0W CFtb4sm7C6wQM20kpjz/ygSx9yqzxNcJs9hAEiICOhIP9zcwQVwqK/Hv4hl2kCIJgY+sEpdX bmCcwCg8C+G+WUjum4VkxwJG5lWMQrmJmTm6mXmmeokFBTmpesn5uZsYQYE83U54B+PpVVaH GAU4GJV4eH/k9YcIsSaWFVfmHmKU5mBREud9rwsUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wFiYekvzbeC+x2wxp7YZ8XNr7H24W0eoObfg15tfgjyaxydFMWcxR2aw1wpM2HPpzpaTGyJS zt1baXCmaPWu+WuM7HV2cksFKcpI5k9QEpqhduPDuUvS/QvXHJGcbMI9sbHEXHFe+ErXOoun 01qem07zZvwhfTIlbP7dE9eNW/hee6uszJ7G9UmJpTgj0VCLuag4EQDOtG4VRQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcovujY0KIwaKrnBZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4+eHTuaCZv6KpVt7mRoYu3m6GDk5JARMJJ4sXcoIYYtJXLi3 nq2LkYtDSGASk8TxU5cYIZz5TBLvbh9h6mLk4GAWUJeYMiUXpIFXQE+i6cljJhBbWEBFYv/u E+wgNpuAqsSDOcfAhnIKaEss33USrIYFKH7o9F+wGmYBYYnvj++xQNjaEk/eXWCFmGkjMeX5 VyaIvVeZJb5OmMUGkhAR0JF4uL+BCeJSWYl/F8+wT2AUmIVw0iwkJ81CMnYBI/MqRoGi1JzE SlO9xIKCnFS95PzcTYzgwCuM2MH4f5nVIUYBDkYlHt6Awv4QIdbEsuLK3EOMEhzMSiK8zI0T QoR4UxIrq1KL8uOLSnNSiw8xSnOwKInzlrxrDBESSE8sSc1OTS1ILYLJMnFwSjUwJjYIHOpO /byAm0Or7Msh4YCjTxlLnBPXdGjXi8+aUjvvQMbEBSLKRR++HbOX2Nxs+uC5+qpP/1cuP7LO nvvsjLX7zRZfK/vdufKCVEBR2/Jd/5dWZW2oe370Iveq9Wd51H+/vfnqUwtf8Ybmp4HBdg+k 3f5qaCtlWjBPelotYJ4TWrv45KtjmUosxRmJhlrMRcWJANNmBpY4AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/L32HnrGoqxz5I1_fthzkAIaRRRU Cc: rtcweb@ietf.org Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 19:33:18 -0000 > On Dec 16, 2014, at 7:35 , Harald Alvestrand = wrote: >=20 > On 12/16/2014 04:21 PM, John Leslie wrote: >> Eric Rescorla wrote: >>> On Tue, Dec 16, 2014 at 7:03 AM, John Leslie wrote: >>>=20 >>>> I cry "TILT"! Let's have the WGC calling consensus publish the >>>> text we're being asked to consent to. >>> Huh? The relevant text is here: >>>=20 >>> https://tools.ietf.org/html/draft-ietf-rtcweb-video-03#section-5 >> Perhaps it is; perhaps not: we'd have to listen to the audio to be >> sure. Even after hearing the audio once, I'm not quite sure... >=20 > If the chairs say that the text in video-03 section 5 is the text they = think they're calling consensus on, I'm happy to have consensus called = on that. >=20 > It's close enough to what I believe we agreed on in Honolulu that I'm = willing to consider the changes from what I remember editorial (the = biggest difference I see offhand is the indentation of the = future-pointing section, but there might have been grammar changes too.) >=20 > I agree that having the consensus-calling chair state that this text = is what he's calling consensus on would be beneficial. Unless I am being blind or lacking sufficient coffee, there is a = problem: "For the definitions of "WebRTC Brower," "WebRTC Non-Browser", and "WebRTC-Compatible Endpoint" as they are used in this section, please refer to [ I-D.ietf-rtcweb-overview ]." Except I can=E2=80=99t find the text =E2=80=9Cnon-browser=E2=80=9D in = the referenced document. (And I don=E2=80=99t formally know what a = Brower is either :-( [typo]). If it means WebRTC Device, then this sentence comes into play "All WebRTC browsers (UAs) are WebRTC devices, so any requirement on a WebRTC device also applies to a WebRTC browser.=E2=80=9D ? David Singer Manager, Software Standards, Apple Inc. From nobody Tue Dec 16 11:34:36 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5076A1A8736 for ; Tue, 16 Dec 2014 11:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSYOWQaUeF70 for ; Tue, 16 Dec 2014 11:34:32 -0800 (PST) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [67.18.44.28]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653FC1A8734 for ; Tue, 16 Dec 2014 11:34:32 -0800 (PST) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id D2A2A3850B904; Tue, 16 Dec 2014 13:34:31 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway16.websitewelcome.com (Postfix) with ESMTP id AF6053850B821 for ; Tue, 16 Dec 2014 13:34:31 -0600 (CST) Received: from [96.231.218.201] (port=56915 helo=[192.168.1.7]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Y0xt8-00059M-To; Tue, 16 Dec 2014 13:34:31 -0600 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <20141216162534.GV47023@verdi> Date: Tue, 16 Dec 2014 14:34:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4D2D9D07-D086-40F8-8B3E-3D348ACB179C@ieca.com> References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> To: John Leslie X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.218.201 X-Exim-ID: 1Y0xt8-00059M-To X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.7]) [96.231.218.201]:56915 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fhxlvzuO6DC4OL4pT54DUDjcIqA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 19:34:34 -0000 John, This is normal IETF process. We had a session in Hawaii, we had a consensus call, and now I'm confirming it on the list as well as asking for any unaddressed issues to be raised. The text on which I am are calling for consensus is the compromise text that was discussed appears in slides 12-14 at [4] (which is a slight editorial variation of the text proposed at [2]). Specifically: 1. WebRTC User Agents (Browsers) MUST implement both VP8 and H.264. 2. WebRTC devices (Non-Browsers) MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. The definitions of these terms are found on slide 12. Note that there was a 3rd bullet but as noted in [2] and on slide 14 of [4], it=92s really a throw away statement because it=92s more of an observation that WebRTC-compatible endpoints are free to whatever they want. My original message also included a summary of the major issues that were raised at the meeting. Obviously, the numbered points are summaries but I do consider those to be an unbiased summary of the conversation that took place at the mic. As chair, I'm asking that we not continue to rehash discussion on those points because both sides of each numbered point were clearly articulated. In other words, we need not bike shed on one those topics any longer unless something new is raised. spt On Dec 16, 2014, at 11:25, John Leslie wrote: > Eric Rescorla wrote: >> On Tue, Dec 16, 2014 at 7:21 AM, John Leslie wrote: >>=20 >>> Perhaps it is; perhaps not: we'd have to listen to the audio to be >>> sure. Even after hearing the audio once, I'm not quite sure... >>=20 >> Again, huh? >=20 > No, "still". >=20 >> The version that was discussed in Honolulu is on the slides here: >>=20 >> http://www.ietf.org/proceedings/91/slides/slides-91-rtcweb-7.pdf >>=20 >> on page 14. The text isn't exactly the same but it's substantively >> the same as what's in the draft. >=20 > You prove my point... >=20 >> Needless to say, having WG consensus on the substance and letting the >> editor wordsmith the text is totally normal IETF process. >=20 > In some cases, yes. IMHO, this is not one of them. YMMV... >=20 >> I haven't heard anyone who was at HNL and in favor of the text on the >> slides object that Adam's text in the draft doesn't reflect those >> slides. >=20 > Probably you haven't... >=20 >> Besides, Eric isn't the WGC calling consensus. >>=20 >> No, the chairs did here: >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html > ]=20 > ] From: Sean Turner > ] At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion > ] about codecs, which I dubbed "the great codec compromise." > ] The compromise text that was discussed appears in slides 12-14 at = [4] > ] (which is a slight editorial variation of the text proposed at [2]). > ]=20 > ] This message serves to confirm the sense of the room. >=20 > Actually, as I read this more carefully, that isn't a consensus = call. > Sean goes on to dismiss the objections he heard in the room: > ]=20 > ] In the room, I heard the following objections and responses (and I'm > ] paraphrasing here), which I'll take the liberty of categorizing as > ] IPR, Time, and Trigger: > ]=20 > ] 1) IPR: > ] Objections: There are still IPR concerns which may restrict what a > ] particular organization feels comfortable with including in their > ] browser implementations. > ] Response: IPR concerns on this topic are well known. There is even = a > ] draft summarizing the current IPR status for VP8: > ] draft-benham-rtcweb-vp8litigation. The sense of the room was still > ] that adopting the compromise text was appropriate. >=20 > Sean is stating his view of consensus-of-the-room. >=20 > ] 2) Time: > ] 2.1) Time to consider decision: > ] Objection: The decision to consider the compromise proposal at this > ] meeting was provided on short notice and did not provide some the > ] opportunity to attend in person. > ] Response: Six months ago the chairs made it clear discussion would = be > ] revisited @ IETF 91. The first agenda proposal for the WG included = this > ] topic, and the topic was never removed by the chairs. More = importantly, > ] all decisions are confirmed on list; in person attendance is not > ] required to be part of the process. >=20 > Sean is defending the action of the WGCs. >=20 > ] 2.2) Time to consider text: > ] Objection: The proposed text [2] is too new to be considered. > ] Response: The requirement for browsers to support both VP8 and H.264 > ] was among the options in the straw poll conducted more than six = months > ] ago. All decisions are confirmed on list so there will be ample time > ] to discuss the proposal. >=20 > Sean is specifically saying the text should be discussed on-list. >=20 > ] 3) Trigger: > ] Objection: The "trigger" sentence [3] is all kinds of wrong because > ] it's promising that the future IETF will update this specification. > ] Response: Like any IETF proposal, an RFC that documents the current > ] proposal can be changed through the consensus process at any other = time. >=20 > Sean is specifically saying the "trigger" should be discussed > on-list. >=20 > ] After the discussion, some clarifying questions about the hums, and > ] typing the hum questions on the screen, there was rough consensus in > ] the room to add (aka "shove") the proposed text into > ] draft-ietf-rtcweb-video. In keeping with IETF process, I am = confirming > ] this consensus call on the list. >=20 > This _is_ calling for consensus. >=20 > But Sean omitted saying _what_ text; and agreed that the exact text > may not have been clear to those in the room. >=20 > ] If anyone has any other issues that they would like to raise please = do > ] by December 19th. >=20 > (And folks have been doing so.) >=20 > I have asked on-list for the exact text before raising my issues, > since my issues relate to the text, not the choosing to have two MTIs. >=20 >> And this message clearly points to the slides above. >=20 > I don't find it helpful to attack the people who raise issues. YMMV. >=20 > But what EKR thinks really doesn't matter. He is not a WGC. >=20 > -- > John Leslie >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Dec 16 11:35:39 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D3B1A8743 for ; Tue, 16 Dec 2014 11:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ukjoy1Hajgsa for ; Tue, 16 Dec 2014 11:35:36 -0800 (PST) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12C0E1A8736 for ; Tue, 16 Dec 2014 11:35:36 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id r5so10861348qcx.16 for ; Tue, 16 Dec 2014 11:35:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K54t83DBkObMVovuPjcoRfx++h8V6oNryA6cQjdhHHs=; b=NY5QFrQY2zatRjnmpS6iMKUYzPFSKiTj6qeBKVefu1sjns+slhpCPvfSIRwyMfGwd4 FSo3AojLpwTeaJxLkphpt8gXmgIdZzLXre6TNYrhtnfCt2Ns9lqtH9gcQTXoA7qW+h5D U3tuoHKyxrJw4AzK4uXqx/qmc01C/f01BogdPMk4hzdPqTaa5jg7Xc8kpWUUsnp41r4B n3+0inpVQDvvg9p+Ivl0d6Wj63G8MU9E3+3CekaBbWUZRCcqsaYd+OQ4KOBLYdZInRVx 28nOFsgHXOavL+11S4L73JzPuaV47CsANdd4zneY97wQDTqUfQYZIQ9bH3WrnbcWWrkK mYZQ== X-Gm-Message-State: ALoCoQnphf6FLyZShXurx0jwFKOsYUfwzBAStnNacfd+HJlYhE3Az3Vqd3KQ7cJV405HR4rYDyAE MIME-Version: 1.0 X-Received: by 10.140.97.35 with SMTP id l32mr17290164qge.11.1418758528385; Tue, 16 Dec 2014 11:35:28 -0800 (PST) Received: by 10.96.26.135 with HTTP; Tue, 16 Dec 2014 11:35:28 -0800 (PST) Received: by 10.96.26.135 with HTTP; Tue, 16 Dec 2014 11:35:28 -0800 (PST) In-Reply-To: References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> <92D0D52F3A63344CA478CF12DB0648AADF363463@XMB111CNC.rim.net> Date: Tue, 16 Dec 2014 20:35:28 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Roman Shpount Content-Type: multipart/alternative; boundary=001a113a9c281b5cab050a5a76a0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nvcZPYoqhNkUfRmpTf1jR7Oawnk Cc: rtcweb@ietf.org Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 19:35:37 -0000 --001a113a9c281b5cab050a5a76a0 Content-Type: text/plain; charset=UTF-8 +1 On 16 Dec 2014 20:32, "Roman Shpount" wrote: > On Tue, Dec 16, 2014 at 2:26 PM, Gaelle Martin-Cocher < > gmartincocher@blackberry.com> wrote: >> >> >> >> I think what has not been discussed is a differentiated text for both >> codecs. >> >> VP8 to be deprecated if failing to meet RF statements from proponents >> >> H264 to be deprecated when not used anymore by legacy services in >> accordance with H264 proponents statements >> >> >> > How about > VP8 to be depreciated if it fails to pass the ISO or other standardization > process or if licensing is confirmed in court to be a non royalty free. > H264 to be depreciated if VP8 passes the standardization process and > confirmed to be royalty free, unless H264 becomes royalty free as well? > _____________ > Roman Shpount > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a113a9c281b5cab050a5a76a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+1

On 16 Dec 2014 20:32, "Roman Shpount" = <roman@telurix.com> wrote:
On Tue, Dec 16, 2014 at 2= :26 PM, Gaelle Martin-Cocher <gmartincocher@blackberry.com&= gt; wrote:

=C2=A0

=C2=A0I think w= hat has not been discussed is a differentiated text for both codecs.=

VP8 to be deprecated if failing to meet RF s= tatements from proponents

H264 to be deprecated when not used anymore = by legacy services in accordance with H264 proponents statements<= /u>


=C2=A0
How about=C2=A0
VP8 to be depreciated = if it fails to pass the ISO or other standardization process or if licensin= g is confirmed in court to be a non royalty free.
H264 to be depr= eciated if VP8 passes the standardization process and confirmed to be royal= ty free, unless H264 becomes royalty free as well?
_________= ____
Roman Shpount
=C2=A0

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--001a113a9c281b5cab050a5a76a0-- From nobody Tue Dec 16 11:38:49 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2FA1A1BD2 for ; Tue, 16 Dec 2014 11:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsgxmEf4bgdu for ; Tue, 16 Dec 2014 11:38:43 -0800 (PST) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93CD91A8737 for ; Tue, 16 Dec 2014 11:38:42 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so18152214wgh.6 for ; Tue, 16 Dec 2014 11:38:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rJNPnXU9Em4FGB2ISQAm38TFTBOmypyKosjTnzOxZIc=; b=JLLPPPDqNVwFfhUvJQV5Dmk56i9x5E3nkeVWeuFL+Ph3hwJ961zVr16dUhpK4wXMlX uKbA2FV9S5AnVYJ/S6zaJyhYbfcht6rMUbJ4lthQADlyiwnuLerUmWKNBw8aIPWuod+U Tro/UUzws/tqVMEMjaRrSslJE9ppZaK1bky2mbr0QJBJvzmEXqy4h9oRWJo3ktQ/CfRC FWK7M+ZtFujrREDCl3LeV3BlPfWvz5sEXUrTvUWNKPR3kCSXZSyhWf0GaqseXRGPJ2sK g1ytOQAEvYIhVfu80SfD2KbJn1PTkOtO325uThmQIPZU7vG+KxASF0fH+v2q0sQYXGnH 0zLg== X-Gm-Message-State: ALoCoQlZZ4Ai/gVQGkc17FO+rDdCw8+16/R6mErWJuE1BKMvB0zizX66lsz4tJExd9xkCIgQhqIe X-Received: by 10.180.198.164 with SMTP id jd4mr7475152wic.42.1418758721302; Tue, 16 Dec 2014 11:38:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Tue, 16 Dec 2014 11:38:01 -0800 (PST) In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF3634AA@XMB111CNC.rim.net> References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> <92D0D52F3A63344CA478CF12DB0648AADF3634AA@XMB111CNC.rim.net> From: Eric Rescorla Date: Tue, 16 Dec 2014 11:38:01 -0800 Message-ID: To: Gaelle Martin-Cocher Content-Type: multipart/alternative; boundary=047d7b6047069b0c5d050a5a8170 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5zk1oow7KnqwfhE5LjQg5hwze4A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 19:38:46 -0000 --047d7b6047069b0c5d050a5a8170 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 16, 2014 at 11:31 AM, Gaelle Martin-Cocher < gmartincocher@blackberry.com> wrote: > > I have little confidence that the choice between H265 and VP9 will be > easier than it is today between VP8 and H264. > > Are we going to multiply similarly performing codecs going forward (in > the spec or in practice) or be stuck with mandatory low performing codecs > because we cannot make better decision? > It's important to remember that the requirement for an MTI codec is to guarantee basic interoperability. I would not imagine that we would define a new required codec unless it was not just technically superior but also definitively RF in the sense contemplated by Adam's text. -Ekr > Time frame for H265 / VP9 is up to two years from now > > And possibly the timeframe for H.266/Dalaa is four years from now > > > > This is one more drawback of the proposed text for MTI, not only it > multiplies encoders and decoders to be supported but can prevent the > evolution of webrtc toward more advances codecs. (assuming we will not > require 4 or 6 encoders and 4 or 6 decoders to be supported by every sing= le > endpoints. Two MTI seems largely enough, no?). > > > > Ga=C3=ABlle > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Eric > Rescorla > *Sent:* Tuesday, December 16, 2014 11:53 AM > *To:* John Leslie > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] revisiting MTI > > > > On Tue, Dec 16, 2014 at 8:25 AM, John Leslie wrote: > > Eric Rescorla wrote: > > On Tue, Dec 16, 2014 at 7:21 AM, John Leslie wrote: > > > Needless to say, having WG consensus on the substance and letting the > > editor wordsmith the text is totally normal IETF process. > > In some cases, yes. IMHO, this is not one of them. YMMV... > > > > Indeed it does, since I have *never* heard of such a case where > > the editor had no discretion to change the text in purely editorial > > ways (subject to WG consensus of course). Feel free to cite one > > if you have one. > > > > > > > I haven't heard anyone who was at HNL and in favor of the text on the > > slides object that Adam's text in the draft doesn't reflect those > > slides. > > Probably you haven't... > > > > To the best of my knowledge it hasn't happened. Can you cite anyone > > who has so objected. > > > > > > > > Besides, Eric isn't the WGC calling consensus. > > > > No, the chairs did here: > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html > ] > ] From: Sean Turner > ] At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion > ] about codecs, which I dubbed "the great codec compromise." > ] The compromise text that was discussed appears in slides 12-14 at [4] > ] (which is a slight editorial variation of the text proposed at [2]). > ] > ] This message serves to confirm the sense of the room. > > Actually, as I read this more carefully, that isn't a consensus call. > Sean goes on to dismiss the objections he heard in the room: > > > > He's addressing them. What exactly is the problem with this? > > > > > ] 3) Trigger: > ] Objection: The "trigger" sentence [3] is all kinds of wrong because > ] it's promising that the future IETF will update this specification. > ] Response: Like any IETF proposal, an RFC that documents the current > ] proposal can be changed through the consensus process at any other time= . > > Sean is specifically saying the "trigger" should be discussed > on-list. > > > > I don't read this this way at all, Rather he's saying that in the future = we > > can update the RFC. But yes, we can discuss the trigger on-list. Do you > > have some substantive objection that wasn't raised in HNL and/or > > hasn't been discussed to death here? > > > > > > ] After the discussion, some clarifying questions about the hums, and > ] typing the hum questions on the screen, there was rough consensus in > ] the room to add (aka "shove") the proposed text into > ] draft-ietf-rtcweb-video. In keeping with IETF process, I am confirming > ] this consensus call on the list. > > This _is_ calling for consensus. > > But Sean omitted saying _what_ text; and agreed that the exact text > may not have been clear to those in the room. > > > > Huh? The "proposed text" that was discussed in HNL is on the slide and > > that's what's being referred to here. Adam edited text which is > substantially > > the same into the draft. > > > > > > > > ] If anyone has any other issues that they would like to raise please do > ] by December 19th. > > (And folks have been doing so.) > > I have asked on-list for the exact text before raising my issues, > since my issues relate to the text, not the choosing to have two MTIs. > > > > As I pointed out in my original message, that text is in Adam's draft. > > > > Again, it's totally procedurally regular to have rough consensus on text = in > > the WG meeting and on the list and then have the editor edit in > substantively > > the same text to the draft. If you think there is some respect in which > those > > two blocks of text are not in fact the same, please point to it. Otherwis= e, > > this is just dilatory. > > > > > > > And this message clearly points to the slides above. > > I don't find it helpful to attack the people who raise issues. YMMV. > > > > But what EKR thinks really doesn't matter. He is not a WGC. > > > > Ironic that you would complain about "attack"s in a thread where you > > started out by attacking Adam Roach and here say "what EKR thinks > > really doesn't matter" > > > > -Ekr > --047d7b6047069b0c5d050a5a8170 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 16, 2014 at 11:31 AM, Gaelle Martin-Cocher <gma= rtincocher@blackberry.com> wrote:

I have little confidence = that the choice between H265 and VP9 will be easier than it is today betwee= n VP8 and H264.

Are we going to multiply = similarly performing codecs =C2=A0going forward (in the spec or in practice= ) or be stuck with mandatory low performing codecs because we cannot make better decision?


<= /div>
It's important to remember that the requirement for an MTI co= dec
is to guarantee basic interoperability. I would not imagine t= hat we
would define a new required codec unless it was not just t= echnically
superior but also definitively RF in the sense contemp= lated by Adam's
text.

-Ekr


=C2=A0
<= div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">

Time frame for H265 / VP9= =C2=A0is up to two years from now

And possibly the timefram= e for H.266/Dalaa is four years from now

=C2=A0

This is one more drawback= of the proposed text for MTI, not only it multiplies encoders and decoders= to be supported but =C2=A0can prevent the evolution of webrtc toward more advances codecs. (assuming we will not require 4 or 6 encoders= and 4 or 6 decoders to be supported by every single endpoints. Two MTI see= ms largely enough, no?).

=C2=A0

Ga=C3=ABlle=

=C2=A0

From: rtcweb [= mailto:rtcweb-= bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Tuesday, December 16, 2014 11:53 AM
To: John Leslie
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] revisiting MTI

=C2=A0

On Tue, Dec 16, 2014 at 8:25 AM, John Leslie <john@jlc.net> wrote:<= u>

Eric Rescorla <ekr@rtfm.com> wrote:
> On Tue, Dec 16, 2014 at 7:21 AM, John Leslie <john@jlc.net> wrote:

> Needless to say, having WG consensus on the sub= stance and letting the
> editor wordsmith the text is totally normal IETF process.

=C2=A0 =C2=A0In some cases, yes. IMHO, this is not one of them. YMMV...<= /u>

=C2=A0

Indeed it does, since I have *never* heard of such a= case where

the editor had no discretion to change the text in p= urely editorial

ways (subject to WG consensus of course). Feel free = to cite one

if you have one.

=C2=A0

=C2=A0

> I haven't heard anyone who was at HNL and i= n favor of the text on the
> slides object that Adam's text in the draft doesn't reflect th= ose
> slides.

=C2=A0 =C2=A0Probably you haven't...

=C2=A0

To the best of my knowledge it hasn't happened. = Can you cite anyone

who has so objected.

=C2=A0

=C2=A0


> Besides, Eric isn't the WGC calling consensus.
>
> No, the chairs did here:
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html
]
] From: Sean Turner <turners at ieca.com>
] At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion
] about codecs, which I dubbed "the great codec compromise."
] The compromise text that was discussed appears in slides 12-14 at [4]
] (which is a slight editorial variation of the text proposed at [2]).
]
] This message serves to confirm the sense of the room.

=C2=A0 =C2=A0Actually, as I read this more carefully, that isn't a cons= ensus call.
Sean goes on to dismiss the objections he heard in the room:<= /p>

=C2=A0

He's addressing them. What exactly is the proble= m with this?

=C2=A0


] 3) Trigger:
] Objection: The "trigger" sentence [3] is all kinds of wrong bec= ause
] it's promising that the future IETF will update this specification. ] Response: Like any IETF proposal, an RFC that documents the current
] proposal can be changed through the consensus process at any other time.<= br>
=C2=A0 =C2=A0Sean is specifically saying the "trigger" should be = discussed
on-list.

=C2=A0

I don't read this this way at all, Rather he'= ;s saying that in the future we

can update the RFC. But yes, we can discuss the trig= ger on-list. Do you

have some substantive objection that wasn't rais= ed in HNL and/or

hasn't been discussed to death here?

=C2=A0

=C2=A0

] After the discussion, some clarifying questions ab= out the hums, and
] typing the hum questions on the screen, there was rough consensus in
] the room to add (aka "shove") the proposed text into
] draft-ietf-rtcweb-video. In keeping with IETF process, I am confirming ] this consensus call on the list.

=C2=A0 =C2=A0This _is_ calling for consensus.

=C2=A0 =C2=A0But Sean omitted saying _what_ text; and agreed that the exact= text
may not have been clear to those in the room.

=C2=A0

Huh? The "proposed text" that was discusse= d in HNL is on the slide and

that's what's being referred to here. Adam e= dited text which is substantially

the same into the draft.

=C2=A0

=C2=A0

=C2=A0

] If anyone has any other issues that they would lik= e to raise please do
] by December 19th.

=C2=A0 =C2=A0(And folks have been doing so.)

=C2=A0 =C2=A0I have asked on-list for the exact text before raising my issu= es,
since my issues relate to the text, not the choosing to have two MTIs.

=C2=A0

As I pointed out in my original message, that text i= s in Adam's draft.

=C2=A0

Again, it's totally procedurally regular to have= rough consensus on text in

the WG meeting and on the list and then have the edi= tor edit in substantively

the same text to the draft. If you think there is so= me respect in which those

two blocks of text are not in fact the same, please = point to it. Otherwise,

this is just dilatory.

=C2=A0

=C2=A0

> And this message clearly points to the slides a= bove.

=C2=A0 =C2=A0I don't find it helpful to attack the people who raise iss= ues. YMMV.

=C2=A0

=C2=A0 =C2=A0But what EKR thinks really doesn't = matter. He is not a WGC.

=C2=A0

Ironic that you would complain about "attack&qu= ot;s in a thread where you

started out by attacking Adam Roach and here say &qu= ot;what EKR thinks

really doesn't matter"

=C2=A0

-Ekr

--047d7b6047069b0c5d050a5a8170-- From nobody Tue Dec 16 11:39:28 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3CA1A873E for ; Tue, 16 Dec 2014 11:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRe_0zF-PFeF for ; Tue, 16 Dec 2014 11:39:22 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6191A8737 for ; Tue, 16 Dec 2014 11:39:21 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex7so13375974wid.9 for ; Tue, 16 Dec 2014 11:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Ml3aqIjs8YpBxdjhb/ZthqC/D4Kq70xolynRisbKumg=; b=MB+FvxNVtsE0zPBViGaC4lkhisV0kIn+kgVw1GJq4DshCvRYFRdYjrmdtq0cNaWzHA KIkTYDHfCtbRzKD6e7XTOvNuuEh1koLwErg6dUxATfTNEClUCiFsrLwa3Iax2LOO7Dm9 ewQWkkkgLymnD8xwAynKBwh/lb6ePyOi+syweitbTgBvJa+lfqLrfqDXYp5T4sgG6x9A /UKw0GUF4JiJZrVmM+mk8PJaq89SwLk9TTHlqd1UxHJjHp/aIcZXiAd8XZGRxj8KsPmw CZ2Y9PvUnU5VMQImqFmUkFmGqXYcxRGzAMuSxReG1jNM9UNUzz7gxKke5TVRkeSpZgiB zU/A== X-Received: by 10.180.97.7 with SMTP id dw7mr4191772wib.6.1418758760637; Tue, 16 Dec 2014 11:39:20 -0800 (PST) Received: from Saturns-MBP.fritz.box ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id n5sm3304415wic.6.2014.12.16.11.39.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Dec 2014 11:39:19 -0800 (PST) Message-ID: <54908A65.1010705@gmail.com> Date: Tue, 16 Dec 2014 20:39:17 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MrgZ_kzU3nIXovpfOioVBOd0ZUg Subject: [rtcweb] clarifications on current discussions - re: confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.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, 16 Dec 2014 19:39:23 -0000 With many forks of the thread and various opinions, can anyone clarify the expectation of these discussions. Ideally will be the WG chairs stating what is the role of the current discussions, specially to the initial thread with the subject 'confirming sense of the room: mti codec' started by Sean Turner - link to archive: - http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html My understanding was that it is about clarifying what happened during the sessions in Honolulu, not a call on consensus for the proposal. I get the feeling that many understood it differently, being the call on consensus for video MTI codecs. I saw many people simply stating there position in replies to this thread, which is ok if they want to say/reiterate it, but not addressing any of the points set for discussion by Sean. For a call on consensus I would expect to be with a explicit subject, including or pointing to the (draft of) text to be adopted. Which side got it wrong here? Thanks, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda From nobody Tue Dec 16 11:42:14 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181191A8752 for ; Tue, 16 Dec 2014 11:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCrTLHege9fE for ; Tue, 16 Dec 2014 11:42:10 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA951A8751 for ; Tue, 16 Dec 2014 11:42:10 -0800 (PST) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 16 Dec 2014 14:42:10 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT105CNC.rim.net ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.03.0210.002; Tue, 16 Dec 2014 14:42:09 -0500 From: Gaelle Martin-Cocher To: Adam Roach , Peter Saint-Andre - &yet , Ted Hardie Thread-Topic: [rtcweb] revisiting MTI Thread-Index: AQHQGK9hz+EPVQM3202R+pzBLk6Ke5yRiFAAgAAEJwCAAAEZAIAAAMsAgAAFmwCAAQrfwA== Date: Tue, 16 Dec 2014 19:42:09 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF363518@XMB111CNC.rim.net> References: <548AFB1A.1040405@andyet.net> <548AFF76.1010003@nostrum.com> <548B047F.9090704@nostrum.com> <56448CBD-FB31-4468-B449-497652FCAAEB@apple.com> <548B7EFF.5080105@andyet.net> <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> In-Reply-To: <548F646C.1050406@nostrum.com> Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vUVGCAv-T-iO1HBGTgyzZU12Wak Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 19:42:12 -0000 -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Adam Roach Sent: Monday, December 15, 2014 5:45 PM To: Peter Saint-Andre - &yet; Ted Hardie Cc: rtcweb@ietf.org Subject: Re: [rtcweb] revisiting MTI ____ [1] To put a finer point on the necessity I mention here: in the straw poll= last year, this option *without* the forward-looking provision received a = mere 9% of participants supporting it, with 53% actively opposing it. The f= orward-looking provision is basically the "special sauce" that makes this a= pproach palatable for some significant number of WG participants. Since last year the situation has changed drastically with regards to codec= access. I don't believe pointing at previous results make any sense and we= could be very surprised if we were to ask again the same questions. Ga=EBlle From nobody Tue Dec 16 11:56:17 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCB21A873E for ; Tue, 16 Dec 2014 11:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuU6UHNIlgE6 for ; Tue, 16 Dec 2014 11:56:13 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 15A5B1A8751 for ; Tue, 16 Dec 2014 11:56:06 -0800 (PST) Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 16 Dec 2014 14:56:06 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.03.0210.002; Tue, 16 Dec 2014 14:56:06 -0500 From: Gaelle Martin-Cocher To: Eric Rescorla Thread-Topic: [rtcweb] revisiting MTI Thread-Index: AQHQGK9hz+EPVQM3202R+pzBLk6Ke5yRiFAAgAAEJwCAAAEZAIAAAMsAgAAFmwCAARFEgIAAAWIAgAADogCAAAQ5gIAADdEAgAAHm4D//9Il8IAAXAWA//+ur/A= Date: Tue, 16 Dec 2014 19:56:05 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF363549@XMB111CNC.rim.net> References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> <92D0D52F3A63344CA478CF12DB0648AADF3634AA@XMB111CNC.rim.net> In-Reply-To: Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: multipart/alternative; boundary="_000_92D0D52F3A63344CA478CF12DB0648AADF363549XMB111CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/06FI_4gLNjkgGqAZs3t7Qy8iUe4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 19:56:16 -0000 --_000_92D0D52F3A63344CA478CF12DB0648AADF363549XMB111CNCrimnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3Qgc3VyZSBvbiB3aGF0IHlvdSBhcmUgYmFzaW5nIHlvdXIgb3Bpbmlvbi4NCldhaXRp bmcgZm9yIGFuIFJGIHRlY2huaWNhbGx5IHN1cGVyaW9yIGNvZGVjIG1pZ2h0IG5vdCBiZSBwcmFn bWF0aWMgYW5kIGNhbiBpbmRlZWQgcHJldmVudCBhbnkgZXZvbHV0aW9uIG9mIFdlYlJUQyBjb2Rl YyBmb3IgYSBsb25nIHRpbWUuDQpEZXByZWNhdGluZyBNVEkgY2FuIGJlIGRvbmUgaW4gc3RlcHMg KGUuZy4gYmVjb21lIFNIT1VMRCwgdGhlbiBNQVkpDQoNCklmIHRoaXMgTVRJIHRleHQgcHJldmVu dHMgY29kZWMgZXZvbHV0aW9uLCB0aGlzIGlzIGEgc2VyaW91cyBpc3N1ZS4NCkdhw6tsbGUNCg0K DQpGcm9tOiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXQ0KU2VudDogVHVlc2Rh eSwgRGVjZW1iZXIgMTYsIDIwMTQgMjozOCBQTQ0KVG86IEdhZWxsZSBNYXJ0aW4tQ29jaGVyDQpD YzogSm9obiBMZXNsaWU7IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIHJl dmlzaXRpbmcgTVRJDQoNCg0KDQpPbiBUdWUsIERlYyAxNiwgMjAxNCBhdCAxMTozMSBBTSwgR2Fl bGxlIE1hcnRpbi1Db2NoZXIgPGdtYXJ0aW5jb2NoZXJAYmxhY2tiZXJyeS5jb208bWFpbHRvOmdt YXJ0aW5jb2NoZXJAYmxhY2tiZXJyeS5jb20+PiB3cm90ZToNCkkgaGF2ZSBsaXR0bGUgY29uZmlk ZW5jZSB0aGF0IHRoZSBjaG9pY2UgYmV0d2VlbiBIMjY1IGFuZCBWUDkgd2lsbCBiZSBlYXNpZXIg dGhhbiBpdCBpcyB0b2RheSBiZXR3ZWVuIFZQOCBhbmQgSDI2NC4NCkFyZSB3ZSBnb2luZyB0byBt dWx0aXBseSBzaW1pbGFybHkgcGVyZm9ybWluZyBjb2RlY3MgIGdvaW5nIGZvcndhcmQgKGluIHRo ZSBzcGVjIG9yIGluIHByYWN0aWNlKSBvciBiZSBzdHVjayB3aXRoIG1hbmRhdG9yeSBsb3cgcGVy Zm9ybWluZyBjb2RlY3MgYmVjYXVzZSB3ZSBjYW5ub3QgbWFrZSBiZXR0ZXIgZGVjaXNpb24/DQoN Ckl0J3MgaW1wb3J0YW50IHRvIHJlbWVtYmVyIHRoYXQgdGhlIHJlcXVpcmVtZW50IGZvciBhbiBN VEkgY29kZWMNCmlzIHRvIGd1YXJhbnRlZSBiYXNpYyBpbnRlcm9wZXJhYmlsaXR5LiBJIHdvdWxk IG5vdCBpbWFnaW5lIHRoYXQgd2UNCndvdWxkIGRlZmluZSBhIG5ldyByZXF1aXJlZCBjb2RlYyB1 bmxlc3MgaXQgd2FzIG5vdCBqdXN0IHRlY2huaWNhbGx5DQpzdXBlcmlvciBidXQgYWxzbyBkZWZp bml0aXZlbHkgUkYgaW4gdGhlIHNlbnNlIGNvbnRlbXBsYXRlZCBieSBBZGFtJ3MNCnRleHQuDQoN Ci1Fa3INCg0KDQoNClRpbWUgZnJhbWUgZm9yIEgyNjUgLyBWUDkgIGlzIHVwIHRvIHR3byB5ZWFy cyBmcm9tIG5vdw0KQW5kIHBvc3NpYmx5IHRoZSB0aW1lZnJhbWUgZm9yIEguMjY2L0RhbGFhIGlz IGZvdXIgeWVhcnMgZnJvbSBub3cNCg0KVGhpcyBpcyBvbmUgbW9yZSBkcmF3YmFjayBvZiB0aGUg cHJvcG9zZWQgdGV4dCBmb3IgTVRJLCBub3Qgb25seSBpdCBtdWx0aXBsaWVzIGVuY29kZXJzIGFu ZCBkZWNvZGVycyB0byBiZSBzdXBwb3J0ZWQgYnV0ICBjYW4gcHJldmVudCB0aGUgZXZvbHV0aW9u IG9mIHdlYnJ0YyB0b3dhcmQgbW9yZSBhZHZhbmNlcyBjb2RlY3MuIChhc3N1bWluZyB3ZSB3aWxs IG5vdCByZXF1aXJlIDQgb3IgNiBlbmNvZGVycyBhbmQgNCBvciA2IGRlY29kZXJzIHRvIGJlIHN1 cHBvcnRlZCBieSBldmVyeSBzaW5nbGUgZW5kcG9pbnRzLiBUd28gTVRJIHNlZW1zIGxhcmdlbHkg ZW5vdWdoLCBubz8pLg0KDQpHYcOrbGxlDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1i b3VuY2VzQGlldGYub3JnPG1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFs ZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxNiwgMjAxNCAxMTo1 MyBBTQ0KVG86IEpvaG4gTGVzbGllDQpDYzogcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gcmV2aXNpdGluZyBNVEkNCg0KT24gVHVl LCBEZWMgMTYsIDIwMTQgYXQgODoyNSBBTSwgSm9obiBMZXNsaWUgPGpvaG5AamxjLm5ldDxtYWls dG86am9obkBqbGMubmV0Pj4gd3JvdGU6DQpFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFp bHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KPiBPbiBUdWUsIERlYyAxNiwgMjAxNCBhdCA3OjIx IEFNLCBKb2huIExlc2xpZSA8am9obkBqbGMubmV0PG1haWx0bzpqb2huQGpsYy5uZXQ+PiB3cm90 ZToNCj4gTmVlZGxlc3MgdG8gc2F5LCBoYXZpbmcgV0cgY29uc2Vuc3VzIG9uIHRoZSBzdWJzdGFu Y2UgYW5kIGxldHRpbmcgdGhlDQo+IGVkaXRvciB3b3Jkc21pdGggdGhlIHRleHQgaXMgdG90YWxs eSBub3JtYWwgSUVURiBwcm9jZXNzLg0KDQogICBJbiBzb21lIGNhc2VzLCB5ZXMuIElNSE8sIHRo aXMgaXMgbm90IG9uZSBvZiB0aGVtLiBZTU1WLi4uDQoNCkluZGVlZCBpdCBkb2VzLCBzaW5jZSBJ IGhhdmUgKm5ldmVyKiBoZWFyZCBvZiBzdWNoIGEgY2FzZSB3aGVyZQ0KdGhlIGVkaXRvciBoYWQg bm8gZGlzY3JldGlvbiB0byBjaGFuZ2UgdGhlIHRleHQgaW4gcHVyZWx5IGVkaXRvcmlhbA0Kd2F5 cyAoc3ViamVjdCB0byBXRyBjb25zZW5zdXMgb2YgY291cnNlKS4gRmVlbCBmcmVlIHRvIGNpdGUg b25lDQppZiB5b3UgaGF2ZSBvbmUuDQoNCg0KPiBJIGhhdmVuJ3QgaGVhcmQgYW55b25lIHdobyB3 YXMgYXQgSE5MIGFuZCBpbiBmYXZvciBvZiB0aGUgdGV4dCBvbiB0aGUNCj4gc2xpZGVzIG9iamVj dCB0aGF0IEFkYW0ncyB0ZXh0IGluIHRoZSBkcmFmdCBkb2Vzbid0IHJlZmxlY3QgdGhvc2UNCj4g c2xpZGVzLg0KDQogICBQcm9iYWJseSB5b3UgaGF2ZW4ndC4uLg0KDQpUbyB0aGUgYmVzdCBvZiBt eSBrbm93bGVkZ2UgaXQgaGFzbid0IGhhcHBlbmVkLiBDYW4geW91IGNpdGUgYW55b25lDQp3aG8g aGFzIHNvIG9iamVjdGVkLg0KDQoNCg0KPiBCZXNpZGVzLCBFcmljIGlzbid0IHRoZSBXR0MgY2Fs bGluZyBjb25zZW5zdXMuDQo+DQo+IE5vLCB0aGUgY2hhaXJzIGRpZCBoZXJlOg0KPiBodHRwOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1cnJlbnQvbXNnMTM2OTYuaHRt bA0KXQ0KXSBGcm9tOiBTZWFuIFR1cm5lciA8dHVybmVycyBhdCBpZWNhLmNvbTxodHRwOi8vaWVj YS5jb20+Pg0KXSBBdCB0aGUgMm5kIFJUQ3dlYiBXRyBzZXNzaW9uIEAgSUVURiA5MSwgd2UgaGFk IGEgbGl2ZWx5IGRpc2N1c3Npb24NCl0gYWJvdXQgY29kZWNzLCB3aGljaCBJIGR1YmJlZCAidGhl IGdyZWF0IGNvZGVjIGNvbXByb21pc2UuIg0KXSBUaGUgY29tcHJvbWlzZSB0ZXh0IHRoYXQgd2Fz IGRpc2N1c3NlZCBhcHBlYXJzIGluIHNsaWRlcyAxMi0xNCBhdCBbNF0NCl0gKHdoaWNoIGlzIGEg c2xpZ2h0IGVkaXRvcmlhbCB2YXJpYXRpb24gb2YgdGhlIHRleHQgcHJvcG9zZWQgYXQgWzJdKS4N Cl0NCl0gVGhpcyBtZXNzYWdlIHNlcnZlcyB0byBjb25maXJtIHRoZSBzZW5zZSBvZiB0aGUgcm9v bS4NCg0KICAgQWN0dWFsbHksIGFzIEkgcmVhZCB0aGlzIG1vcmUgY2FyZWZ1bGx5LCB0aGF0IGlz bid0IGEgY29uc2Vuc3VzIGNhbGwuDQpTZWFuIGdvZXMgb24gdG8gZGlzbWlzcyB0aGUgb2JqZWN0 aW9ucyBoZSBoZWFyZCBpbiB0aGUgcm9vbToNCg0KSGUncyBhZGRyZXNzaW5nIHRoZW0uIFdoYXQg ZXhhY3RseSBpcyB0aGUgcHJvYmxlbSB3aXRoIHRoaXM/DQoNCg0KXSAzKSBUcmlnZ2VyOg0KXSBP YmplY3Rpb246IFRoZSAidHJpZ2dlciIgc2VudGVuY2UgWzNdIGlzIGFsbCBraW5kcyBvZiB3cm9u ZyBiZWNhdXNlDQpdIGl0J3MgcHJvbWlzaW5nIHRoYXQgdGhlIGZ1dHVyZSBJRVRGIHdpbGwgdXBk YXRlIHRoaXMgc3BlY2lmaWNhdGlvbi4NCl0gUmVzcG9uc2U6IExpa2UgYW55IElFVEYgcHJvcG9z YWwsIGFuIFJGQyB0aGF0IGRvY3VtZW50cyB0aGUgY3VycmVudA0KXSBwcm9wb3NhbCBjYW4gYmUg Y2hhbmdlZCB0aHJvdWdoIHRoZSBjb25zZW5zdXMgcHJvY2VzcyBhdCBhbnkgb3RoZXIgdGltZS4N Cg0KICAgU2VhbiBpcyBzcGVjaWZpY2FsbHkgc2F5aW5nIHRoZSAidHJpZ2dlciIgc2hvdWxkIGJl IGRpc2N1c3NlZA0Kb24tbGlzdC4NCg0KSSBkb24ndCByZWFkIHRoaXMgdGhpcyB3YXkgYXQgYWxs LCBSYXRoZXIgaGUncyBzYXlpbmcgdGhhdCBpbiB0aGUgZnV0dXJlIHdlDQpjYW4gdXBkYXRlIHRo ZSBSRkMuIEJ1dCB5ZXMsIHdlIGNhbiBkaXNjdXNzIHRoZSB0cmlnZ2VyIG9uLWxpc3QuIERvIHlv dQ0KaGF2ZSBzb21lIHN1YnN0YW50aXZlIG9iamVjdGlvbiB0aGF0IHdhc24ndCByYWlzZWQgaW4g SE5MIGFuZC9vcg0KaGFzbid0IGJlZW4gZGlzY3Vzc2VkIHRvIGRlYXRoIGhlcmU/DQoNCg0KXSBB ZnRlciB0aGUgZGlzY3Vzc2lvbiwgc29tZSBjbGFyaWZ5aW5nIHF1ZXN0aW9ucyBhYm91dCB0aGUg aHVtcywgYW5kDQpdIHR5cGluZyB0aGUgaHVtIHF1ZXN0aW9ucyBvbiB0aGUgc2NyZWVuLCB0aGVy ZSB3YXMgcm91Z2ggY29uc2Vuc3VzIGluDQpdIHRoZSByb29tIHRvIGFkZCAoYWthICJzaG92ZSIp IHRoZSBwcm9wb3NlZCB0ZXh0IGludG8NCl0gZHJhZnQtaWV0Zi1ydGN3ZWItdmlkZW8uIEluIGtl ZXBpbmcgd2l0aCBJRVRGIHByb2Nlc3MsIEkgYW0gY29uZmlybWluZw0KXSB0aGlzIGNvbnNlbnN1 cyBjYWxsIG9uIHRoZSBsaXN0Lg0KDQogICBUaGlzIF9pc18gY2FsbGluZyBmb3IgY29uc2Vuc3Vz Lg0KDQogICBCdXQgU2VhbiBvbWl0dGVkIHNheWluZyBfd2hhdF8gdGV4dDsgYW5kIGFncmVlZCB0 aGF0IHRoZSBleGFjdCB0ZXh0DQptYXkgbm90IGhhdmUgYmVlbiBjbGVhciB0byB0aG9zZSBpbiB0 aGUgcm9vbS4NCg0KSHVoPyBUaGUgInByb3Bvc2VkIHRleHQiIHRoYXQgd2FzIGRpc2N1c3NlZCBp biBITkwgaXMgb24gdGhlIHNsaWRlIGFuZA0KdGhhdCdzIHdoYXQncyBiZWluZyByZWZlcnJlZCB0 byBoZXJlLiBBZGFtIGVkaXRlZCB0ZXh0IHdoaWNoIGlzIHN1YnN0YW50aWFsbHkNCnRoZSBzYW1l IGludG8gdGhlIGRyYWZ0Lg0KDQoNCg0KXSBJZiBhbnlvbmUgaGFzIGFueSBvdGhlciBpc3N1ZXMg dGhhdCB0aGV5IHdvdWxkIGxpa2UgdG8gcmFpc2UgcGxlYXNlIGRvDQpdIGJ5IERlY2VtYmVyIDE5 dGguDQoNCiAgIChBbmQgZm9sa3MgaGF2ZSBiZWVuIGRvaW5nIHNvLikNCg0KICAgSSBoYXZlIGFz a2VkIG9uLWxpc3QgZm9yIHRoZSBleGFjdCB0ZXh0IGJlZm9yZSByYWlzaW5nIG15IGlzc3VlcywN CnNpbmNlIG15IGlzc3VlcyByZWxhdGUgdG8gdGhlIHRleHQsIG5vdCB0aGUgY2hvb3NpbmcgdG8g aGF2ZSB0d28gTVRJcy4NCg0KQXMgSSBwb2ludGVkIG91dCBpbiBteSBvcmlnaW5hbCBtZXNzYWdl LCB0aGF0IHRleHQgaXMgaW4gQWRhbSdzIGRyYWZ0Lg0KDQpBZ2FpbiwgaXQncyB0b3RhbGx5IHBy b2NlZHVyYWxseSByZWd1bGFyIHRvIGhhdmUgcm91Z2ggY29uc2Vuc3VzIG9uIHRleHQgaW4NCnRo ZSBXRyBtZWV0aW5nIGFuZCBvbiB0aGUgbGlzdCBhbmQgdGhlbiBoYXZlIHRoZSBlZGl0b3IgZWRp dCBpbiBzdWJzdGFudGl2ZWx5DQp0aGUgc2FtZSB0ZXh0IHRvIHRoZSBkcmFmdC4gSWYgeW91IHRo aW5rIHRoZXJlIGlzIHNvbWUgcmVzcGVjdCBpbiB3aGljaCB0aG9zZQ0KdHdvIGJsb2NrcyBvZiB0 ZXh0IGFyZSBub3QgaW4gZmFjdCB0aGUgc2FtZSwgcGxlYXNlIHBvaW50IHRvIGl0LiBPdGhlcndp c2UsDQp0aGlzIGlzIGp1c3QgZGlsYXRvcnkuDQoNCg0KPiBBbmQgdGhpcyBtZXNzYWdlIGNsZWFy bHkgcG9pbnRzIHRvIHRoZSBzbGlkZXMgYWJvdmUuDQoNCiAgIEkgZG9uJ3QgZmluZCBpdCBoZWxw ZnVsIHRvIGF0dGFjayB0aGUgcGVvcGxlIHdobyByYWlzZSBpc3N1ZXMuIFlNTVYuDQoNCiAgIEJ1 dCB3aGF0IEVLUiB0aGlua3MgcmVhbGx5IGRvZXNuJ3QgbWF0dGVyLiBIZSBpcyBub3QgYSBXR0Mu DQoNCklyb25pYyB0aGF0IHlvdSB3b3VsZCBjb21wbGFpbiBhYm91dCAiYXR0YWNrInMgaW4gYSB0 aHJlYWQgd2hlcmUgeW91DQpzdGFydGVkIG91dCBieSBhdHRhY2tpbmcgQWRhbSBSb2FjaCBhbmQg aGVyZSBzYXkgIndoYXQgRUtSIHRoaW5rcw0KcmVhbGx5IGRvZXNuJ3QgbWF0dGVyIg0KDQotRWty DQo= --_000_92D0D52F3A63344CA478CF12DB0648AADF363549XMB111CNCrimnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgYW0gbm90IHN1cmUgb24gd2hhdCB5b3UgYXJlIGJhc2luZyB5b3VyIG9w aW5pb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldhaXRpbmcgZm9yIGFuIFJGIHRl Y2huaWNhbGx5IHN1cGVyaW9yIGNvZGVjIG1pZ2h0IG5vdCBiZSBwcmFnbWF0aWMgYW5kIGNhbiBp bmRlZWQgcHJldmVudCBhbnkgZXZvbHV0aW9uIG9mIFdlYlJUQyBjb2RlYyBmb3IgYSBsb25nIHRp bWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlcHJlY2F0aW5nIE1USSBjYW4gYmUg ZG9uZSBpbiBzdGVwcyAoZS5nLiBiZWNvbWUgU0hPVUxELCB0aGVuIE1BWSk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklm IHRoaXMgTVRJIHRleHQgcHJldmVudHMgY29kZWMgZXZvbHV0aW9uLCB0aGlzIGlzIGEgc2VyaW91 cyBpc3N1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+R2HDq2xsZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gVHVlc2RheSwgRGVjZW1iZXIgMTYsIDIwMTQgMjozOCBQTTxicj4NCjxiPlRv OjwvYj4gR2FlbGxlIE1hcnRpbi1Db2NoZXI8YnI+DQo8Yj5DYzo8L2I+IEpvaG4gTGVzbGllOyBy dGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIHJldmlzaXRp bmcgTVRJPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBEZWMgMTYsIDIwMTQgYXQg MTE6MzEgQU0sIEdhZWxsZSBNYXJ0aW4tQ29jaGVyICZsdDs8YSBocmVmPSJtYWlsdG86Z21hcnRp bmNvY2hlckBibGFja2JlcnJ5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdtYXJ0aW5jb2NoZXJAYmxh Y2tiZXJyeS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SSBoYXZlIGxpdHRsZSBjb25maWRlbmNlIHRoYXQgdGhlIGNob2ljZSBiZXR3ZWVu IEgyNjUgYW5kIFZQOSB3aWxsIGJlIGVhc2llciB0aGFuIGl0IGlzIHRvZGF5IGJldHdlZW4NCiBW UDggYW5kIEgyNjQuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFyZSB3ZSBnb2lu ZyB0byBtdWx0aXBseSBzaW1pbGFybHkgcGVyZm9ybWluZyBjb2RlY3MgJm5ic3A7Z29pbmcgZm9y d2FyZCAoaW4gdGhlIHNwZWMgb3IgaW4gcHJhY3RpY2UpDQogb3IgYmUgc3R1Y2sgd2l0aCBtYW5k YXRvcnkgbG93IHBlcmZvcm1pbmcgY29kZWNzIGJlY2F1c2Ugd2UgY2Fubm90IG1ha2UgYmV0dGVy IGRlY2lzaW9uPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCdzIGltcG9ydGFudCB0byByZW1lbWJlciB0aGF0IHRo ZSByZXF1aXJlbWVudCBmb3IgYW4gTVRJIGNvZGVjPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pcyB0byBndWFyYW50ZWUgYmFzaWMgaW50ZXJvcGVy YWJpbGl0eS4gSSB3b3VsZCBub3QgaW1hZ2luZSB0aGF0IHdlPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53b3VsZCBkZWZpbmUgYSBuZXcgcmVxdWly ZWQgY29kZWMgdW5sZXNzIGl0IHdhcyBub3QganVzdCB0ZWNobmljYWxseTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c3VwZXJpb3IgYnV0IGFsc28g ZGVmaW5pdGl2ZWx5IFJGIGluIHRoZSBzZW5zZSBjb250ZW1wbGF0ZWQgYnkgQWRhbSdzPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50ZXh0LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlRpbWUgZnJhbWUgZm9yIEgyNjUgLyBWUDkgJm5ic3A7aXMgdXAgdG8gdHdvIHllYXJz IGZyb20gbm93DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbmQgcG9zc2libHkg dGhlIHRpbWVmcmFtZSBmb3IgSC4yNjYvRGFsYWEgaXMgZm91ciB5ZWFycyBmcm9tIG5vdzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRoaXMgaXMgb25lIG1vcmUgZHJhd2JhY2sgb2YgdGhlIHByb3Bvc2VkIHRleHQg Zm9yIE1USSwgbm90IG9ubHkgaXQgbXVsdGlwbGllcyBlbmNvZGVycyBhbmQgZGVjb2RlcnMNCiB0 byBiZSBzdXBwb3J0ZWQgYnV0ICZuYnNwO2NhbiBwcmV2ZW50IHRoZSBldm9sdXRpb24gb2Ygd2Vi cnRjIHRvd2FyZCBtb3JlIGFkdmFuY2VzIGNvZGVjcy4gKGFzc3VtaW5nIHdlIHdpbGwgbm90IHJl cXVpcmUgNCBvciA2IGVuY29kZXJzIGFuZCA0IG9yIDYgZGVjb2RlcnMgdG8gYmUgc3VwcG9ydGVk IGJ5IGV2ZXJ5IHNpbmdsZSBlbmRwb2ludHMuIFR3byBNVEkgc2VlbXMgbGFyZ2VseSBlbm91Z2gs IG5vPykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+R2HDq2xsZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpydGN3ZWIt Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYi1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpYyBSZXNjb3JsYTxicj4NCjxiPlNlbnQ6PC9i PiBUdWVzZGF5LCBEZWNlbWJlciAxNiwgMjAxNCAxMTo1MyBBTTxicj4NCjxiPlRvOjwvYj4gSm9o biBMZXNsaWU8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbcnRjd2ViXSByZXZpc2l0aW5nIE1USTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgRGVjIDE2LCAyMDE0IGF0IDg6MjUg QU0sIEpvaG4gTGVzbGllICZsdDs8YSBocmVmPSJtYWlsdG86am9obkBqbGMubmV0IiB0YXJnZXQ9 Il9ibGFuayI+am9obkBqbGMubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4m Z3Q7IHdyb3RlOjxicj4NCiZndDsgT24gVHVlLCBEZWMgMTYsIDIwMTQgYXQgNzoyMSBBTSwgSm9o biBMZXNsaWUgJmx0OzxhIGhyZWY9Im1haWx0bzpqb2huQGpsYy5uZXQiIHRhcmdldD0iX2JsYW5r Ij5qb2huQGpsYy5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mZ3Q7IE5lZWRsZXNzIHRvIHNheSwgaGF2aW5nIFdHIGNvbnNlbnN1cyBvbiB0aGUgc3Vi c3RhbmNlIGFuZCBsZXR0aW5nIHRoZTxicj4NCiZndDsgZWRpdG9yIHdvcmRzbWl0aCB0aGUgdGV4 dCBpcyB0b3RhbGx5IG5vcm1hbCBJRVRGIHByb2Nlc3MuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw O0luIHNvbWUgY2FzZXMsIHllcy4gSU1ITywgdGhpcyBpcyBub3Qgb25lIG9mIHRoZW0uIFlNTVYu Li48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5JbmRlZWQgaXQgZG9lcywgc2luY2UgSSBoYXZlICpuZXZlciogaGVhcmQgb2Yg c3VjaCBhIGNhc2Ugd2hlcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+dGhlIGVkaXRvciBoYWQgbm8gZGlzY3JldGlvbiB0byBjaGFuZ2UgdGhl IHRleHQgaW4gcHVyZWx5IGVkaXRvcmlhbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj53YXlzIChzdWJqZWN0IHRvIFdHIGNvbnNlbnN1cyBvZiBj b3Vyc2UpLiBGZWVsIGZyZWUgdG8gY2l0ZSBvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+aWYgeW91IGhhdmUgb25lLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7IEkgaGF2ZW4ndCBoZWFyZCBh bnlvbmUgd2hvIHdhcyBhdCBITkwgYW5kIGluIGZhdm9yIG9mIHRoZSB0ZXh0IG9uIHRoZTxicj4N CiZndDsgc2xpZGVzIG9iamVjdCB0aGF0IEFkYW0ncyB0ZXh0IGluIHRoZSBkcmFmdCBkb2Vzbid0 IHJlZmxlY3QgdGhvc2U8YnI+DQomZ3Q7IHNsaWRlcy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 UHJvYmFibHkgeW91IGhhdmVuJ3QuLi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UbyB0aGUgYmVzdCBvZiBteSBrbm93bGVk Z2UgaXQgaGFzbid0IGhhcHBlbmVkLiBDYW4geW91IGNpdGUgYW55b25lPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPndobyBoYXMgc28gb2JqZWN0 ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4N CiZndDsgQmVzaWRlcywgRXJpYyBpc24ndCB0aGUgV0dDIGNhbGxpbmcgY29uc2Vuc3VzLjxicj4N CiZndDs8YnI+DQomZ3Q7IE5vLCB0aGUgY2hhaXJzIGRpZCBoZXJlOjxicj4NCiZndDsgPGEgaHJl Zj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50L21z ZzEzNjk2Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9ydGN3ZWIvY3VycmVudC9tc2cxMzY5Ni5odG1sPC9hPjxicj4NCl08YnI+DQpd IEZyb206IFNlYW4gVHVybmVyICZsdDt0dXJuZXJzIGF0IDxhIGhyZWY9Imh0dHA6Ly9pZWNhLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmllY2EuY29tPC9hPiZndDs8YnI+DQpdIEF0IHRoZSAybmQgUlRD d2ViIFdHIHNlc3Npb24gQCBJRVRGIDkxLCB3ZSBoYWQgYSBsaXZlbHkgZGlzY3Vzc2lvbjxicj4N Cl0gYWJvdXQgY29kZWNzLCB3aGljaCBJIGR1YmJlZCAmcXVvdDt0aGUgZ3JlYXQgY29kZWMgY29t cHJvbWlzZS4mcXVvdDs8YnI+DQpdIFRoZSBjb21wcm9taXNlIHRleHQgdGhhdCB3YXMgZGlzY3Vz c2VkIGFwcGVhcnMgaW4gc2xpZGVzIDEyLTE0IGF0IFs0XTxicj4NCl0gKHdoaWNoIGlzIGEgc2xp Z2h0IGVkaXRvcmlhbCB2YXJpYXRpb24gb2YgdGhlIHRleHQgcHJvcG9zZWQgYXQgWzJdKS48YnI+ DQpdPGJyPg0KXSBUaGlzIG1lc3NhZ2Ugc2VydmVzIHRvIGNvbmZpcm0gdGhlIHNlbnNlIG9mIHRo ZSByb29tLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtBY3R1YWxseSwgYXMgSSByZWFkIHRoaXMg bW9yZSBjYXJlZnVsbHksIHRoYXQgaXNuJ3QgYSBjb25zZW5zdXMgY2FsbC48YnI+DQpTZWFuIGdv ZXMgb24gdG8gZGlzbWlzcyB0aGUgb2JqZWN0aW9ucyBoZSBoZWFyZCBpbiB0aGUgcm9vbTo8bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5IZSdzIGFkZHJlc3NpbmcgdGhlbS4gV2hhdCBleGFjdGx5IGlzIHRoZSBwcm9ibGVtIHdp dGggdGhpcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+ DQpdIDMpIFRyaWdnZXI6PGJyPg0KXSBPYmplY3Rpb246IFRoZSAmcXVvdDt0cmlnZ2VyJnF1b3Q7 IHNlbnRlbmNlIFszXSBpcyBhbGwga2luZHMgb2Ygd3JvbmcgYmVjYXVzZTxicj4NCl0gaXQncyBw cm9taXNpbmcgdGhhdCB0aGUgZnV0dXJlIElFVEYgd2lsbCB1cGRhdGUgdGhpcyBzcGVjaWZpY2F0 aW9uLjxicj4NCl0gUmVzcG9uc2U6IExpa2UgYW55IElFVEYgcHJvcG9zYWwsIGFuIFJGQyB0aGF0 IGRvY3VtZW50cyB0aGUgY3VycmVudDxicj4NCl0gcHJvcG9zYWwgY2FuIGJlIGNoYW5nZWQgdGhy b3VnaCB0aGUgY29uc2Vuc3VzIHByb2Nlc3MgYXQgYW55IG90aGVyIHRpbWUuPGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwO1NlYW4gaXMgc3BlY2lmaWNhbGx5IHNheWluZyB0aGUgJnF1b3Q7dHJpZ2dl ciZxdW90OyBzaG91bGQgYmUgZGlzY3Vzc2VkPGJyPg0Kb24tbGlzdC48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGRvbid0 IHJlYWQgdGhpcyB0aGlzIHdheSBhdCBhbGwsIFJhdGhlciBoZSdzIHNheWluZyB0aGF0IGluIHRo ZSBmdXR1cmUgd2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Y2FuIHVwZGF0ZSB0aGUgUkZDLiBCdXQgeWVzLCB3ZSBjYW4gZGlzY3VzcyB0aGUg dHJpZ2dlciBvbi1saXN0LiBEbyB5b3U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+aGF2ZSBzb21lIHN1YnN0YW50aXZlIG9iamVjdGlvbiB0aGF0 IHdhc24ndCByYWlzZWQgaW4gSE5MIGFuZC9vcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5oYXNuJ3QgYmVlbiBkaXNjdXNzZWQgdG8gZGVhdGgg aGVyZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+XSBB ZnRlciB0aGUgZGlzY3Vzc2lvbiwgc29tZSBjbGFyaWZ5aW5nIHF1ZXN0aW9ucyBhYm91dCB0aGUg aHVtcywgYW5kPGJyPg0KXSB0eXBpbmcgdGhlIGh1bSBxdWVzdGlvbnMgb24gdGhlIHNjcmVlbiwg dGhlcmUgd2FzIHJvdWdoIGNvbnNlbnN1cyBpbjxicj4NCl0gdGhlIHJvb20gdG8gYWRkIChha2Eg JnF1b3Q7c2hvdmUmcXVvdDspIHRoZSBwcm9wb3NlZCB0ZXh0IGludG88YnI+DQpdIGRyYWZ0LWll dGYtcnRjd2ViLXZpZGVvLiBJbiBrZWVwaW5nIHdpdGggSUVURiBwcm9jZXNzLCBJIGFtIGNvbmZp cm1pbmc8YnI+DQpdIHRoaXMgY29uc2Vuc3VzIGNhbGwgb24gdGhlIGxpc3QuPGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwO1RoaXMgX2lzXyBjYWxsaW5nIGZvciBjb25zZW5zdXMuPGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwO0J1dCBTZWFuIG9taXR0ZWQgc2F5aW5nIF93aGF0XyB0ZXh0OyBhbmQgYWdy ZWVkIHRoYXQgdGhlIGV4YWN0IHRleHQ8YnI+DQptYXkgbm90IGhhdmUgYmVlbiBjbGVhciB0byB0 aG9zZSBpbiB0aGUgcm9vbS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IdWg/IFRoZSAmcXVvdDtwcm9wb3NlZCB0ZXh0JnF1 b3Q7IHRoYXQgd2FzIGRpc2N1c3NlZCBpbiBITkwgaXMgb24gdGhlIHNsaWRlIGFuZDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50aGF0J3Mgd2hh dCdzIGJlaW5nIHJlZmVycmVkIHRvIGhlcmUuIEFkYW0gZWRpdGVkIHRleHQgd2hpY2ggaXMgc3Vi c3RhbnRpYWxseTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj50aGUgc2FtZSBpbnRvIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl0gSWYgYW55b25lIGhhcyBhbnkgb3RoZXIgaXNz dWVzIHRoYXQgdGhleSB3b3VsZCBsaWtlIHRvIHJhaXNlIHBsZWFzZSBkbzxicj4NCl0gYnkgRGVj ZW1iZXIgMTl0aC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7KEFuZCBmb2xrcyBoYXZlIGJlZW4g ZG9pbmcgc28uKTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtJIGhhdmUgYXNrZWQgb24tbGlzdCBm b3IgdGhlIGV4YWN0IHRleHQgYmVmb3JlIHJhaXNpbmcgbXkgaXNzdWVzLDxicj4NCnNpbmNlIG15 IGlzc3VlcyByZWxhdGUgdG8gdGhlIHRleHQsIG5vdCB0aGUgY2hvb3NpbmcgdG8gaGF2ZSB0d28g TVRJcy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5BcyBJIHBvaW50ZWQgb3V0IGluIG15IG9yaWdpbmFsIG1lc3NhZ2UsIHRo YXQgdGV4dCBpcyBpbiBBZGFtJ3MgZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BZ2FpbiwgaXQncyB0b3RhbGx5IHByb2NlZHVy YWxseSByZWd1bGFyIHRvIGhhdmUgcm91Z2ggY29uc2Vuc3VzIG9uIHRleHQgaW48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dGhlIFdHIG1lZXRp bmcgYW5kIG9uIHRoZSBsaXN0IGFuZCB0aGVuIGhhdmUgdGhlIGVkaXRvciBlZGl0IGluIHN1YnN0 YW50aXZlbHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+dGhlIHNhbWUgdGV4dCB0byB0aGUgZHJhZnQuIElmIHlvdSB0aGluayB0aGVyZSBpcyBz b21lIHJlc3BlY3QgaW4gd2hpY2ggdGhvc2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dHdvIGJsb2NrcyBvZiB0ZXh0IGFyZSBub3QgaW4gZmFj dCB0aGUgc2FtZSwgcGxlYXNlIHBvaW50IHRvIGl0LiBPdGhlcndpc2UsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRoaXMgaXMganVzdCBkaWxh dG9yeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0 OyBBbmQgdGhpcyBtZXNzYWdlIGNsZWFybHkgcG9pbnRzIHRvIHRoZSBzbGlkZXMgYWJvdmUuPGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwO0kgZG9uJ3QgZmluZCBpdCBoZWxwZnVsIHRvIGF0dGFjayB0 aGUgcGVvcGxlIHdobyByYWlzZSBpc3N1ZXMuIFlNTVYuPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtCdXQgd2hhdCBFS1IgdGhp bmtzIHJlYWxseSBkb2Vzbid0IG1hdHRlci4gSGUgaXMgbm90IGEgV0dDLjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklyb25p YyB0aGF0IHlvdSB3b3VsZCBjb21wbGFpbiBhYm91dCAmcXVvdDthdHRhY2smcXVvdDtzIGluIGEg dGhyZWFkIHdoZXJlIHlvdTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5zdGFydGVkIG91dCBieSBhdHRhY2tpbmcgQWRhbSBSb2FjaCBhbmQgaGVy ZSBzYXkgJnF1b3Q7d2hhdCBFS1IgdGhpbmtzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnJlYWxseSBkb2Vzbid0IG1hdHRlciZxdW90OzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LUVr cjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_92D0D52F3A63344CA478CF12DB0648AADF363549XMB111CNCrimnet_-- From nobody Tue Dec 16 11:56:21 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C6B1A874B for ; Tue, 16 Dec 2014 11:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.609 X-Spam-Level: X-Spam-Status: No, score=-6.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrH4EDQRUAD5 for ; Tue, 16 Dec 2014 11:56:13 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71D901A8744 for ; Tue, 16 Dec 2014 11:56:07 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 344E7581113C4; Tue, 16 Dec 2014 19:56:02 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sBGJu4mw001585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Dec 2014 20:56:05 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 20:56:04 +0100 From: "DRAGE, Keith (Keith)" To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Roman Shpount Thread-Topic: [rtcweb] revisiting MTI Thread-Index: AQHQGK9hz+EPVQM3202R+pzBLk6Ke5yRiFAAgAAEJwCAAAEZAIAAAMsAgAAFmwCAARFEgIAAAWIAgAADogCAAAQ5gIAADdEAgAAHm4D//9TVIP//8zUAgAAA1ACAABVpIA== Date: Tue, 16 Dec 2014 19:56:04 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B296427@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> <92D0D52F3A63344CA478CF12DB0648AADF363463@XMB111CNC.rim.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B296427FR712WXCHMBA11zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lX980MObDFb6TZJkXdXmZH3tano Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 19:56:19 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B296427FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Forget it. You are making an attempt to reduce the entire issue to IPR, and the discus= sion prior to the last meeting had been wider that that, including issues o= f interoperability with endpoints outside webRTC. As far as I am concerned an IPR free codec is irrelevant if I cannot talk t= o the endpoints I need to, and just concentrating on the webrtc community a= s the available endpoint may meet some deployers use cases, but not others. Keith ________________________________ From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of I=F1aki Baz Cast= illo Sent: 16 December 2014 19:35 To: Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] revisiting MTI +1 On 16 Dec 2014 20:32, "Roman Shpount" > wrote: On Tue, Dec 16, 2014 at 2:26 PM, Gaelle Martin-Cocher > wrote: I think what has not been discussed is a differentiated text for both code= cs. VP8 to be deprecated if failing to meet RF statements from proponents H264 to be deprecated when not used anymore by legacy services in accordanc= e with H264 proponents statements How about VP8 to be depreciated if it fails to pass the ISO or other standardization = process or if licensing is confirmed in court to be a non royalty free. H264 to be depreciated if VP8 passes the standardization process and confir= med to be royalty free, unless H264 becomes royalty free as well? _____________ Roman Shpount _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_949EF20990823C4C85C18D59AA11AD8B296427FR712WXCHMBA11zeu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Forget it.
 
You are making an attempt to redu= ce the entire issue to IPR, and the discussion prior to the last meeting ha= d been wider that that, including issues of interoperability with endpoints outside webRTC.
 
As far as I am concerned an IPR f= ree codec is irrelevant if I cannot talk to the endpoints I need to, and ju= st concentrating on the webrtc community as the available endpoint may meet some deployers use cases, but not others.<= /font>
 
Keith

From: rtcweb [mailto:rtcweb-bounces= @ietf.org] On Behalf Of I=F1aki Baz Castillo
Sent: 16 December 2014 19:35
To: Roman Shpount
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] revisiting MTI

+1

On 16 Dec 2014 20:32, "Roman Shpount" = <roman@telurix.com> wrote:
On Tue, Dec 16, 2014 at 2:26 PM, Gaelle Martin-C= ocher <gmart= incocher@blackberry.com> wrote:

 

 I think = what has not been discussed is a differentiated text for both codecs.

VP8 to be deprecated if failing to meet= RF statements from proponents

H264 to be deprecated when not used any= more by legacy services in accordance with H264 proponents statements


 
How about 
VP8 to be depreciated if it fails to pass the ISO or other standardiza= tion process or if licensing is confirmed in court to be a non royalty free= .
H264 to be depreciated if VP8 passes the standardization process and c= onfirmed to be royalty free, unless H264 becomes royalty free as well?
_____________
Roman Shpount
 

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--_000_949EF20990823C4C85C18D59AA11AD8B296427FR712WXCHMBA11zeu_-- From nobody Tue Dec 16 12:00:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B7D1ACDFF for ; Tue, 16 Dec 2014 12:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIXOFj6ujqLn for ; Tue, 16 Dec 2014 12:00:04 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C741A8766 for ; Tue, 16 Dec 2014 12:00:04 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id r20so13478203wiv.0 for ; Tue, 16 Dec 2014 12:00:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kDcy7UNNNwnuFUtyl1O7TMD0dTnZZLjL1UeZUApWnGE=; b=RZFUPu76qMKDf8Cac52VZIljy7z43RZyggYA97IJJcwfbzUgE9+J9ExrMs0IEYclCp s0ZpFpOXYsjYkl5NiZiTpnWNixvjpkyhMQrpiEq4P3V7jZuhL9SqPoMTuUGVgJmMJ9w6 hnGBFIF505Mku/HRtamQIwuq8HzybQuqTaJ6CZhow3SEY6pglSIlvAtuhCihG3YkHb2w mcUiWM6PP8JJTTdMnq5AUQXRUoxRxwVBW+4a+/47ZAguFetVtQ4UF6gx3aWG1rcse9dC 0fPPbUVpp2v5gCDNhbd5LOGo+4EHf7MJa/m5YFyREZ2ZdSHVXmq/5i2e+12fyIv4eqC1 x4lA== X-Gm-Message-State: ALoCoQnIsnh16PLaKwHamqpXJMHOPBr6iUNAQcMVVQtUg+3yido42iufS7z0sdGEkFCnzkHQMs1P X-Received: by 10.194.203.104 with SMTP id kp8mr32839217wjc.103.1418760002869; Tue, 16 Dec 2014 12:00:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Tue, 16 Dec 2014 11:59:22 -0800 (PST) In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF363549@XMB111CNC.rim.net> References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> <92D0D52F3A63344CA478CF12DB0648AADF3634AA@XMB111CNC.rim.net> <92D0D52F3A63344CA478CF12DB0648AADF363549@XMB111CNC.rim.net> From: Eric Rescorla Date: Tue, 16 Dec 2014 11:59:22 -0800 Message-ID: To: Gaelle Martin-Cocher Content-Type: multipart/alternative; boundary=047d7bae493efe2541050a5acd2d Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XE-daBfFeavrmrAtzUVDWeiR4K0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 20:00:09 -0000 --047d7bae493efe2541050a5acd2d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 16, 2014 at 11:56 AM, Gaelle Martin-Cocher < gmartincocher@blackberry.com> wrote: > > I am not sure on what you are basing your opinion. > As I said, the purpose of an MTI is to provide basic interop. Waiting for an RF technically superior codec might not be pragmatic and > can indeed prevent any evolution of WebRTC codec for a long time. > > Deprecating MTI can be done in steps (e.g. become SHOULD, then MAY) > > > > If this MTI text prevents codec evolution, this is a serious issue. > It doesn't prevent codec evolution. That's why we have negotiation. Browser= s are free to implement non-MTI codecs and I would anticipate that they will do so. -Ekr Ga=C3=ABlle > > > > > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* Tuesday, December 16, 2014 2:38 PM > *To:* Gaelle Martin-Cocher > *Cc:* John Leslie; rtcweb@ietf.org > > *Subject:* Re: [rtcweb] revisiting MTI > > > > > > > > On Tue, Dec 16, 2014 at 11:31 AM, Gaelle Martin-Cocher < > gmartincocher@blackberry.com> wrote: > > I have little confidence that the choice between H265 and VP9 will be > easier than it is today between VP8 and H264. > > Are we going to multiply similarly performing codecs going forward (in > the spec or in practice) or be stuck with mandatory low performing codecs > because we cannot make better decision? > > > > It's important to remember that the requirement for an MTI codec > > is to guarantee basic interoperability. I would not imagine that we > > would define a new required codec unless it was not just technically > > superior but also definitively RF in the sense contemplated by Adam's > > text. > > > > -Ekr > > > > > > > > Time frame for H265 / VP9 is up to two years from now > > And possibly the timeframe for H.266/Dalaa is four years from now > > > > This is one more drawback of the proposed text for MTI, not only it > multiplies encoders and decoders to be supported but can prevent the > evolution of webrtc toward more advances codecs. (assuming we will not > require 4 or 6 encoders and 4 or 6 decoders to be supported by every sing= le > endpoints. Two MTI seems largely enough, no?). > > > > Ga=C3=ABlle > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Eric > Rescorla > *Sent:* Tuesday, December 16, 2014 11:53 AM > *To:* John Leslie > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] revisiting MTI > > > > On Tue, Dec 16, 2014 at 8:25 AM, John Leslie wrote: > > Eric Rescorla wrote: > > On Tue, Dec 16, 2014 at 7:21 AM, John Leslie wrote: > > > Needless to say, having WG consensus on the substance and letting the > > editor wordsmith the text is totally normal IETF process. > > In some cases, yes. IMHO, this is not one of them. YMMV... > > > > Indeed it does, since I have *never* heard of such a case where > > the editor had no discretion to change the text in purely editorial > > ways (subject to WG consensus of course). Feel free to cite one > > if you have one. > > > > > > > I haven't heard anyone who was at HNL and in favor of the text on the > > slides object that Adam's text in the draft doesn't reflect those > > slides. > > Probably you haven't... > > > > To the best of my knowledge it hasn't happened. Can you cite anyone > > who has so objected. > > > > > > > > Besides, Eric isn't the WGC calling consensus. > > > > No, the chairs did here: > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html > ] > ] From: Sean Turner > ] At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion > ] about codecs, which I dubbed "the great codec compromise." > ] The compromise text that was discussed appears in slides 12-14 at [4] > ] (which is a slight editorial variation of the text proposed at [2]). > ] > ] This message serves to confirm the sense of the room. > > Actually, as I read this more carefully, that isn't a consensus call. > Sean goes on to dismiss the objections he heard in the room: > > > > He's addressing them. What exactly is the problem with this? > > > > > ] 3) Trigger: > ] Objection: The "trigger" sentence [3] is all kinds of wrong because > ] it's promising that the future IETF will update this specification. > ] Response: Like any IETF proposal, an RFC that documents the current > ] proposal can be changed through the consensus process at any other time= . > > Sean is specifically saying the "trigger" should be discussed > on-list. > > > > I don't read this this way at all, Rather he's saying that in the future = we > > can update the RFC. But yes, we can discuss the trigger on-list. Do you > > have some substantive objection that wasn't raised in HNL and/or > > hasn't been discussed to death here? > > > > > > ] After the discussion, some clarifying questions about the hums, and > ] typing the hum questions on the screen, there was rough consensus in > ] the room to add (aka "shove") the proposed text into > ] draft-ietf-rtcweb-video. In keeping with IETF process, I am confirming > ] this consensus call on the list. > > This _is_ calling for consensus. > > But Sean omitted saying _what_ text; and agreed that the exact text > may not have been clear to those in the room. > > > > Huh? The "proposed text" that was discussed in HNL is on the slide and > > that's what's being referred to here. Adam edited text which is > substantially > > the same into the draft. > > > > > > > > ] If anyone has any other issues that they would like to raise please do > ] by December 19th. > > (And folks have been doing so.) > > I have asked on-list for the exact text before raising my issues, > since my issues relate to the text, not the choosing to have two MTIs. > > > > As I pointed out in my original message, that text is in Adam's draft. > > > > Again, it's totally procedurally regular to have rough consensus on text = in > > the WG meeting and on the list and then have the editor edit in > substantively > > the same text to the draft. If you think there is some respect in which > those > > two blocks of text are not in fact the same, please point to it. Otherwis= e, > > this is just dilatory. > > > > > > > And this message clearly points to the slides above. > > I don't find it helpful to attack the people who raise issues. YMMV. > > > > But what EKR thinks really doesn't matter. He is not a WGC. > > > > Ironic that you would complain about "attack"s in a thread where you > > started out by attacking Adam Roach and here say "what EKR thinks > > really doesn't matter" > > > > -Ekr > > --047d7bae493efe2541050a5acd2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 16, 2014 at 11:56 AM, Gaelle Martin-Cocher <gma= rtincocher@blackberry.com> wrote:

I am not sure on what you= are basing your opinion.


As I said, the purpose of an MTI is to provide basic interop.


Waiting for an RF technic= ally superior codec might not be pragmatic and can indeed prevent any evolu= tion of WebRTC codec for a long time.

Deprecating MTI can be do= ne in steps (e.g. become SHOULD, then MAY)

=C2=A0

If this MTI text prevents= codec evolution, this is a serious issue.


It doesn't prevent codec evolution. That's w= hy we have negotiation. Browsers
are free to implement non-MTI co= decs and I would anticipate that they
will do so.

<= /div>
-Ekr




<= /div>

Ga=C3=ABlle=

=C2=A0

=C2=A0

From: Eric Res= corla [mailto:ekr@rtfm.co= m]
Sent: Tuesday, December 16, 2014 2:38 PM
To: Gaelle Martin-Cocher
Cc: John Leslie; rtcweb@ietf.org


Subject: Re: [rtcweb] revisiting MTI

=C2=A0

=C2=A0

=C2=A0

On Tue, Dec 16, 2014 at 11:31 AM, Gaelle Martin-Coch= er <gm= artincocher@blackberry.com> wrote:

I have little confidence = that the choice between H265 and VP9 will be easier than it is today betwee= n VP8 and H264.

Are we going to multiply = similarly performing codecs =C2=A0going forward (in the spec or in practice= ) or be stuck with mandatory low performing codecs because we cannot make be= tter decision?

=C2=A0

It's important to remember that the requirement = for an MTI codec

is to guarantee basic interoperability. I would not = imagine that we

would define a new required codec unless it was not = just technically

superior but also definitively RF in the sense conte= mplated by Adam's

text.

=C2=A0

-Ekr

=C2=A0

=C2=A0

=C2=A0

Time frame for H265 / VP9= =C2=A0is up to two years from now

And possibly the timefram= e for H.266/Dalaa is four years from now

=C2=A0

This is one more drawback= of the proposed text for MTI, not only it multiplies encoders and decoders to be supported but =C2=A0can prevent the evolution of webrtc toward more = advances codecs. (assuming we will not require 4 or 6 encoders and 4 or 6 d= ecoders to be supported by every single endpoints. Two MTI seems largely en= ough, no?).

=C2=A0

Ga=C3=ABlle=

=C2=A0

From: rtcweb [= mailto:rtcweb-= bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Tuesday, December 16, 2014 11:53 AM
To: John Leslie
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] revisiting MTI

=C2=A0

On Tue, Dec 16, 2014 at 8:25 AM, John Leslie <john@jlc.net> wrote:<= u>

Eric Rescorla <ekr@rtfm.com> wrote:
> On Tue, Dec 16, 2014 at 7:21 AM, John Leslie <john@jlc.net> wrote:

> Needless to say, having WG consensus on the sub= stance and letting the
> editor wordsmith the text is totally normal IETF process.

=C2=A0 =C2=A0In some cases, yes. IMHO, this is not one of them. YMMV...<= /u>

=C2=A0

Indeed it does, since I have *never* heard of such a= case where

the editor had no discretion to change the text in p= urely editorial

ways (subject to WG consensus of course). Feel free = to cite one

if you have one.

=C2=A0

=C2=A0

> I haven't heard anyone who was at HNL and i= n favor of the text on the
> slides object that Adam's text in the draft doesn't reflect th= ose
> slides.

=C2=A0 =C2=A0Probably you haven't...

=C2=A0

To the best of my knowledge it hasn't happened. = Can you cite anyone

who has so objected.

=C2=A0

=C2=A0


> Besides, Eric isn't the WGC calling consensus.
>
> No, the chairs did here:
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html
]
] From: Sean Turner <turners at ieca.com>
] At the 2nd RTCweb WG session @ IETF 91, we had a lively discussion
] about codecs, which I dubbed "the great codec compromise."
] The compromise text that was discussed appears in slides 12-14 at [4]
] (which is a slight editorial variation of the text proposed at [2]).
]
] This message serves to confirm the sense of the room.

=C2=A0 =C2=A0Actually, as I read this more carefully, that isn't a cons= ensus call.
Sean goes on to dismiss the objections he heard in the room:<= /p>

=C2=A0

He's addressing them. What exactly is the proble= m with this?

=C2=A0


] 3) Trigger:
] Objection: The "trigger" sentence [3] is all kinds of wrong bec= ause
] it's promising that the future IETF will update this specification. ] Response: Like any IETF proposal, an RFC that documents the current
] proposal can be changed through the consensus process at any other time.<= br>
=C2=A0 =C2=A0Sean is specifically saying the "trigger" should be = discussed
on-list.

=C2=A0

I don't read this this way at all, Rather he'= ;s saying that in the future we

can update the RFC. But yes, we can discuss the trig= ger on-list. Do you

have some substantive objection that wasn't rais= ed in HNL and/or

hasn't been discussed to death here?

=C2=A0

=C2=A0

] After the discussion, some clarifying questions ab= out the hums, and
] typing the hum questions on the screen, there was rough consensus in
] the room to add (aka "shove") the proposed text into
] draft-ietf-rtcweb-video. In keeping with IETF process, I am confirming ] this consensus call on the list.

=C2=A0 =C2=A0This _is_ calling for consensus.

=C2=A0 =C2=A0But Sean omitted saying _what_ text; and agreed that the exact= text
may not have been clear to those in the room.

=C2=A0

Huh? The "proposed text" that was discusse= d in HNL is on the slide and

that's what's being referred to here. Adam e= dited text which is substantially

the same into the draft.

=C2=A0

=C2=A0

=C2=A0

] If anyone has any other issues that they would lik= e to raise please do
] by December 19th.

=C2=A0 =C2=A0(And folks have been doing so.)

=C2=A0 =C2=A0I have asked on-list for the exact text before raising my issu= es,
since my issues relate to the text, not the choosing to have two MTIs.

=C2=A0

As I pointed out in my original message, that text i= s in Adam's draft.

=C2=A0

Again, it's totally procedurally regular to have= rough consensus on text in

the WG meeting and on the list and then have the edi= tor edit in substantively

the same text to the draft. If you think there is so= me respect in which those

two blocks of text are not in fact the same, please = point to it. Otherwise,

this is just dilatory.

=C2=A0

=C2=A0

> And this message clearly points to the slides a= bove.

=C2=A0 =C2=A0I don't find it helpful to attack the people who raise iss= ues. YMMV.

=C2=A0

=C2=A0 =C2=A0But what EKR thinks really doesn't = matter. He is not a WGC.

=C2=A0

Ironic that you would complain about "attack&qu= ot;s in a thread where you

started out by attacking Adam Roach and here say &qu= ot;what EKR thinks

really doesn't matter"

=C2=A0

-Ekr

--047d7bae493efe2541050a5acd2d-- From nobody Tue Dec 16 12:03:34 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C2F1A873E for ; Tue, 16 Dec 2014 12:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dp9OPshHKi1Y for ; Tue, 16 Dec 2014 12:03:30 -0800 (PST) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9B51A1B99 for ; Tue, 16 Dec 2014 12:03:30 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id l4so11401336lbv.39 for ; Tue, 16 Dec 2014 12:03:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sYtlie8igHAkUPIrhofRIPVRGOMOmdtPs/IqPAD87E0=; b=cmUfbVT7PIK4t+OUfRtc47W+6Kj3ov1QdOslp1hgpxgBn+8zOsnBk8o6PPDrqzry9x g8QjVY16JPzmzix+u2lZz3FI4ddIQ2b2mlG4fzQJ502OWG75oJvHmRc0VhGgY1KQkjZW dbhx81QJafSGKiQpZU4S4oJYVBLn511YkT1yi4FJypFf76ViAcJjQgGEYdb035gdRE9g YY+dpsyaNC6B6okHcdueFSW+jY0cbYJeSLKGYCpD5egbNn7B1j8PRit+A3WBQwD/PLgl wTGys+scDn1/mfQ/Z2xTWZpjTwWrYcKcPKBbPNSSla9KQJTuFd0crnEF5QTFAnusbAaV Tavw== X-Gm-Message-State: ALoCoQkxzgDaF2URoU62T9a43I2CwStRKSnPMkaAm9bkBTJw1xGNNtCq8QUNz7zr4kaWFUxmfn1t MIME-Version: 1.0 X-Received: by 10.112.170.36 with SMTP id aj4mr37224307lbc.3.1418760208672; Tue, 16 Dec 2014 12:03:28 -0800 (PST) Received: by 10.25.12.215 with HTTP; Tue, 16 Dec 2014 12:03:28 -0800 (PST) In-Reply-To: <54908A65.1010705@gmail.com> References: <54908A65.1010705@gmail.com> Date: Tue, 16 Dec 2014 15:03:28 -0500 Message-ID: From: Richard Barnes To: Daniel-Constantin Mierla Content-Type: multipart/alternative; boundary=001a11c261fc427fc1050a5ada98 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VXbEhVhiy20vEUSUH8k5JplvC-k Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] clarifications on current discussions - re: confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 20:03:32 -0000 --001a11c261fc427fc1050a5ada98 Content-Type: text/plain; charset=UTF-8 Hi Daniel, Thanks for the question. The goal of Sean's message is indeed to seek consensus on the codec question. The time for discussion is to allow for any other issues to be raised, beyond those that were raised in the room in Honolulu. At the end of the comment period on Friday, Sean will review the discussion and make a determination as to whether a rough consensus has been reached. --Richard On Tue, Dec 16, 2014 at 2:39 PM, Daniel-Constantin Mierla wrote: > > With many forks of the thread and various opinions, can anyone clarify > the expectation of these discussions. Ideally will be the WG chairs > stating what is the role of the current discussions, specially to the > initial thread with the subject 'confirming sense of the room: mti > codec' started by Sean Turner - link to archive: > > - http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html > > My understanding was that it is about clarifying what happened during > the sessions in Honolulu, not a call on consensus for the proposal. I > get the feeling that many understood it differently, being the call on > consensus for video MTI codecs. I saw many people simply stating there > position in replies to this thread, which is ok if they want to > say/reiterate it, but not addressing any of the points set for > discussion by Sean. > > For a call on consensus I would expect to be with a explicit subject, > including or pointing to the (draft of) text to be adopted. > > Which side got it wrong here? > > Thanks, > Daniel > > -- > Daniel-Constantin Mierla > http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c261fc427fc1050a5ada98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<hat type=3D"AD" subtype=3D"process-stew= ard"/>

Hi Daniel,

Thanks for the question.=C2=A0= The goal of Sean's message is indeed to seek consensus on the codec qu= estion.=C2=A0 The time for discussion is to allow for any other issues to b= e raised, beyond those that were raised in the room in Honolulu.=C2=A0 At t= he end of the comment period on Friday, Sean will review the discussion and= make a determination as to whether a rough consensus has been reached.
=
--Richard


On Tue, Dec 16, 2014 at 2:39 PM, Dani= el-Constantin Mierla <miconda@gmail.com> wrote:
With many forks of the thread and various opinions, can a= nyone clarify
the expectation of these discussions. Ideally will be the WG chairs
stating what is the role of the current discussions, specially to the
initial thread with the subject 'confirming sense of the room: mti
codec' started by Sean Turner - link to archive:

=C2=A0 =C2=A0- http://www.ietf.org/mail-archive/web/rt= cweb/current/msg13696.html

My understanding was that it is about clarifying what happened during
the sessions in Honolulu, not a call on consensus for the proposal. I
get the feeling that many understood it differently, being the call on
consensus for video MTI codecs. I saw many people simply stating there
position in replies to this thread, which is ok if they want to
say/reiterate it, but not addressing any of the points set for
discussion by Sean.

For a call on consensus I would expect to be with a explicit subject,
including or pointing to the (draft of) text to be adopted.

Which side got it wrong here?

Thanks,
Daniel

--
Daniel-Constantin Mierla
http://twitter.= com/#!/miconda - http://www.linkedin.com/in/miconda

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--001a11c261fc427fc1050a5ada98-- From nobody Tue Dec 16 12:10:05 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6570D1A873C for ; Tue, 16 Dec 2014 12:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UFXVSLKXhR8 for ; Tue, 16 Dec 2014 12:10:00 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1458E1A86E2 for ; Tue, 16 Dec 2014 12:10:00 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sBGK9rRB075313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2014 14:09:54 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54909198.7040409@nostrum.com> Date: Tue, 16 Dec 2014 14:10:00 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: David Singer , Harald Alvestrand References: <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <54905132.40105@alvestrand.no> <5B1166AB-A2EA-4F83-ABB2-8947D044B159@apple.com> In-Reply-To: <5B1166AB-A2EA-4F83-ABB2-8947D044B159@apple.com> Content-Type: multipart/alternative; boundary="------------000106030301060904030701" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/yY0sMB6UaDXdC5HcvwfJm9l4Opw Cc: rtcweb@ietf.org Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 20:10:02 -0000 This is a multi-part message in MIME format. --------------000106030301060904030701 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/16/14 13:33, David Singer wrote: > Except I can’t find the text “non-browser†in the referenced document. Huh. I see the following (cf. ): > o A WebRTC non-browser is something that conforms to the protocol > specification, but does not claim to implement the Javascript API. > This can also be called a "WebRTC device" or "WebRTC native > application". In terms of the text you cited about the relationship between terms, which is an outdated version of: > All WebRTC browsers are WebRTC endpoints, so any requirement on a > WebRTC endpoint also applies to a WebRTC browser. If you think you see somewhere that we're imposing a requirement on an endpoint that doesn't *also* apply to a browser, please call it out explicitly. If this is some oblique attempt to complain about the reference to the -12 version of the overview document [1] by pretending to be daft [2]: you're not fooling anyone, so you can stop it. You may be misguided, but we all know that you're not stupid. /a ____ [1] Rather than the -13 version that came out three days after *this* document [2] As you did with the "Brower" typo --------------000106030301060904030701 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/16/14 13:33, David Singer wrote:
Except I can’t find the text “non-browser†in the referenced document.

Huh. I see the following (cf. <https://tools.ietf.org/html/draft-ietf-rtcweb-overview-13#section-2.2>):

   o  A WebRTC non-browser is something that conforms to the protocol
      specification, but does not claim to implement the Javascript API.
      This can also be called a "WebRTC device" or "WebRTC native
      application".


In terms of the text you cited about the relationship between terms, which is an outdated version of:
   All WebRTC browsers are WebRTC endpoints, so any requirement on a
   WebRTC endpoint also applies to a WebRTC browser.

If you think you see somewhere that we're imposing a requirement on an endpoint that doesn't *also* apply to a browser, please call it out explicitly.

If this is some oblique attempt to complain about the reference to the -12 version of the overview document [1]  by pretending to be daft [2]: you're not fooling anyone, so you can stop it. You may be misguided, but we all know that you're not stupid.

/a

____
[1] Rather than the -13 version that came out three days after *this* document
[2] As you did with the "Brower" typo --------------000106030301060904030701-- From nobody Tue Dec 16 12:18:10 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9B01A877D for ; Tue, 16 Dec 2014 12:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9MF1h03y4pN for ; Tue, 16 Dec 2014 12:18:00 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1FF1A8757 for ; Tue, 16 Dec 2014 12:17:58 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-2d-54909374ad92 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8B.4B.24955.47390945; Tue, 16 Dec 2014 21:17:56 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 21:17:56 +0100 From: Christer Holmberg To: Adam Roach , David Singer , "Harald Alvestrand" Thread-Topic: [rtcweb] revisiting MTI Thread-Index: AQHQGUFjso9B1B7Olkyfz4ehEBRmYJySQOMAgAADoQCAAAP7AIAAQnmAgAAKSwCAABLBUA== Date: Tue, 16 Dec 2014 20:17:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5E8C5A@ESESSMB209.ericsson.se> References: <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <54905132.40105@alvestrand.no> <5B1166AB-A2EA-4F83-ABB2-8947D044B159@apple.com> <54909198.7040409@nostrum.com> In-Reply-To: <54909198.7040409@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D5E8C5AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM+JvjW7J5AkhBr+nSFvs+buI3eJYXxeb xdp/7ewW8/s/sjiweFyZcIXVY+vJH2weS5b8ZPKYtfMJSwBLFJdNSmpOZllqkb5dAlfG+p8N jAUvIit+LDvJ3MC4JryLkYNDQsBE4lCbZxcjJ5ApJnHh3nq2LkYuDiGBI4wSz/c3MkI4Sxgl buz7zgbSwCZgIdH9TxukQUSgQKLlxFkmEJtZQF3izuJz7CC2sICKxMNr75khalQl7ny4xQ5h h0ks/DENzGYBit++2A7WyyvgK7F/dR8zxK6VLBJXz61nAUlwCmhL7J7UDWYzAl33/dQaqGXi EreezGeCuFpAYsme88wQtqjEy8f/WCFsJYlFtz9D1edLXOt7wAixTFDi5MwnLBMYRWchGTUL SdksJGWzgF5mFtCUWL9LH6JEUWJK90N2CFtDonXOXHZk8QWM7KsYRYtTi5Ny042M9VKLMpOL i/Pz9PJSSzYxAqPy4JbfqjsYL79xPMQowMGoxMNrsKA/RIg1say4MvcQozQHi5I478Jz84KF BNITS1KzU1MLUovii0pzUosPMTJxcEo1MMYXbVoR8edM15taa6koz7CHEXc3Whw48SlB6e/E nPfbjzpv7Bdpee87qaCPO2DHuqn8rSHce1PTd56yT2dx/xWcdjmoujozSCubeVXroTnsJxeK f2CvuMfCeWd94cnIw26P9WfsNGqXPLBs32TWW87u8neUE7YGPP16asXv92EBqj0zBRbllCix FGckGmoxFxUnAgDXtmjbqwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MJK6ad99GwmiIRzj1ZgJSpokePs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 20:18:04 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D5E8C5AESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCg0KDQpUaGUgZGVjaXNpb24gdG8gdXNlIHRoYXQgdGVybWlub2xvZ3kgKGJyb3dzZXIs IG5vbi1icm93c2VyIGFuZCBjb21wbGlhbnQpIHdhcyBtYWRlIGR1cmluZyB0aGUgZmlyc3QgUlRD V0VCIHNlc3Npb24gYXQgdGhlIHNhbWUgSUVURiBtZWV0aW5nLCB3aGVuIEhhcmFsZCBwcmVzZW50 ZWQgdGhlIHN0YXR1cyBvZiB0aGUgb3ZlcnZpZXcgZHJhZnQuDQoNCg0KDQpJIGFzc3VtZSBIYXJh bGQgd2lsbCBpbXBsZW1lbnQgdGhhdCBkZWNpc2lvbiBpbnRvIHRoZSBuZXh0IHZlcnNpb24gb2Yg dGhlIG92ZXJ2aWV3IGRyYWZ0Lg0KDQoNCg0KUmVnYXJkcywNCg0KDQoNCkNocmlzdGVyDQoNCg0K RnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBBZGFtIFJvYWNoDQpTZW50OiAxNiBEZWNlbWJlciAyMDE0IDIyOjEwDQpUbzogRGF2aWQgU2lu Z2VyOyBIYXJhbGQgQWx2ZXN0cmFuZA0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtydGN3ZWJdIHJldmlzaXRpbmcgTVRJDQoNCk9uIDEyLzE2LzE0IDEzOjMzLCBEYXZpZCBTaW5n ZXIgd3JvdGU6DQoNCkV4Y2VwdCBJIGNhbuKAmXQgZmluZCB0aGUgdGV4dCDigJxub24tYnJvd3Nl cuKAnSBpbiB0aGUgcmVmZXJlbmNlZCBkb2N1bWVudC4NCg0KSHVoLiBJIHNlZSB0aGUgZm9sbG93 aW5nIChjZi4gPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1v dmVydmlldy0xMyNzZWN0aW9uLTIuMj48aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtcnRjd2ViLW92ZXJ2aWV3LTEzI3NlY3Rpb24tMi4yPik6DQoNCg0KDQogICBvICBBIFdl YlJUQyBub24tYnJvd3NlciBpcyBzb21ldGhpbmcgdGhhdCBjb25mb3JtcyB0byB0aGUgcHJvdG9j b2wNCg0KICAgICAgc3BlY2lmaWNhdGlvbiwgYnV0IGRvZXMgbm90IGNsYWltIHRvIGltcGxlbWVu dCB0aGUgSmF2YXNjcmlwdCBBUEkuDQoNCiAgICAgIFRoaXMgY2FuIGFsc28gYmUgY2FsbGVkIGEg IldlYlJUQyBkZXZpY2UiIG9yICJXZWJSVEMgbmF0aXZlDQoNCiAgICAgIGFwcGxpY2F0aW9uIi4N Cg0KDQpJbiB0ZXJtcyBvZiB0aGUgdGV4dCB5b3UgY2l0ZWQgYWJvdXQgdGhlIHJlbGF0aW9uc2hp cCBiZXR3ZWVuIHRlcm1zLCB3aGljaCBpcyBhbiBvdXRkYXRlZCB2ZXJzaW9uIG9mOg0KDQoNCiAg IEFsbCBXZWJSVEMgYnJvd3NlcnMgYXJlIFdlYlJUQyBlbmRwb2ludHMsIHNvIGFueSByZXF1aXJl bWVudCBvbiBhDQoNCiAgIFdlYlJUQyBlbmRwb2ludCBhbHNvIGFwcGxpZXMgdG8gYSBXZWJSVEMg YnJvd3Nlci4NCg0KSWYgeW91IHRoaW5rIHlvdSBzZWUgc29tZXdoZXJlIHRoYXQgd2UncmUgaW1w b3NpbmcgYSByZXF1aXJlbWVudCBvbiBhbiBlbmRwb2ludCB0aGF0IGRvZXNuJ3QgKmFsc28qIGFw cGx5IHRvIGEgYnJvd3NlciwgcGxlYXNlIGNhbGwgaXQgb3V0IGV4cGxpY2l0bHkuDQoNCklmIHRo aXMgaXMgc29tZSBvYmxpcXVlIGF0dGVtcHQgdG8gY29tcGxhaW4gYWJvdXQgdGhlIHJlZmVyZW5j ZSB0byB0aGUgLTEyIHZlcnNpb24gb2YgdGhlIG92ZXJ2aWV3IGRvY3VtZW50IFsxXSAgYnkgcHJl dGVuZGluZyB0byBiZSBkYWZ0IFsyXTogeW91J3JlIG5vdCBmb29saW5nIGFueW9uZSwgc28geW91 IGNhbiBzdG9wIGl0LiBZb3UgbWF5IGJlIG1pc2d1aWRlZCwgYnV0IHdlIGFsbCBrbm93IHRoYXQg eW91J3JlIG5vdCBzdHVwaWQuDQoNCi9hDQoNCl9fX18NClsxXSBSYXRoZXIgdGhhbiB0aGUgLTEz IHZlcnNpb24gdGhhdCBjYW1lIG91dCB0aHJlZSBkYXlzIGFmdGVyICp0aGlzKiBkb2N1bWVudA0K WzJdIEFzIHlvdSBkaWQgd2l0aCB0aGUgIkJyb3dlciIgdHlwbw0K --_000_7594FB04B1934943A5C02806D1A2204B1D5E8C5AESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRl eHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0 IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+SGksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBkZWNpc2lv biB0byB1c2UgdGhhdCB0ZXJtaW5vbG9neSAoYnJvd3Nlciwgbm9uLWJyb3dzZXIgYW5kIGNvbXBs aWFudCkgd2FzIG1hZGUgZHVyaW5nIHRoZSBmaXJzdCBSVENXRUIgc2Vzc2lvbiBhdCB0aGUgc2Ft ZSBJRVRGIG1lZXRpbmcsIHdoZW4gSGFyYWxkIHByZXNlbnRlZCB0aGUgc3RhdHVzIG9mIHRoZSBv dmVydmlldyBkcmFmdC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIGFzc3VtZSBI YXJhbGQgd2lsbCBpbXBsZW1lbnQgdGhhdCBkZWNpc2lvbiBpbnRvIHRoZSBuZXh0IHZlcnNpb24g b2YgdGhlIG92ZXJ2aWV3IGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SZWdh cmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5DaHJpc3RlcjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjp3aW5kb3d0ZXh0Ij4gcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFkYW0gUm9hY2g8YnI+DQo8Yj5TZW50OjwvYj4gMTYg RGVjZW1iZXIgMjAxNCAyMjoxMDxicj4NCjxiPlRvOjwvYj4gRGF2aWQgU2luZ2VyOyBIYXJhbGQg QWx2ZXN0cmFuZDxicj4NCjxiPkNjOjwvYj4gcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbcnRjd2ViXSByZXZpc2l0aW5nIE1USTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMi8xNi8xNCAxMzozMywgRGF2aWQg U2luZ2VyIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+RXhjZXB0IEkgY2Fu 4oCZdCBmaW5kIHRoZSB0ZXh0IOKAnG5vbi1icm93c2Vy4oCdIGluIHRoZSByZWZlcmVuY2VkIGRv Y3VtZW50LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQpIdWguIEkgc2VlIHRoZSBmb2xsb3dpbmcgKGNmLiA8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItb3ZlcnZpZXctMTMjc2VjdGlv bi0yLjIiPg0KJmx0O2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dl Yi1vdmVydmlldy0xMyNzZWN0aW9uLTIuMiZndDs8L2E+KTo8YnI+DQo8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHByZT4mbmJzcDsmbmJzcDsgbyZuYnNwOyBBIFdlYlJUQyBub24tYnJv d3NlciBpcyBzb21ldGhpbmcgdGhhdCBjb25mb3JtcyB0byB0aGUgcHJvdG9jb2w8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3BlY2lmaWNhdGlv biwgYnV0IGRvZXMgbm90IGNsYWltIHRvIGltcGxlbWVudCB0aGUgSmF2YXNjcmlwdCBBUEkuPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMg Y2FuIGFsc28gYmUgY2FsbGVkIGEgJnF1b3Q7V2ViUlRDIGRldmljZSZxdW90OyBvciAmcXVvdDtX ZWJSVEMgbmF0aXZlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGFwcGxpY2F0aW9uJnF1b3Q7LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVv dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpJbiB0ZXJtcyBvZiB0aGUgdGV4 dCB5b3UgY2l0ZWQgYWJvdXQgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRlcm1zLCB3aGljaCBp cyBhbiBvdXRkYXRlZCB2ZXJzaW9uIG9mOjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cHJlPiZuYnNwOyZuYnNwOyBBbGwgV2ViUlRDIGJyb3dzZXJzIGFyZSBXZWJSVEMgZW5kcG9pbnRz LCBzbyBhbnkgcmVxdWlyZW1lbnQgb24gYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBXZWJSVEMgZW5kcG9pbnQgYWxzbyBhcHBsaWVzIHRvIGEgV2ViUlRDIGJyb3dzZXIuPG86 cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N CklmIHlvdSB0aGluayB5b3Ugc2VlIHNvbWV3aGVyZSB0aGF0IHdlJ3JlIGltcG9zaW5nIGEgcmVx dWlyZW1lbnQgb24gYW4gZW5kcG9pbnQgdGhhdCBkb2Vzbid0ICphbHNvKiBhcHBseSB0byBhIGJy b3dzZXIsIHBsZWFzZSBjYWxsIGl0IG91dCBleHBsaWNpdGx5Ljxicj4NCjxicj4NCklmIHRoaXMg aXMgc29tZSBvYmxpcXVlIGF0dGVtcHQgdG8gY29tcGxhaW4gYWJvdXQgdGhlIHJlZmVyZW5jZSB0 byB0aGUgLTEyIHZlcnNpb24gb2YgdGhlIG92ZXJ2aWV3IGRvY3VtZW50IFsxXSZuYnNwOyBieSBw cmV0ZW5kaW5nIHRvIGJlIGRhZnQgWzJdOiB5b3UncmUgbm90IGZvb2xpbmcgYW55b25lLCBzbyB5 b3UgY2FuIHN0b3AgaXQuIFlvdSBtYXkgYmUgbWlzZ3VpZGVkLCBidXQgd2UgYWxsIGtub3cgdGhh dCB5b3UncmUgbm90IHN0dXBpZC48YnI+DQo8YnI+DQovYTxicj4NCjxicj4NCl9fX188YnI+DQpb MV0gUmF0aGVyIHRoYW4gdGhlIC0xMyB2ZXJzaW9uIHRoYXQgY2FtZSBvdXQgdGhyZWUgZGF5cyBh ZnRlciAqdGhpcyogZG9jdW1lbnQ8YnI+DQpbMl0gQXMgeW91IGRpZCB3aXRoIHRoZSAmcXVvdDtC cm93ZXImcXVvdDsgdHlwbyA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_7594FB04B1934943A5C02806D1A2204B1D5E8C5AESESSMB209erics_-- From nobody Tue Dec 16 12:18:55 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF871A8780 for ; Tue, 16 Dec 2014 12:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhEozpodXFNr for ; Tue, 16 Dec 2014 12:18:47 -0800 (PST) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CA71A8757 for ; Tue, 16 Dec 2014 12:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1418761119; x=2282674719; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZS5/ycpbAOqlMWcAeKTiZmJiLM3BFJm9Y6hqSw+ln+I=; b=Oyv1TovCeGXhlcVj76Sb/2FgnIDaWxv+zB9ielwA0c+m7Yioy65lTf82R+SMf2Nl YWTb0QRAolFXo0XHxDww+mC8u7U5b3LgHrY6P98M1qsHhjFDve+aNkN9Y4/H3eUC s91JU+fiVvGUZ3DOEQ/Zkr40nEc/5xc0KBCkmnXlXUWcLMhAwj5HmberU5deQLwZ 2nhekQjyjosaWBg4OGO2yh0blKfjrOw5GiBcY4RiXFyao+WkYU1n7Mgq0jj2/SrW xS9siXydj3/zlM4AA4I9wJ5kobmqF0VDeMDxLRXPyULxQ4mOF0HPcM7KVdPtGEcQ yJpzDOR0L4mbq2jjmwbr2w==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 85.CC.27006.F9390945; Tue, 16 Dec 2014 12:18:39 -0800 (PST) X-AuditID: 11973e15-f79f36d00000697e-0b-5490939f21f9 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id BA.69.05858.89390945; Tue, 16 Dec 2014 12:18:33 -0800 (PST) Received: from singda.apple.com (singda.apple.com [17.201.24.241]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NGO00NT6Z333R10@marigold.apple.com> for rtcweb@ietf.org; Tue, 16 Dec 2014 12:18:39 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: David Singer In-reply-to: <54909198.7040409@nostrum.com> Date: Tue, 16 Dec 2014 12:18:39 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <548F0E28.8040503@andyet.net> <20141215192409.GN47023@verdi> <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <54905132.40105@alvestrand.no> <5B1166AB-A2EA-4F83-ABB2-8947D044B159@apple.com> <54909198.7040409@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1993) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FDorDt/8oQQg/sbLS3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxu+TU1gLHvNWLN46i7mB8RNXFyMnh4SAicTGyXuYIWwxiQv3 1rN1MXJxCAnsZZT4Nf0NI0zR1NnrGSESk5gkmrdMYYVw5jNJHDnwgamLkYODWUBdYsqUXJAG XgE9iaYnj5lAbGEBFYn9u0+wg9hsAqoSD+YcAxvKKaAt8fX0X7AaFqD4mzmTweLMArYSe259 ZYOwtSWevLvACjHTRmJW92F2iL3LWSQurLgKViQioCjRdvgm1AuyEv8ungErkhD4yCpx9tJb 1gmMwrMQ7puF5L5ZSHYsYGRexSiUm5iZo5uZZ6aXWFCQk6qXnJ+7iREUyNPtRHcwnllldYhR gINRiYc3oLA/RIg1say4MvcQozQHi5I473tdoJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG u3sbNS44XNUUKvtg0NGbu8BFXfz8pK+HC7YkSLNMFrYz/hdhpW3oKZRy5ZbWpkBG3d3Z0jJJ oWu93zdffqZfFrf1XF6qTeOl/o4/7etkeuvd3r7f2614/eDsQD3BsldZC3YdeROlyWix/Nxl 088vzlyePD2qxfF6WrXHzah7j9dWnjfyjRRXYinOSDTUYi4qTgQAQVmr+0UCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcojtz8oQQgy2bmSzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxu+TU1gLHvNWLN46i7mB8RNXFyMnh4SAicTU2esZIWwxiQv3 1rN1MXJxCAlMYpJo3jKFFcKZzyRx5MAHpi5GDg5mAXWJKVNyQRp4BfQkmp48ZgKxhQVUJPbv PsEOYrMJqEo8mHMMbCingLbE19N/wWpYgOJv5kwGizML2ErsufWVDcLWlnjy7gIrxEwbiVnd h9kh9i5nkbiw4ipYkYiAokTb4ZvMEJfKSvy7eIZ9AqPALISTZiE5aRaSsQsYmVcxChSl5iRW GuklFhTkpOol5+duYgQHXqHzDsZjy6wOMQpwMCrx8AYU9ocIsSaWFVfmHmKU4GBWEuFlbpwQ IsSbklhZlVqUH19UmpNafIhRmoNFSZw3511jiJBAemJJanZqakFqEUyWiYNTqoGRn/nzG7aa vC2XbW5VrwhXlLdo/PiIQaix/csaKa4Lb8w01VJ4yxvcK8KLDu5Z9vVC2CX29eVMD2YYJH9z d79+9fL83VeFF71niU3k+bGr9swypZ6gCxatnyfNYFH9e8zPT6drB8/t8qlb+U68Kcr9OE1B gdX5eec8jbtViipKYt0mcxL3vbigxFKckWioxVxUnAgAWnocRDgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/p0sFuStx_enm60riWW-2319kr90 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 20:18:54 -0000 > On Dec 16, 2014, at 12:10 , Adam Roach wrote: >=20 > On 12/16/14 13:33, David Singer wrote: >> Except I can=E2=80=99t find the text =E2=80=9Cnon-browser=E2=80=9D in = the referenced document. >=20 > Huh. I see the following (cf. = ): Ah, the document linked to -12, which is different. I just followed the = links/references. >=20 >> o A WebRTC non-browser is something that conforms to the protocol >> specification, but does not claim to implement the Javascript = API. >> This can also be called a "WebRTC device" or "WebRTC native >> application". >>=20 >=20 >=20 > In terms of the text you cited about the relationship between terms, = which is an outdated version of: >> All WebRTC browsers are WebRTC endpoints, so any requirement on a >> WebRTC endpoint also applies to a WebRTC browser. >>=20 >=20 > If you think you see somewhere that we're imposing a requirement on an = endpoint that doesn't *also* apply to a browser, please call it out = explicitly. no, quite the reverse. If all browsers are also devices, then we only = need to state the requirements for browsers if they differ from devices, = and they don=E2=80=99t, do they? >=20 > If this is some oblique attempt to complain about the reference to the = -12 version of the overview document [1] by pretending to be daft [2]: = you're not fooling anyone, so you can stop it. You may be misguided, but = we all know that you're not stupid. seriously, I just (quickly) reviewed the text and references as cited as = being the ones people are asking for consensus on. David Singer Manager, Software Standards, Apple Inc. From nobody Tue Dec 16 12:26:37 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423021A8765 for ; Tue, 16 Dec 2014 12:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktcj_QT5Ga_h for ; Tue, 16 Dec 2014 12:26:33 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E556E1A8779 for ; Tue, 16 Dec 2014 12:26:13 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id h11so13542384wiw.1 for ; Tue, 16 Dec 2014 12:26:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=ktXFrtnv3uCW7noAbhxRNPBngRcYDXpvC2ziZXAKkHc=; b=M4eL7Pvc4qrQkWhzvqIY7BNcjUGrRohMIsulwXKUUX7W5fgtnn+J6EWsK7g3uHr2Ca YXnoYfpwTx9NlaMYcsbL1w+ApSIc5cpLZaMCVBZxWgAj5GEp87dDQYqZAgxtBfnynN9d 9WJUPKtSOBiV1+IDG45ww7zPSxUIZrO/4jfVhBSmXiNSvQVFX8f49XVjurCSKWBRtPc3 yaUaGLl1x836N/274KDDyw1KroohGt05XAaT0oiX17iv5YkOoW24h7yw2w+xccUAhOVp LnqNg05Cg44MnpzpJWtesjyU9OlmgkIgCAnJJCuX2GQheFpdsJEtvGvdx7Ow3gwbtC+Z naAg== X-Received: by 10.180.7.198 with SMTP id l6mr7952296wia.26.1418761572742; Tue, 16 Dec 2014 12:26:12 -0800 (PST) Received: from Saturns-MBP.fritz.box ([2a01:4f8:a0:638e::2]) by mx.google.com with ESMTPSA id kn5sm2354830wjb.48.2014.12.16.12.26.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Dec 2014 12:26:12 -0800 (PST) Message-ID: <54909562.7060504@gmail.com> Date: Tue, 16 Dec 2014 21:26:10 +0100 From: Daniel-Constantin Mierla User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Richard Barnes References: <54908A65.1010705@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000005000903050005060903" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/s6cGzONWlrviVAndd-JXzmJYs28 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] clarifications on current discussions - re: confirming sense of the room: mti codec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: miconda@gmail.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, 16 Dec 2014 20:26:35 -0000 This is a multi-part message in MIME format. --------------000005000903050005060903 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Richard, thanks for the clarification! IMO, the initial message content was not stating explicitly this is the goal and apparently it misled the expectation from some of us. Maybe it would be appropriate to have a fresh message sent by WG chairs/AD (or other IETF 'official' involved in the process) to say it explicitly by subject, just in case someone (else than me) didn't understand (from current discussions) that there is an ongoing call on consensus for video MTI codec. There are still three days left that can prevent negative reactions later. Daniel On 16/12/14 21:03, Richard Barnes wrote: > > > Hi Daniel, > > Thanks for the question. The goal of Sean's message is indeed to seek > consensus on the codec question. The time for discussion is to allow > for any other issues to be raised, beyond those that were raised in > the room in Honolulu. At the end of the comment period on Friday, > Sean will review the discussion and make a determination as to whether > a rough consensus has been reached. > > --Richard > > > On Tue, Dec 16, 2014 at 2:39 PM, Daniel-Constantin Mierla > > wrote: > > With many forks of the thread and various opinions, can anyone clarify > the expectation of these discussions. Ideally will be the WG chairs > stating what is the role of the current discussions, specially to the > initial thread with the subject 'confirming sense of the room: mti > codec' started by Sean Turner - link to archive: > > - http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html > > My understanding was that it is about clarifying what happened during > the sessions in Honolulu, not a call on consensus for the proposal. I > get the feeling that many understood it differently, being the call on > consensus for video MTI codecs. I saw many people simply stating there > position in replies to this thread, which is ok if they want to > say/reiterate it, but not addressing any of the points set for > discussion by Sean. > > For a call on consensus I would expect to be with a explicit subject, > including or pointing to the (draft of) text to be adopted. > > Which side got it wrong here? > > Thanks, > Daniel > > -- > Daniel-Constantin Mierla > http://twitter.com/#!/miconda - > http://www.linkedin.com/in/miconda > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda --------------000005000903050005060903 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Richard,

thanks for the clarification! IMO, the initial message content was not stating explicitly this is the goal and apparently it misled the expectation from some of us.

Maybe it would be appropriate to have a fresh message sent by WG chairs/AD (or other IETF 'official' involved in the process) to say it explicitly by subject, just in case someone (else than me) didn't understand (from current discussions) that there is an ongoing call on consensus for video MTI codec. There are still three days left that can prevent negative reactions later.

Daniel

On 16/12/14 21:03, Richard Barnes wrote:
<hat type="AD" subtype="process-steward"/>

Hi Daniel,

Thanks for the question.  The goal of Sean's message is indeed to seek consensus on the codec question.  The time for discussion is to allow for any other issues to be raised, beyond those that were raised in the room in Honolulu.  At the end of the comment period on Friday, Sean will review the discussion and make a determination as to whether a rough consensus has been reached.

--Richard


On Tue, Dec 16, 2014 at 2:39 PM, Daniel-Constantin Mierla <miconda@gmail.com> wrote:
With many forks of the thread and various opinions, can anyone clarify
the expectation of these discussions. Ideally will be the WG chairs
stating what is the role of the current discussions, specially to the
initial thread with the subject 'confirming sense of the room: mti
codec' started by Sean Turner - link to archive:

   - http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html

My understanding was that it is about clarifying what happened during
the sessions in Honolulu, not a call on consensus for the proposal. I
get the feeling that many understood it differently, being the call on
consensus for video MTI codecs. I saw many people simply stating there
position in replies to this thread, which is ok if they want to
say/reiterate it, but not addressing any of the points set for
discussion by Sean.

For a call on consensus I would expect to be with a explicit subject,
including or pointing to the (draft of) text to be adopted.

Which side got it wrong here?

Thanks,
Daniel

--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
--------------000005000903050005060903-- From nobody Tue Dec 16 12:35:54 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17EE21A8786 for ; Tue, 16 Dec 2014 12:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zUYNztPtim2 for ; Tue, 16 Dec 2014 12:35:42 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id B91B71A87BB for ; Tue, 16 Dec 2014 12:35:40 -0800 (PST) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 16 Dec 2014 15:35:09 -0500 Received: from XCT114CNC.rim.net (10.65.161.214) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.210.2; Tue, 16 Dec 2014 15:35:09 -0500 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT114CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Tue, 16 Dec 2014 15:35:08 -0500 From: Gaelle Martin-Cocher To: Eric Rescorla Thread-Topic: [rtcweb] revisiting MTI Thread-Index: AQHQGK9hz+EPVQM3202R+pzBLk6Ke5yRiFAAgAAEJwCAAAEZAIAAAMsAgAAFmwCAARFEgIAAAWIAgAADogCAAAQ5gIAADdEAgAAHm4D//9Il8IAAXAWA//+ur/CAAFdIAP//tSOw Date: Tue, 16 Dec 2014 20:35:08 +0000 Message-ID: <92D0D52F3A63344CA478CF12DB0648AADF363670@XMB111CNC.rim.net> References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> <92D0D52F3A63344CA478CF12DB0648AADF3634AA@XMB111CNC.rim.net> <92D0D52F3A63344CA478CF12DB0648AADF363549@XMB111CNC.rim.net> In-Reply-To: Accept-Language: fr-FR, en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: multipart/alternative; boundary="_000_92D0D52F3A63344CA478CF12DB0648AADF363670XMB111CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Z16Fu7O3tS6c38WyMpjTIXpHxZU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 20:35:48 -0000 --_000_92D0D52F3A63344CA478CF12DB0648AADF363670XMB111CNCrimnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dDQpTZW50OiBUdWVz ZGF5LCBEZWNlbWJlciAxNiwgMjAxNCAyOjU5IFBNDQpUbzogR2FlbGxlIE1hcnRpbi1Db2NoZXIN CkNjOiBKb2huIExlc2xpZTsgcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0g cmV2aXNpdGluZyBNVEkNCg0KDQoNCk9uIFR1ZSwgRGVjIDE2LCAyMDE0IGF0IDExOjU2IEFNLCBH YWVsbGUgTWFydGluLUNvY2hlciA8Z21hcnRpbmNvY2hlckBibGFja2JlcnJ5LmNvbTxtYWlsdG86 Z21hcnRpbmNvY2hlckBibGFja2JlcnJ5LmNvbT4+IHdyb3RlOg0KSSBhbSBub3Qgc3VyZSBvbiB3 aGF0IHlvdSBhcmUgYmFzaW5nIHlvdXIgb3Bpbmlvbi4NCg0KQXMgSSBzYWlkLCB0aGUgcHVycG9z ZSBvZiBhbiBNVEkgaXMgdG8gcHJvdmlkZSBiYXNpYyBpbnRlcm9wLg0KDQpUaGF0IHBvaW50IGlz IGNsZWFyIHRvIGFsbC4gIFNvcnJ5IEkgd2FzIHJlZmVycmluZyB0byDigJxJIHdvdWxkIG5vdCBp bWFnaW5lIHRoYXQgd2UNCndvdWxkIGRlZmluZSBhIG5ldyByZXF1aXJlZCBjb2RlYyB1bmxlc3Mg aXQgd2FzIG5vdCBqdXN0IHRlY2huaWNhbGx5DQpzdXBlcmlvciBidXQgYWxzbyBkZWZpbml0aXZl bHkgUkYgaW4gdGhlIHNlbnNlIGNvbnRlbXBsYXRlZCBieSBBZGFtJ3MNCnRleHQu4oCdDQpBbmQg SSBhbSBub3Qgc3VyZSB0aGF0IGhvbGRzIHRydWUuDQoNCldhaXRpbmcgZm9yIGFuIFJGIHRlY2hu aWNhbGx5IHN1cGVyaW9yIGNvZGVjIG1pZ2h0IG5vdCBiZSBwcmFnbWF0aWMgYW5kIGNhbiBpbmRl ZWQgcHJldmVudCBhbnkgZXZvbHV0aW9uIG9mIFdlYlJUQyBjb2RlYyBmb3IgYSBsb25nIHRpbWUu DQpEZXByZWNhdGluZyBNVEkgY2FuIGJlIGRvbmUgaW4gc3RlcHMgKGUuZy4gYmVjb21lIFNIT1VM RCwgdGhlbiBNQVkpDQoNCklmIHRoaXMgTVRJIHRleHQgcHJldmVudHMgY29kZWMgZXZvbHV0aW9u LCB0aGlzIGlzIGEgc2VyaW91cyBpc3N1ZS4NCg0KSXQgZG9lc24ndCBwcmV2ZW50IGNvZGVjIGV2 b2x1dGlvbi4gVGhhdCdzIHdoeSB3ZSBoYXZlIG5lZ290aWF0aW9uLiBCcm93c2Vycw0KYXJlIGZy ZWUgdG8gaW1wbGVtZW50IG5vbi1NVEkgY29kZWNzIGFuZCBJIHdvdWxkIGFudGljaXBhdGUgdGhh dCB0aGV5DQp3aWxsIGRvIHNvLg0KQW5kIG5vbi1icm93c2VyIGFzIHdlbGwsIGJ1dCB0aGUgc3Bl YyB3aWxsIGxldCB1cyBzdHVjayBmb3IgZXZlciB3aXRoIGxvdyBwZXJmb3JtaW5nIGNvZGVjLg0K DQpHYcOrbGxlDQoNCi1Fa3INCg0KDQoNCg0KDQpHYcOrbGxlDQoNCg0KRnJvbTogRXJpYyBSZXNj b3JsYSBbbWFpbHRvOmVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPl0NClNlbnQ6IFR1 ZXNkYXksIERlY2VtYmVyIDE2LCAyMDE0IDI6MzggUE0NClRvOiBHYWVsbGUgTWFydGluLUNvY2hl cg0KQ2M6IEpvaG4gTGVzbGllOyBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9y Zz4NCg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIHJldmlzaXRpbmcgTVRJDQoNCg0KDQpPbiBUdWUs IERlYyAxNiwgMjAxNCBhdCAxMTozMSBBTSwgR2FlbGxlIE1hcnRpbi1Db2NoZXIgPGdtYXJ0aW5j b2NoZXJAYmxhY2tiZXJyeS5jb208bWFpbHRvOmdtYXJ0aW5jb2NoZXJAYmxhY2tiZXJyeS5jb20+ PiB3cm90ZToNCkkgaGF2ZSBsaXR0bGUgY29uZmlkZW5jZSB0aGF0IHRoZSBjaG9pY2UgYmV0d2Vl biBIMjY1IGFuZCBWUDkgd2lsbCBiZSBlYXNpZXIgdGhhbiBpdCBpcyB0b2RheSBiZXR3ZWVuIFZQ OCBhbmQgSDI2NC4NCkFyZSB3ZSBnb2luZyB0byBtdWx0aXBseSBzaW1pbGFybHkgcGVyZm9ybWlu ZyBjb2RlY3MgIGdvaW5nIGZvcndhcmQgKGluIHRoZSBzcGVjIG9yIGluIHByYWN0aWNlKSBvciBi ZSBzdHVjayB3aXRoIG1hbmRhdG9yeSBsb3cgcGVyZm9ybWluZyBjb2RlY3MgYmVjYXVzZSB3ZSBj YW5ub3QgbWFrZSBiZXR0ZXIgZGVjaXNpb24/DQoNCkl0J3MgaW1wb3J0YW50IHRvIHJlbWVtYmVy IHRoYXQgdGhlIHJlcXVpcmVtZW50IGZvciBhbiBNVEkgY29kZWMNCmlzIHRvIGd1YXJhbnRlZSBi YXNpYyBpbnRlcm9wZXJhYmlsaXR5LiBJIHdvdWxkIG5vdCBpbWFnaW5lIHRoYXQgd2UNCndvdWxk IGRlZmluZSBhIG5ldyByZXF1aXJlZCBjb2RlYyB1bmxlc3MgaXQgd2FzIG5vdCBqdXN0IHRlY2hu aWNhbGx5DQpzdXBlcmlvciBidXQgYWxzbyBkZWZpbml0aXZlbHkgUkYgaW4gdGhlIHNlbnNlIGNv bnRlbXBsYXRlZCBieSBBZGFtJ3MNCnRleHQuDQoNCi1Fa3INCg0KDQoNClRpbWUgZnJhbWUgZm9y IEgyNjUgLyBWUDkgIGlzIHVwIHRvIHR3byB5ZWFycyBmcm9tIG5vdw0KQW5kIHBvc3NpYmx5IHRo ZSB0aW1lZnJhbWUgZm9yIEguMjY2L0RhbGFhIGlzIGZvdXIgeWVhcnMgZnJvbSBub3cNCg0KVGhp cyBpcyBvbmUgbW9yZSBkcmF3YmFjayBvZiB0aGUgcHJvcG9zZWQgdGV4dCBmb3IgTVRJLCBub3Qg b25seSBpdCBtdWx0aXBsaWVzIGVuY29kZXJzIGFuZCBkZWNvZGVycyB0byBiZSBzdXBwb3J0ZWQg YnV0ICBjYW4gcHJldmVudCB0aGUgZXZvbHV0aW9uIG9mIHdlYnJ0YyB0b3dhcmQgbW9yZSBhZHZh bmNlcyBjb2RlY3MuIChhc3N1bWluZyB3ZSB3aWxsIG5vdCByZXF1aXJlIDQgb3IgNiBlbmNvZGVy cyBhbmQgNCBvciA2IGRlY29kZXJzIHRvIGJlIHN1cHBvcnRlZCBieSBldmVyeSBzaW5nbGUgZW5k cG9pbnRzLiBUd28gTVRJIHNlZW1zIGxhcmdlbHkgZW5vdWdoLCBubz8pLg0KDQpHYcOrbGxlDQoN CkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50OiBU dWVzZGF5LCBEZWNlbWJlciAxNiwgMjAxNCAxMTo1MyBBTQ0KVG86IEpvaG4gTGVzbGllDQpDYzog cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0 Y3dlYl0gcmV2aXNpdGluZyBNVEkNCg0KT24gVHVlLCBEZWMgMTYsIDIwMTQgYXQgODoyNSBBTSwg Sm9obiBMZXNsaWUgPGpvaG5AamxjLm5ldDxtYWlsdG86am9obkBqbGMubmV0Pj4gd3JvdGU6DQpF cmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0K PiBPbiBUdWUsIERlYyAxNiwgMjAxNCBhdCA3OjIxIEFNLCBKb2huIExlc2xpZSA8am9obkBqbGMu bmV0PG1haWx0bzpqb2huQGpsYy5uZXQ+PiB3cm90ZToNCj4gTmVlZGxlc3MgdG8gc2F5LCBoYXZp bmcgV0cgY29uc2Vuc3VzIG9uIHRoZSBzdWJzdGFuY2UgYW5kIGxldHRpbmcgdGhlDQo+IGVkaXRv ciB3b3Jkc21pdGggdGhlIHRleHQgaXMgdG90YWxseSBub3JtYWwgSUVURiBwcm9jZXNzLg0KDQog ICBJbiBzb21lIGNhc2VzLCB5ZXMuIElNSE8sIHRoaXMgaXMgbm90IG9uZSBvZiB0aGVtLiBZTU1W Li4uDQoNCkluZGVlZCBpdCBkb2VzLCBzaW5jZSBJIGhhdmUgKm5ldmVyKiBoZWFyZCBvZiBzdWNo IGEgY2FzZSB3aGVyZQ0KdGhlIGVkaXRvciBoYWQgbm8gZGlzY3JldGlvbiB0byBjaGFuZ2UgdGhl IHRleHQgaW4gcHVyZWx5IGVkaXRvcmlhbA0Kd2F5cyAoc3ViamVjdCB0byBXRyBjb25zZW5zdXMg b2YgY291cnNlKS4gRmVlbCBmcmVlIHRvIGNpdGUgb25lDQppZiB5b3UgaGF2ZSBvbmUuDQoNCg0K PiBJIGhhdmVuJ3QgaGVhcmQgYW55b25lIHdobyB3YXMgYXQgSE5MIGFuZCBpbiBmYXZvciBvZiB0 aGUgdGV4dCBvbiB0aGUNCj4gc2xpZGVzIG9iamVjdCB0aGF0IEFkYW0ncyB0ZXh0IGluIHRoZSBk cmFmdCBkb2Vzbid0IHJlZmxlY3QgdGhvc2UNCj4gc2xpZGVzLg0KDQogICBQcm9iYWJseSB5b3Ug aGF2ZW4ndC4uLg0KDQpUbyB0aGUgYmVzdCBvZiBteSBrbm93bGVkZ2UgaXQgaGFzbid0IGhhcHBl bmVkLiBDYW4geW91IGNpdGUgYW55b25lDQp3aG8gaGFzIHNvIG9iamVjdGVkLg0KDQoNCg0KPiBC ZXNpZGVzLCBFcmljIGlzbid0IHRoZSBXR0MgY2FsbGluZyBjb25zZW5zdXMuDQo+DQo+IE5vLCB0 aGUgY2hhaXJzIGRpZCBoZXJlOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvcnRjd2ViL2N1cnJlbnQvbXNnMTM2OTYuaHRtbA0KXQ0KXSBGcm9tOiBTZWFuIFR1cm5lciA8 dHVybmVycyBhdCBpZWNhLmNvbTxodHRwOi8vaWVjYS5jb20+Pg0KXSBBdCB0aGUgMm5kIFJUQ3dl YiBXRyBzZXNzaW9uIEAgSUVURiA5MSwgd2UgaGFkIGEgbGl2ZWx5IGRpc2N1c3Npb24NCl0gYWJv dXQgY29kZWNzLCB3aGljaCBJIGR1YmJlZCAidGhlIGdyZWF0IGNvZGVjIGNvbXByb21pc2UuIg0K XSBUaGUgY29tcHJvbWlzZSB0ZXh0IHRoYXQgd2FzIGRpc2N1c3NlZCBhcHBlYXJzIGluIHNsaWRl cyAxMi0xNCBhdCBbNF0NCl0gKHdoaWNoIGlzIGEgc2xpZ2h0IGVkaXRvcmlhbCB2YXJpYXRpb24g b2YgdGhlIHRleHQgcHJvcG9zZWQgYXQgWzJdKS4NCl0NCl0gVGhpcyBtZXNzYWdlIHNlcnZlcyB0 byBjb25maXJtIHRoZSBzZW5zZSBvZiB0aGUgcm9vbS4NCg0KICAgQWN0dWFsbHksIGFzIEkgcmVh ZCB0aGlzIG1vcmUgY2FyZWZ1bGx5LCB0aGF0IGlzbid0IGEgY29uc2Vuc3VzIGNhbGwuDQpTZWFu IGdvZXMgb24gdG8gZGlzbWlzcyB0aGUgb2JqZWN0aW9ucyBoZSBoZWFyZCBpbiB0aGUgcm9vbToN Cg0KSGUncyBhZGRyZXNzaW5nIHRoZW0uIFdoYXQgZXhhY3RseSBpcyB0aGUgcHJvYmxlbSB3aXRo IHRoaXM/DQoNCg0KXSAzKSBUcmlnZ2VyOg0KXSBPYmplY3Rpb246IFRoZSAidHJpZ2dlciIgc2Vu dGVuY2UgWzNdIGlzIGFsbCBraW5kcyBvZiB3cm9uZyBiZWNhdXNlDQpdIGl0J3MgcHJvbWlzaW5n IHRoYXQgdGhlIGZ1dHVyZSBJRVRGIHdpbGwgdXBkYXRlIHRoaXMgc3BlY2lmaWNhdGlvbi4NCl0g UmVzcG9uc2U6IExpa2UgYW55IElFVEYgcHJvcG9zYWwsIGFuIFJGQyB0aGF0IGRvY3VtZW50cyB0 aGUgY3VycmVudA0KXSBwcm9wb3NhbCBjYW4gYmUgY2hhbmdlZCB0aHJvdWdoIHRoZSBjb25zZW5z dXMgcHJvY2VzcyBhdCBhbnkgb3RoZXIgdGltZS4NCg0KICAgU2VhbiBpcyBzcGVjaWZpY2FsbHkg c2F5aW5nIHRoZSAidHJpZ2dlciIgc2hvdWxkIGJlIGRpc2N1c3NlZA0Kb24tbGlzdC4NCg0KSSBk b24ndCByZWFkIHRoaXMgdGhpcyB3YXkgYXQgYWxsLCBSYXRoZXIgaGUncyBzYXlpbmcgdGhhdCBp biB0aGUgZnV0dXJlIHdlDQpjYW4gdXBkYXRlIHRoZSBSRkMuIEJ1dCB5ZXMsIHdlIGNhbiBkaXNj dXNzIHRoZSB0cmlnZ2VyIG9uLWxpc3QuIERvIHlvdQ0KaGF2ZSBzb21lIHN1YnN0YW50aXZlIG9i amVjdGlvbiB0aGF0IHdhc24ndCByYWlzZWQgaW4gSE5MIGFuZC9vcg0KaGFzbid0IGJlZW4gZGlz Y3Vzc2VkIHRvIGRlYXRoIGhlcmU/DQoNCg0KXSBBZnRlciB0aGUgZGlzY3Vzc2lvbiwgc29tZSBj bGFyaWZ5aW5nIHF1ZXN0aW9ucyBhYm91dCB0aGUgaHVtcywgYW5kDQpdIHR5cGluZyB0aGUgaHVt IHF1ZXN0aW9ucyBvbiB0aGUgc2NyZWVuLCB0aGVyZSB3YXMgcm91Z2ggY29uc2Vuc3VzIGluDQpd IHRoZSByb29tIHRvIGFkZCAoYWthICJzaG92ZSIpIHRoZSBwcm9wb3NlZCB0ZXh0IGludG8NCl0g ZHJhZnQtaWV0Zi1ydGN3ZWItdmlkZW8uIEluIGtlZXBpbmcgd2l0aCBJRVRGIHByb2Nlc3MsIEkg YW0gY29uZmlybWluZw0KXSB0aGlzIGNvbnNlbnN1cyBjYWxsIG9uIHRoZSBsaXN0Lg0KDQogICBU aGlzIF9pc18gY2FsbGluZyBmb3IgY29uc2Vuc3VzLg0KDQogICBCdXQgU2VhbiBvbWl0dGVkIHNh eWluZyBfd2hhdF8gdGV4dDsgYW5kIGFncmVlZCB0aGF0IHRoZSBleGFjdCB0ZXh0DQptYXkgbm90 IGhhdmUgYmVlbiBjbGVhciB0byB0aG9zZSBpbiB0aGUgcm9vbS4NCg0KSHVoPyBUaGUgInByb3Bv c2VkIHRleHQiIHRoYXQgd2FzIGRpc2N1c3NlZCBpbiBITkwgaXMgb24gdGhlIHNsaWRlIGFuZA0K dGhhdCdzIHdoYXQncyBiZWluZyByZWZlcnJlZCB0byBoZXJlLiBBZGFtIGVkaXRlZCB0ZXh0IHdo aWNoIGlzIHN1YnN0YW50aWFsbHkNCnRoZSBzYW1lIGludG8gdGhlIGRyYWZ0Lg0KDQoNCg0KXSBJ ZiBhbnlvbmUgaGFzIGFueSBvdGhlciBpc3N1ZXMgdGhhdCB0aGV5IHdvdWxkIGxpa2UgdG8gcmFp c2UgcGxlYXNlIGRvDQpdIGJ5IERlY2VtYmVyIDE5dGguDQoNCiAgIChBbmQgZm9sa3MgaGF2ZSBi ZWVuIGRvaW5nIHNvLikNCg0KICAgSSBoYXZlIGFza2VkIG9uLWxpc3QgZm9yIHRoZSBleGFjdCB0 ZXh0IGJlZm9yZSByYWlzaW5nIG15IGlzc3VlcywNCnNpbmNlIG15IGlzc3VlcyByZWxhdGUgdG8g dGhlIHRleHQsIG5vdCB0aGUgY2hvb3NpbmcgdG8gaGF2ZSB0d28gTVRJcy4NCg0KQXMgSSBwb2lu dGVkIG91dCBpbiBteSBvcmlnaW5hbCBtZXNzYWdlLCB0aGF0IHRleHQgaXMgaW4gQWRhbSdzIGRy YWZ0Lg0KDQpBZ2FpbiwgaXQncyB0b3RhbGx5IHByb2NlZHVyYWxseSByZWd1bGFyIHRvIGhhdmUg cm91Z2ggY29uc2Vuc3VzIG9uIHRleHQgaW4NCnRoZSBXRyBtZWV0aW5nIGFuZCBvbiB0aGUgbGlz dCBhbmQgdGhlbiBoYXZlIHRoZSBlZGl0b3IgZWRpdCBpbiBzdWJzdGFudGl2ZWx5DQp0aGUgc2Ft ZSB0ZXh0IHRvIHRoZSBkcmFmdC4gSWYgeW91IHRoaW5rIHRoZXJlIGlzIHNvbWUgcmVzcGVjdCBp biB3aGljaCB0aG9zZQ0KdHdvIGJsb2NrcyBvZiB0ZXh0IGFyZSBub3QgaW4gZmFjdCB0aGUgc2Ft ZSwgcGxlYXNlIHBvaW50IHRvIGl0LiBPdGhlcndpc2UsDQp0aGlzIGlzIGp1c3QgZGlsYXRvcnku DQoNCg0KPiBBbmQgdGhpcyBtZXNzYWdlIGNsZWFybHkgcG9pbnRzIHRvIHRoZSBzbGlkZXMgYWJv dmUuDQoNCiAgIEkgZG9uJ3QgZmluZCBpdCBoZWxwZnVsIHRvIGF0dGFjayB0aGUgcGVvcGxlIHdo byByYWlzZSBpc3N1ZXMuIFlNTVYuDQoNCiAgIEJ1dCB3aGF0IEVLUiB0aGlua3MgcmVhbGx5IGRv ZXNuJ3QgbWF0dGVyLiBIZSBpcyBub3QgYSBXR0MuDQoNCklyb25pYyB0aGF0IHlvdSB3b3VsZCBj b21wbGFpbiBhYm91dCAiYXR0YWNrInMgaW4gYSB0aHJlYWQgd2hlcmUgeW91DQpzdGFydGVkIG91 dCBieSBhdHRhY2tpbmcgQWRhbSBSb2FjaCBhbmQgaGVyZSBzYXkgIndoYXQgRUtSIHRoaW5rcw0K cmVhbGx5IGRvZXNuJ3QgbWF0dGVyIg0KDQotRWtyDQo= --_000_92D0D52F3A63344CA478CF12DB0648AADF363670XMB111CNCrimnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44 NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21d DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRGVjZW1iZXIgMTYsIDIwMTQgMjo1OSBQTTxi cj4NCjxiPlRvOjwvYj4gR2FlbGxlIE1hcnRpbi1Db2NoZXI8YnI+DQo8Yj5DYzo8L2I+IEpvaG4g TGVzbGllOyBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJd IHJldmlzaXRpbmcgTVRJPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBEZWMgMTYs IDIwMTQgYXQgMTE6NTYgQU0sIEdhZWxsZSBNYXJ0aW4tQ29jaGVyICZsdDs8YSBocmVmPSJtYWls dG86Z21hcnRpbmNvY2hlckBibGFja2JlcnJ5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdtYXJ0aW5j b2NoZXJAYmxhY2tiZXJyeS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SSBhbSBub3Qgc3VyZSBvbiB3aGF0IHlvdSBhcmUgYmFzaW5nIHlv dXIgb3Bpbmlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgSSBzYWlkLCB0aGUgcHVycG9zZSBvZiBhbiBNVEkg aXMgdG8gcHJvdmlkZSBiYXNpYyBpbnRlcm9wLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGF0IHBvaW50IGlzIGNsZWFyIHRvIGFs bC4mbmJzcDsgU29ycnkgSSB3YXMgcmVmZXJyaW5nIHRvIOKAnDwvc3Bhbj5JIHdvdWxkIG5vdCBp bWFnaW5lIHRoYXQgd2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndvdWxk IGRlZmluZSBhIG5ldyByZXF1aXJlZCBjb2RlYyB1bmxlc3MgaXQgd2FzIG5vdCBqdXN0IHRlY2hu aWNhbGx5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zdXBlcmlvciBidXQg YWxzbyBkZWZpbml0aXZlbHkgUkYgaW4gdGhlIHNlbnNlIGNvbnRlbXBsYXRlZCBieSBBZGFtJ3M8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRleHQu4oCdPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+QW5kIEkgYW0gbm90IHN1cmUgdGhhdCBob2xkcyB0cnVlLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5XYWl0aW5nIGZvciBhbiBSRiB0ZWNobmljYWxseSBzdXBlcmlvciBjb2RlYyBtaWdodCBub3Qg YmUgcHJhZ21hdGljIGFuZCBjYW4gaW5kZWVkIHByZXZlbnQgYW55IGV2b2x1dGlvbg0KIG9mIFdl YlJUQyBjb2RlYyBmb3IgYSBsb25nIHRpbWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+RGVwcmVjYXRpbmcgTVRJIGNhbiBiZSBkb25lIGluIHN0ZXBzIChlLmcuIGJlY29tZSBTSE9V TEQsIHRoZW4gTUFZKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHRoaXMgTVRJIHRleHQgcHJldmVudHMgY29k ZWMgZXZvbHV0aW9uLCB0aGlzIGlzIGEgc2VyaW91cyBpc3N1ZS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SXQgZG9lc24ndCBwcmV2ZW50IGNvZGVjIGV2b2x1dGlvbi4gVGhhdCdzIHdoeSB3 ZSBoYXZlIG5lZ290aWF0aW9uLiBCcm93c2VyczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YXJlIGZyZWUgdG8gaW1wbGVtZW50IG5vbi1NVEkgY29k ZWNzIGFuZCBJIHdvdWxkIGFudGljaXBhdGUgdGhhdCB0aGV5PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53aWxsIGRvIHNvLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkFuZCBub24tYnJvd3NlciBhcyB3ZWxsLCBidXQgdGhlIHNwZWMgd2lsbCBsZXQg dXMgc3R1Y2sgZm9yIGV2ZXIgd2l0aCBsb3cgcGVyZm9ybWluZyBjb2RlYy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkdh w6tsbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+R2HDq2xsZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEVyaWMgUmVzY29ybGEg W21haWx0bzo8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWty QHJ0Zm0uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBEZWNlbWJlciAxNiwg MjAxNCAyOjM4IFBNPGJyPg0KPGI+VG86PC9iPiBHYWVsbGUgTWFydGluLUNvY2hlcjxicj4NCjxi PkNjOjwvYj4gSm9obiBMZXNsaWU7IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtydGN3ZWJdIHJldmlzaXRpbmcgTVRJPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgRGVjIDE2LCAyMDE0IGF0IDExOjMx IEFNLCBHYWVsbGUgTWFydGluLUNvY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdtYXJ0aW5jb2No ZXJAYmxhY2tiZXJyeS5jb20iIHRhcmdldD0iX2JsYW5rIj5nbWFydGluY29jaGVyQGJsYWNrYmVy cnkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkkgaGF2ZSBsaXR0bGUgY29uZmlkZW5jZSB0aGF0IHRoZSBjaG9pY2UgYmV0d2VlbiBIMjY1 IGFuZCBWUDkgd2lsbCBiZSBlYXNpZXIgdGhhbiBpdCBpcyB0b2RheSBiZXR3ZWVuDQogVlA4IGFu ZCBIMjY0LiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcmUgd2UgZ29pbmcgdG8g bXVsdGlwbHkgc2ltaWxhcmx5IHBlcmZvcm1pbmcgY29kZWNzICZuYnNwO2dvaW5nIGZvcndhcmQg KGluIHRoZSBzcGVjIG9yIGluIHByYWN0aWNlKQ0KIG9yIGJlIHN0dWNrIHdpdGggbWFuZGF0b3J5 IGxvdyBwZXJmb3JtaW5nIGNvZGVjcyBiZWNhdXNlIHdlIGNhbm5vdCBtYWtlIGJldHRlciBkZWNp c2lvbj88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0J3MgaW1wb3J0YW50IHRvIHJlbWVtYmVyIHRoYXQgdGhl IHJlcXVpcmVtZW50IGZvciBhbiBNVEkgY29kZWM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+aXMgdG8gZ3VhcmFudGVlIGJhc2ljIGludGVyb3Bl cmFiaWxpdHkuIEkgd291bGQgbm90IGltYWdpbmUgdGhhdCB3ZTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj53b3VsZCBkZWZpbmUgYSBuZXcgcmVx dWlyZWQgY29kZWMgdW5sZXNzIGl0IHdhcyBub3QganVzdCB0ZWNobmljYWxseTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5zdXBlcmlvciBidXQg YWxzbyBkZWZpbml0aXZlbHkgUkYgaW4gdGhlIHNlbnNlIGNvbnRlbXBsYXRlZCBieSBBZGFtJ3M8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dGV4 dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRpbWUgZnJhbWUgZm9yIEgyNjUgLyBWUDkgJm5ic3A7aXMgdXAgdG8gdHdvIHllYXJzIGZy b20gbm93DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbmQgcG9zc2libHkgdGhl IHRpbWVmcmFtZSBmb3IgSC4yNjYvRGFsYWEgaXMgZm91ciB5ZWFycyBmcm9tIG5vdzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlRoaXMgaXMgb25lIG1vcmUgZHJhd2JhY2sgb2YgdGhlIHByb3Bvc2VkIHRleHQgZm9y IE1USSwgbm90IG9ubHkgaXQgbXVsdGlwbGllcyBlbmNvZGVycyBhbmQgZGVjb2RlcnMNCiB0byBi ZSBzdXBwb3J0ZWQgYnV0ICZuYnNwO2NhbiBwcmV2ZW50IHRoZSBldm9sdXRpb24gb2Ygd2VicnRj IHRvd2FyZCBtb3JlIGFkdmFuY2VzIGNvZGVjcy4gKGFzc3VtaW5nIHdlIHdpbGwgbm90IHJlcXVp cmUgNCBvciA2IGVuY29kZXJzIGFuZCA0IG9yIDYgZGVjb2RlcnMgdG8gYmUgc3VwcG9ydGVkIGJ5 IGV2ZXJ5IHNpbmdsZSBlbmRwb2ludHMuIFR3byBNVEkgc2VlbXMgbGFyZ2VseSBlbm91Z2gsIG5v PykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+R2HDq2xsZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IHJ0Y3dlYiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9h Pl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpYyBSZXNjb3JsYTxicj4NCjxiPlNlbnQ6PC9iPiBU dWVzZGF5LCBEZWNlbWJlciAxNiwgMjAxNCAxMTo1MyBBTTxicj4NCjxiPlRvOjwvYj4gSm9obiBM ZXNsaWU8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbcnRjd2ViXSByZXZpc2l0aW5nIE1USTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgRGVjIDE2LCAyMDE0IGF0IDg6MjUgQU0s IEpvaG4gTGVzbGllICZsdDs8YSBocmVmPSJtYWlsdG86am9obkBqbGMubmV0IiB0YXJnZXQ9Il9i bGFuayI+am9obkBqbGMubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxicj4NCiZndDsgT24gVHVlLCBEZWMgMTYsIDIwMTQgYXQgNzoyMSBBTSwgSm9obiBM ZXNsaWUgJmx0OzxhIGhyZWY9Im1haWx0bzpqb2huQGpsYy5uZXQiIHRhcmdldD0iX2JsYW5rIj5q b2huQGpsYy5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mZ3Q7IE5lZWRsZXNzIHRvIHNheSwgaGF2aW5nIFdHIGNvbnNlbnN1cyBvbiB0aGUgc3Vic3Rh bmNlIGFuZCBsZXR0aW5nIHRoZTxicj4NCiZndDsgZWRpdG9yIHdvcmRzbWl0aCB0aGUgdGV4dCBp cyB0b3RhbGx5IG5vcm1hbCBJRVRGIHByb2Nlc3MuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO0lu IHNvbWUgY2FzZXMsIHllcy4gSU1ITywgdGhpcyBpcyBub3Qgb25lIG9mIHRoZW0uIFlNTVYuLi48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5JbmRlZWQgaXQgZG9lcywgc2luY2UgSSBoYXZlICpuZXZlciogaGVhcmQgb2Ygc3Vj aCBhIGNhc2Ugd2hlcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+dGhlIGVkaXRvciBoYWQgbm8gZGlzY3JldGlvbiB0byBjaGFuZ2UgdGhlIHRl eHQgaW4gcHVyZWx5IGVkaXRvcmlhbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj53YXlzIChzdWJqZWN0IHRvIFdHIGNvbnNlbnN1cyBvZiBjb3Vy c2UpLiBGZWVsIGZyZWUgdG8gY2l0ZSBvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+aWYgeW91IGhhdmUgb25lLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7IEkgaGF2ZW4ndCBoZWFyZCBhbnlv bmUgd2hvIHdhcyBhdCBITkwgYW5kIGluIGZhdm9yIG9mIHRoZSB0ZXh0IG9uIHRoZTxicj4NCiZn dDsgc2xpZGVzIG9iamVjdCB0aGF0IEFkYW0ncyB0ZXh0IGluIHRoZSBkcmFmdCBkb2Vzbid0IHJl ZmxlY3QgdGhvc2U8YnI+DQomZ3Q7IHNsaWRlcy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7UHJv YmFibHkgeW91IGhhdmVuJ3QuLi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UbyB0aGUgYmVzdCBvZiBteSBrbm93bGVkZ2Ug aXQgaGFzbid0IGhhcHBlbmVkLiBDYW4geW91IGNpdGUgYW55b25lPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPndobyBoYXMgc28gb2JqZWN0ZWQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCiZn dDsgQmVzaWRlcywgRXJpYyBpc24ndCB0aGUgV0dDIGNhbGxpbmcgY29uc2Vuc3VzLjxicj4NCiZn dDs8YnI+DQomZ3Q7IE5vLCB0aGUgY2hhaXJzIGRpZCBoZXJlOjxicj4NCiZndDsgPGEgaHJlZj0i aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50L21zZzEz Njk2Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9ydGN3ZWIvY3VycmVudC9tc2cxMzY5Ni5odG1sPC9hPjxicj4NCl08YnI+DQpdIEZy b206IFNlYW4gVHVybmVyICZsdDt0dXJuZXJzIGF0IDxhIGhyZWY9Imh0dHA6Ly9pZWNhLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmllY2EuY29tPC9hPiZndDs8YnI+DQpdIEF0IHRoZSAybmQgUlRDd2Vi IFdHIHNlc3Npb24gQCBJRVRGIDkxLCB3ZSBoYWQgYSBsaXZlbHkgZGlzY3Vzc2lvbjxicj4NCl0g YWJvdXQgY29kZWNzLCB3aGljaCBJIGR1YmJlZCAmcXVvdDt0aGUgZ3JlYXQgY29kZWMgY29tcHJv bWlzZS4mcXVvdDs8YnI+DQpdIFRoZSBjb21wcm9taXNlIHRleHQgdGhhdCB3YXMgZGlzY3Vzc2Vk IGFwcGVhcnMgaW4gc2xpZGVzIDEyLTE0IGF0IFs0XTxicj4NCl0gKHdoaWNoIGlzIGEgc2xpZ2h0 IGVkaXRvcmlhbCB2YXJpYXRpb24gb2YgdGhlIHRleHQgcHJvcG9zZWQgYXQgWzJdKS48YnI+DQpd PGJyPg0KXSBUaGlzIG1lc3NhZ2Ugc2VydmVzIHRvIGNvbmZpcm0gdGhlIHNlbnNlIG9mIHRoZSBy b29tLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtBY3R1YWxseSwgYXMgSSByZWFkIHRoaXMgbW9y ZSBjYXJlZnVsbHksIHRoYXQgaXNuJ3QgYSBjb25zZW5zdXMgY2FsbC48YnI+DQpTZWFuIGdvZXMg b24gdG8gZGlzbWlzcyB0aGUgb2JqZWN0aW9ucyBoZSBoZWFyZCBpbiB0aGUgcm9vbTo8bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5IZSdzIGFkZHJlc3NpbmcgdGhlbS4gV2hhdCBleGFjdGx5IGlzIHRoZSBwcm9ibGVtIHdpdGgg dGhpcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpd IDMpIFRyaWdnZXI6PGJyPg0KXSBPYmplY3Rpb246IFRoZSAmcXVvdDt0cmlnZ2VyJnF1b3Q7IHNl bnRlbmNlIFszXSBpcyBhbGwga2luZHMgb2Ygd3JvbmcgYmVjYXVzZTxicj4NCl0gaXQncyBwcm9t aXNpbmcgdGhhdCB0aGUgZnV0dXJlIElFVEYgd2lsbCB1cGRhdGUgdGhpcyBzcGVjaWZpY2F0aW9u Ljxicj4NCl0gUmVzcG9uc2U6IExpa2UgYW55IElFVEYgcHJvcG9zYWwsIGFuIFJGQyB0aGF0IGRv Y3VtZW50cyB0aGUgY3VycmVudDxicj4NCl0gcHJvcG9zYWwgY2FuIGJlIGNoYW5nZWQgdGhyb3Vn aCB0aGUgY29uc2Vuc3VzIHByb2Nlc3MgYXQgYW55IG90aGVyIHRpbWUuPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwO1NlYW4gaXMgc3BlY2lmaWNhbGx5IHNheWluZyB0aGUgJnF1b3Q7dHJpZ2dlciZx dW90OyBzaG91bGQgYmUgZGlzY3Vzc2VkPGJyPg0Kb24tbGlzdC48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGRvbid0IHJl YWQgdGhpcyB0aGlzIHdheSBhdCBhbGwsIFJhdGhlciBoZSdzIHNheWluZyB0aGF0IGluIHRoZSBm dXR1cmUgd2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Y2FuIHVwZGF0ZSB0aGUgUkZDLiBCdXQgeWVzLCB3ZSBjYW4gZGlzY3VzcyB0aGUgdHJp Z2dlciBvbi1saXN0LiBEbyB5b3U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+aGF2ZSBzb21lIHN1YnN0YW50aXZlIG9iamVjdGlvbiB0aGF0IHdh c24ndCByYWlzZWQgaW4gSE5MIGFuZC9vcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5oYXNuJ3QgYmVlbiBkaXNjdXNzZWQgdG8gZGVhdGggaGVy ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+XSBBZnRl ciB0aGUgZGlzY3Vzc2lvbiwgc29tZSBjbGFyaWZ5aW5nIHF1ZXN0aW9ucyBhYm91dCB0aGUgaHVt cywgYW5kPGJyPg0KXSB0eXBpbmcgdGhlIGh1bSBxdWVzdGlvbnMgb24gdGhlIHNjcmVlbiwgdGhl cmUgd2FzIHJvdWdoIGNvbnNlbnN1cyBpbjxicj4NCl0gdGhlIHJvb20gdG8gYWRkIChha2EgJnF1 b3Q7c2hvdmUmcXVvdDspIHRoZSBwcm9wb3NlZCB0ZXh0IGludG88YnI+DQpdIGRyYWZ0LWlldGYt cnRjd2ViLXZpZGVvLiBJbiBrZWVwaW5nIHdpdGggSUVURiBwcm9jZXNzLCBJIGFtIGNvbmZpcm1p bmc8YnI+DQpdIHRoaXMgY29uc2Vuc3VzIGNhbGwgb24gdGhlIGxpc3QuPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwO1RoaXMgX2lzXyBjYWxsaW5nIGZvciBjb25zZW5zdXMuPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwO0J1dCBTZWFuIG9taXR0ZWQgc2F5aW5nIF93aGF0XyB0ZXh0OyBhbmQgYWdyZWVk IHRoYXQgdGhlIGV4YWN0IHRleHQ8YnI+DQptYXkgbm90IGhhdmUgYmVlbiBjbGVhciB0byB0aG9z ZSBpbiB0aGUgcm9vbS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5IdWg/IFRoZSAmcXVvdDtwcm9wb3NlZCB0ZXh0JnF1b3Q7 IHRoYXQgd2FzIGRpc2N1c3NlZCBpbiBITkwgaXMgb24gdGhlIHNsaWRlIGFuZDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50aGF0J3Mgd2hhdCdz IGJlaW5nIHJlZmVycmVkIHRvIGhlcmUuIEFkYW0gZWRpdGVkIHRleHQgd2hpY2ggaXMgc3Vic3Rh bnRpYWxseTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj50aGUgc2FtZSBpbnRvIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl0gSWYgYW55b25lIGhhcyBhbnkgb3RoZXIgaXNzdWVz IHRoYXQgdGhleSB3b3VsZCBsaWtlIHRvIHJhaXNlIHBsZWFzZSBkbzxicj4NCl0gYnkgRGVjZW1i ZXIgMTl0aC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7KEFuZCBmb2xrcyBoYXZlIGJlZW4gZG9p bmcgc28uKTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtJIGhhdmUgYXNrZWQgb24tbGlzdCBmb3Ig dGhlIGV4YWN0IHRleHQgYmVmb3JlIHJhaXNpbmcgbXkgaXNzdWVzLDxicj4NCnNpbmNlIG15IGlz c3VlcyByZWxhdGUgdG8gdGhlIHRleHQsIG5vdCB0aGUgY2hvb3NpbmcgdG8gaGF2ZSB0d28gTVRJ cy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5BcyBJIHBvaW50ZWQgb3V0IGluIG15IG9yaWdpbmFsIG1lc3NhZ2UsIHRoYXQg dGV4dCBpcyBpbiBBZGFtJ3MgZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BZ2FpbiwgaXQncyB0b3RhbGx5IHByb2NlZHVyYWxs eSByZWd1bGFyIHRvIGhhdmUgcm91Z2ggY29uc2Vuc3VzIG9uIHRleHQgaW48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dGhlIFdHIG1lZXRpbmcg YW5kIG9uIHRoZSBsaXN0IGFuZCB0aGVuIGhhdmUgdGhlIGVkaXRvciBlZGl0IGluIHN1YnN0YW50 aXZlbHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+dGhlIHNhbWUgdGV4dCB0byB0aGUgZHJhZnQuIElmIHlvdSB0aGluayB0aGVyZSBpcyBzb21l IHJlc3BlY3QgaW4gd2hpY2ggdGhvc2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+dHdvIGJsb2NrcyBvZiB0ZXh0IGFyZSBub3QgaW4gZmFjdCB0 aGUgc2FtZSwgcGxlYXNlIHBvaW50IHRvIGl0LiBPdGhlcndpc2UsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRoaXMgaXMganVzdCBkaWxhdG9y eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyBB bmQgdGhpcyBtZXNzYWdlIGNsZWFybHkgcG9pbnRzIHRvIHRoZSBzbGlkZXMgYWJvdmUuPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwO0kgZG9uJ3QgZmluZCBpdCBoZWxwZnVsIHRvIGF0dGFjayB0aGUg cGVvcGxlIHdobyByYWlzZSBpc3N1ZXMuIFlNTVYuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDtCdXQgd2hhdCBFS1IgdGhpbmtz IHJlYWxseSBkb2Vzbid0IG1hdHRlci4gSGUgaXMgbm90IGEgV0dDLjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklyb25pYyB0 aGF0IHlvdSB3b3VsZCBjb21wbGFpbiBhYm91dCAmcXVvdDthdHRhY2smcXVvdDtzIGluIGEgdGhy ZWFkIHdoZXJlIHlvdTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5zdGFydGVkIG91dCBieSBhdHRhY2tpbmcgQWRhbSBSb2FjaCBhbmQgaGVyZSBz YXkgJnF1b3Q7d2hhdCBFS1IgdGhpbmtzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPnJlYWxseSBkb2Vzbid0IG1hdHRlciZxdW90OzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LUVrcjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_92D0D52F3A63344CA478CF12DB0648AADF363670XMB111CNCrimnet_-- From nobody Tue Dec 16 12:41:11 2014 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787D51A87E8 for ; Tue, 16 Dec 2014 12:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WBWvczUoHOd for ; Tue, 16 Dec 2014 12:40:52 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104B31A87CE for ; Tue, 16 Dec 2014 12:40:52 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so18654469wgg.33 for ; Tue, 16 Dec 2014 12:40:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=sA5Okgxv3GIjMcyz8r2KyMUvBQUznY/yH3KZpfyhrmU=; b=RsC7i7MH3a5MvPu0Pokth6yQV9TE+N8YwumDiHM14JfcOAZUcgukQAbfq3im3jOF5V XtX6lAjCy39/6jZjvOmcCrAZZbNLxe70V4hpjmrZKyZLU7ByBO9h0hem1qsjMXaDrE6E Ls/cDM4Cn/OOPCs0X9eU29SUg12SxKuFiR6xMPpPYEl5uh5S+5m9+4AdyRg5N0L7rOiV AyYrBnPdO9WGGU63vk1zVAi5PjD/sNm1mVyvaKg2LCxCqxJP5txT8eCfAFOKv5d2KWXL Oo0NPQcRv0MMjkdnfYTXuy02NuxgufhiPq53ztIdfXq0vpEdgDXKRnrxAxlUBwoDaeVR tdhw== X-Gm-Message-State: ALoCoQkZ6UsltmgviWBcb6H/ZRqFwYelVLa2U49uC6M6teLgCvTc2wlevtaSp5HdlVNgplIczvIj X-Received: by 10.194.203.104 with SMTP id kp8mr33094661wjc.103.1418762450757; Tue, 16 Dec 2014 12:40:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.130.34 with HTTP; Tue, 16 Dec 2014 12:40:10 -0800 (PST) In-Reply-To: <92D0D52F3A63344CA478CF12DB0648AADF363670@XMB111CNC.rim.net> References: <548F54A5.2060105@andyet.net> <548F5E22.2040605@andyet.net> <548F5F0E.4050100@nostrum.com> <548F5FB8.9010300@andyet.net> <548F646C.1050406@nostrum.com> <20141216150303.GT47023@verdi> <20141216152100.GU47023@verdi> <20141216162534.GV47023@verdi> <92D0D52F3A63344CA478CF12DB0648AADF3634AA@XMB111CNC.rim.net> <92D0D52F3A63344CA478CF12DB0648AADF363549@XMB111CNC.rim.net> <92D0D52F3A63344CA478CF12DB0648AADF363670@XMB111CNC.rim.net> From: Eric Rescorla Date: Tue, 16 Dec 2014 12:40:10 -0800 Message-ID: To: Gaelle Martin-Cocher Content-Type: multipart/alternative; boundary=047d7bae493ee60073050a5b5fa2 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gQ47_BmKiyox-TLxIyAX8blYbG0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] revisiting MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 20:40:58 -0000 --047d7bae493ee60073050a5b5fa2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Dec 16, 2014 at 12:35 PM, Gaelle Martin-Cocher < gmartincocher@blackberry.com> wrote: > > > > > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* Tuesday, December 16, 2014 2:59 PM > *To:* Gaelle Martin-Cocher > *Cc:* John Leslie; rtcweb@ietf.org > *Subject:* Re: [rtcweb] revisiting MTI > > > > > > > > On Tue, Dec 16, 2014 at 11:56 AM, Gaelle Martin-Cocher < > gmartincocher@blackberry.com> wrote: > > I am not sure on what you are basing your opinion. > > > > As I said, the purpose of an MTI is to provide basic interop. > > > > That point is clear to all. Sorry I was referring to =E2=80=9CI would no= t > imagine that we > > would define a new required codec unless it was not just technically > > superior but also definitively RF in the sense contemplated by Adam's > > text.=E2=80=9D > > And I am not sure that holds true. > > Making a new non-RF codec MTI doesn't enhance basic interop. Waiting for an RF technically superior codec might not be pragmatic and > can indeed prevent any evolution of WebRTC codec for a long time. > > Deprecating MTI can be done in steps (e.g. become SHOULD, then MAY) > > > > If this MTI text prevents codec evolution, this is a serious issue. > > > > It doesn't prevent codec evolution. That's why we have negotiation. > Browsers > > are free to implement non-MTI codecs and I would anticipate that they > > will do so. > > And non-browser as well, but the spec will let us stuck for ever with low > performing codec. > This doesn't follow at all. The IETF is free to in the future designate som= e other codec as MTI and these not and this text doesn't preclude that. -Ekr > --047d7bae493ee60073050a5b5fa2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 16, 2014 at 12:35 PM, Gaelle Martin-Cocher <gma= rtincocher@blackberry.com> wrote:

=C2=A0

=C2=A0

From: Eric Res= corla [mailto:ekr@rtfm.co= m]
Sent: Tuesday, December 16, 2014 2:59 PM
To: Gaelle Martin-Cocher
Cc: John Leslie; rtcweb@ietf.org
Subject: Re: [rtcweb] revisiting MTI

=C2=A0

=C2=A0

=C2=A0

On Tue, Dec 16, 2014 at 11:56 AM, Gaelle Martin-Coch= er <gm= artincocher@blackberry.com> wrote:

I am not sure on what you= are basing your opinion.

=C2=A0

As I said, the purpose of an MTI is to provide basic= interop.

=C2=A0

That point is clea= r to all.=C2=A0 Sorry I was referring to =E2=80=9CI would not imagin= e that we

would define a new required codec unless it was not = just technically

superior but also definitively RF in the sense conte= mplated by Adam's

text.=E2=80=9D

And I am not sure that= holds true.



=
Making a new non-RF codec MTI doesn't enhance basic interop.
=

Waiting for an RF technic= ally superior codec might not be pragmatic and can indeed prevent any evolu= tion of WebRTC codec for a long time.

Deprecating MTI can be do= ne in steps (e.g. become SHOULD, then MAY)

=C2=A0

If this MTI text prevents= codec evolution, this is a serious issue.

=C2=A0

It doesn't prevent codec evolution. That's w= hy we have negotiation. Browsers

are free to implement non-MTI codecs and I would ant= icipate that they

will do so.

And non-browser as wel= l, but the spec will let us stuck for ever with low performing codec.


T= his doesn't follow at all. The IETF is free to in the future designate = some
other codec as MTI and these not and this text doesn't p= reclude that.

-Ekr
=C2=A0
=
<= div>