Re: [rtcweb] Time allocation for video discussion (Re: Proposed Agenda For WG Meetings)

Matthew Kaufman <matthew@matthew.at> Fri, 22 February 2013 16:18 UTC

Return-Path: <matthew@matthew.at>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A401021F84E0 for <rtcweb@ietfa.amsl.com>; Fri, 22 Feb 2013 08:18:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.43
X-Spam-Level:
X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIWw355fm2jF for <rtcweb@ietfa.amsl.com>; Fri, 22 Feb 2013 08:18:30 -0800 (PST)
Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D5721F84D9 for <rtcweb@ietf.org>; Fri, 22 Feb 2013 08:18:29 -0800 (PST)
Received: from [10.10.155.229] (unknown [10.10.155.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 9A99D1480BF; Fri, 22 Feb 2013 08:18:29 -0800 (PST)
Message-ID: <51279A54.5000503@matthew.at>
Date: Fri, 22 Feb 2013 08:18:28 -0800
From: Matthew Kaufman <matthew@matthew.at>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ted Hardie <ted.ietf@gmail.com>
References: <CABcZeBMg0AdhFj61S1hgz9WCP2JikLabrm3dAA36hyb99_93Sg@mail.gmail.com> <51263796.8030705@alvestrand.no> <CABcZeBPoH+QQg1dPEoCc1AgwFVYdmHduwZ7W8qCahOr+Spz8eQ@mail.gmail.com> <AE1A6B5FD507DC4FB3C5166F3A05A484161EB226@TK5EX14MBXC273.redmond.corp.microsoft.com> <CA+9kkMD_a7Si5F+4PiggmLkAtTUaocrF=bYd0oy0bv-bZ6zzdA@mail.gmail.com> <5126C5BA.4060701@matthew.at> <CA+9kkMBmzJecyiqapYKukwRgK5kN73pmFqEC_qVc+DZ7ESaWJA@mail.gmail.com>
In-Reply-To: <CA+9kkMBmzJecyiqapYKukwRgK5kN73pmFqEC_qVc+DZ7ESaWJA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Time allocation for video discussion (Re: Proposed Agenda For WG Meetings)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Feb 2013 16:18:30 -0000

On 2/22/2013 7:42 AM, Ted Hardie wrote:
> Hi Matthew,
>
>> But just because the charter mistakenly calls this out as something for the
>> IETF to solve doesn't mean that the IETF is the right place to have the
>> discussion. I will note that several other IETF protocols for A/V
>> interoperability, such as SIP, have enjoyed wide success without wasting any
>> valuable meeting time trying to standardize on a single audio and video
>> codec...
> You may have heard the chairs use the term "negotiation failure" in the context
> of selecting mandatory to implement codecs.   This phrase was taken from one of
> Henning's talking points on practical interoperability in SIP contexts

Yes, but it is also a good description for what's going to happen when 
this actually gets discussed. There are parties in the room who cannot 
under any circumstances ship one of the two options, and parties in the 
room who cannot under any circumstances ship the other. At least given 
the current IPR issues associated with each option.

Despite the charter, ultimately the W3C specification will need to be 
ratified, and having a pointer in there to an IETF document which 
mandates a codec which some of the parties in the room cannot use will 
be a blocking issue, and thus a subject of W3C discussion anyway, 
whether or not we take up valuable IETF meeting time discussing it again.

Matthew Kaufman