Re: [rtcweb] Stephan Wenger's choices

Ron <ron@debian.org> Thu, 02 January 2014 15:31 UTC

Return-Path: <ron@debian.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD371AE561 for <rtcweb@ietfa.amsl.com>; Thu, 2 Jan 2014 07:31:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YqHpORIMtvx for <rtcweb@ietfa.amsl.com>; Thu, 2 Jan 2014 07:31:47 -0800 (PST)
Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 40A5D1AE570 for <rtcweb@ietf.org>; Thu, 2 Jan 2014 07:31:46 -0800 (PST)
Received: from ppp118-210-34-29.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([118.210.34.29]) by ipmail06.adl2.internode.on.net with ESMTP; 03 Jan 2014 02:01:39 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 99A484F8F3 for <rtcweb@ietf.org>; Fri, 3 Jan 2014 02:01:34 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XLGA5GMJz2dy for <rtcweb@ietf.org>; Fri, 3 Jan 2014 02:01:33 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id EDEDC4F902; Fri, 3 Jan 2014 02:01:33 +1030 (CST)
Date: Fri, 03 Jan 2014 02:01:33 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <20140102153133.GQ3245@audi.shelbyville.oz>
References: <52BF037D.4050706@googlemail.com> <CEE4479F.3E568%stewe@stewe.org> <20131228183148.GI3245@audi.shelbyville.oz> <CABcZeBOMEE9nOMzR2AisGQDTByrjsNms6qS4+DQvjUMUYyHCjw@mail.gmail.com> <20131228212423.GJ3245@audi.shelbyville.oz> <949EF20990823C4C85C18D59AA11AD8B0FDFAB@FR712WXCHMBA11.zeu.alcatel-lucent.com> <20131230204917.GO3245@audi.shelbyville.oz> <949EF20990823C4C85C18D59AA11AD8B0FE716@FR712WXCHMBA11.zeu.alcatel-lucent.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0FE716@FR712WXCHMBA11.zeu.alcatel-lucent.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] Stephan Wenger's choices
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 02 Jan 2014 15:31:52 -0000

On Thu, Jan 02, 2014 at 11:12:39AM +0000, DRAGE, Keith (Keith) wrote:
> 1)	My original mail was sent "over a shitty mobile connection" but it was
> sent using the normal screen of my laptop, not "on a 4 inch screen". Use of
> mobile is dependent on circumstances of the user, and does not predicate what
> will be used to render to the user.

I'm not sure if that explains where the missing logic might have dropped out,
but congratulations on being able to send some text with it just the same!

> 2)	You are making the assumption that communication mechanism attempted by
> the user is the best available, and that the way you interpret the media to
> be used is the best usage of the bandwidth for that purpose. When the only
> description supplied by the user for that media is "video", that encompasses
> a large range of possible use cases and it is inadvisable to assume that any
> video will do. The signalling does not indicate that there is a deaf person
> in the car with me, and therefore you should not assume the use case has to
> encompass that unless I explicitly say so. Until I actually explicitly signal
> something, my expectations could be at one extreme or the other.

I don't know what kind of crazy windmill system you might be imagining to
tilt at here, but I thought two things were plainly self evident in all of
the discussions here.

 - Codecs can be negotiated (with whatever algorithm may be appropriate).
 - Nothing gets enabled without user consent.


> I stand by my original comment.

I think it fell down.  If there was a point to it that you want to be
understood, you might need to prop it back up again with some sturdier
and more coherent logic.

If your point is that "some codecs are better than others in certain
circumstances", then sure, unlike for audio where we have Opus that
dominates right across the board, for video this currently is still
the case.  And that's yet another reason to have a broader range to
select from at negotiation time.

It's not an argument for why a very simple, low complexity, maximally
available codec isn't suitable as the MTI fallback of last resort.
And it's not an argument for why we should tell people that might be
able to use only that codec on particular devices that they'd be
"better off with no video at all".

In the context of your original comment, that would be be like _us_
telling _you_ that you'd be better off without any legs.  Or that
you'd be better off without any internet connection at all rather
than what you're suffering with now.  Personally I think it would
be rudely presumptuous of us to make such assumptions when there is
no compelling technical reason to disenfranchise people in this way.

  Ron