Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD42F1A8714 for ; Mon, 10 Nov 2014 21:23:19 -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 UtOLWEHqmtM2 for ; Mon, 10 Nov 2014 21:23:17 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913EE1A6FE9 for ; Mon, 10 Nov 2014 21:23:17 -0800 (PST) Received: by mail-oi0-f54.google.com with SMTP id a141so6537004oig.13 for ; Mon, 10 Nov 2014 21:23: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 :content-type; bh=pHezftruDGf7248S3tcQxUhHXJCHAEk3B1TGHGR6zj8=; b=hYrD9SkRXrLzBAZMU0jZDiGQ356Rxn9pHIJEPItKVXZ61gEszg1dQCNgUe7yyZL9SK gV/WzakevpltV2hwKyTh+KdajnFj+U6K6WQ0YgYcF1/1tW4p9xFwym1+1PwnHStFoHQm BTg0v+GZaTOlzG5ycs+fxlKrp6BB+BDjV59q/9Z8L40LApOoAxN535j594Q1Tc1b/fD1 DQc1V2rdROWLvzbSKKgxg5fk/u5oaIkDLsk/MGi2yqN+GzlW05TLuh6l7k1WUyWnZ9qu F/JhnqT+/hZFxSv+0vN/jmj+xd8qRk5bhM8uT0J79YKr4v+1O/VzS1GSMl2t4mLQYpvs BK9Q== MIME-Version: 1.0 X-Received: by 10.60.173.39 with SMTP id bh7mr31321395oec.32.1415683396777; Mon, 10 Nov 2014 21:23:16 -0800 (PST) Received: by 10.202.209.8 with HTTP; Mon, 10 Nov 2014 21:23:16 -0800 (PST) In-Reply-To: References: <54601E19.8080203@nostrum.com> <176316D6-D685-45F4-AA8E-A4F07521CAE4@matthew.at> <1D5CFB04-2CCB-424C-A364-1CAA05E84D12@apple.com> <20141111011054.GR8092@hex.shelbyville.oz> Date: Tue, 11 Nov 2014 13:23:16 +0800 Message-ID: From: Alexandre GOUAILLARD To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7bd6ba9afabe1105078e79f8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OEDJUMFA-vdspjrybNzzId87PsQ Subject: Re: [rtcweb] MTI Video Codec: a novel proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 11 Nov 2014 05:23:20 -0000 --047d7bd6ba9afabe1105078e79f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 for this proposal. Thanks adam for doing the background work to bring some parties closer to a consensus. On Tue, Nov 11, 2014 at 11:19 AM, Bernard Aboba wrote: > I do not get it either. It seems like mobile apps (which count as devices= ) > using a WEBRTC stack now have to include both codecs regardless of whethe= r > they need them. Do we really think app developers will pay attention? Why > should they? > > > > > On Nov 10, 2014, at 3:20 PM, David Singer wrote: > > > > > >> On Nov 10, 2014, at 17:10 , Ron wrote: > >> > >> His option guarantees that anyone implementing only their preferred > >> codec will be able to interop with any compliant implementation, > >> though it may not be able to do so with another non-compliant > >> implementation that similarly opted out of supporting that codec. > > > > I am sorry, I don=E2=80=99t get it. The spec. defines =E2=80=9CWebRTC-= compatible > endpoint=E2=80=9D > > > > A WebRTC-compatible endpoint is an endpoint that is capable of > > successfully communicating 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. > > > > but says nothing about it being =E2=80=98non-compliant=E2=80=99. So an= yone can say =E2=80=9CI > claim that this is compliant to the spec.=E2=80=9D (as a webrtc-compatibl= e > endpoint) =E2=80=94 and it might not interoperate. Basically, this propos= al assigns > different names to the devices that implement both, and those that > implement only one or none, but does that really further the cause of > interoperability? > > > > 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 > --=20 Alex. Gouaillard, PhD, PhD, MBA ---------------------------------------------------------------------------= --------- CTO - Temasys Communications, S'pore / Mountain View President - CoSMo Software, Cambridge, MA ---------------------------------------------------------------------------= --------- sg.linkedin.com/agouaillard - --047d7bd6ba9afabe1105078e79f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for this proposal.

Thanks adam for d= oing the background work to bring some parties closer to a consensus.
=

On Tue, Nov= 11, 2014 at 11:19 AM, Bernard Aboba <bernard.aboba@gmail.com>= ; wrote:
I do not get it either. I= t seems like mobile apps (which count as devices) using a WEBRTC stack now = have to include both codecs regardless of whether they need them. Do we rea= lly think app developers will pay attention? Why should they?



> On Nov 10, 2014, at 3:20 PM, David Singer <singer@apple.com> wrote:
>
>
>> On Nov 10, 2014, at 17:10 , Ron <ron@debian.org> wrote:
>>
>> His option guarantees that anyone implementing only their preferre= d
>> codec will be able to interop with any compliant implementation, >> though it may not be able to do so with another non-compliant
>> implementation that similarly opted out of supporting that codec.<= br> >
> I am sorry, I don=E2=80=99t get it.=C2=A0 The spec. defines =E2=80=9CW= ebRTC-compatible endpoint=E2=80=9D
>
> A WebRTC-compatible endpoint is an endpoint that is capable of
>=C2=A0 =C2=A0 =C2=A0 successfully communicating with a WebRTC endpoint,= but may fail to
>=C2=A0 =C2=A0 =C2=A0 meet some requirements of a WebRTC endpoint.=C2=A0= This may limit where
>=C2=A0 =C2=A0 =C2=A0 in the network such an endpoint can be attached, o= r may limit the
>=C2=A0 =C2=A0 =C2=A0 security guarantees that it offers to others.
>
> but says nothing about it being =E2=80=98non-compliant=E2=80=99.=C2=A0= So anyone can say =E2=80=9CI claim that this is compliant to the spec.=E2= =80=9D (as a webrtc-compatible endpoint) =E2=80=94 and it might not interop= erate. Basically, this proposal assigns different names to the devices that= implement both, and those that implement only one or none, but does that r= eally further the cause of interoperability?
>
> 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



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

<= /div>
--047d7bd6ba9afabe1105078e79f8--