[Rum] Minimum Technical Features in RUM?

Eric Burger <eburger@standardstrack.com> Wed, 27 March 2019 15:21 UTC

Return-Path: <eburger@standardstrack.com>
X-Original-To: rum@ietfa.amsl.com
Delivered-To: rum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FF41202EC for <rum@ietfa.amsl.com>; Wed, 27 Mar 2019 08:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.689
X-Spam-Level:
X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G87KE8n10SZA for <rum@ietfa.amsl.com>; Wed, 27 Mar 2019 08:21:07 -0700 (PDT)
Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com [198.46.93.79]) (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 DC7CC120073 for <rum@ietf.org>; Wed, 27 Mar 2019 08:21:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Message-Id:In-Reply-To:To:References:Date: Subject:Mime-Version:Content-Type:From:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NbNESIehpJI24ovm5D7V73I6glmUttLvW9QopiRM/J0=; b=b0U+RjF0Y6aZkvyhNzDdbP9Pd HDvnxxszSnmSFzXt+r0uJPam3xkVn8Qk4GLsNOIhsW0BoAXTHI21txNvHqc5n1SRFxeeI+fBHieLG DUtDUbQ0aBUTGFv1EJWXEBTzeJB32LpywF3lAY1YgJgibLlb7XIEXdrEV+JNbO4F5BUCU=;
Received: from [174.204.14.136] (port=2509 helo=[192.168.43.104]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <eburger@standardstrack.com>) id 1h9AMM-000GZS-7Y for rum@ietf.org; Wed, 27 Mar 2019 08:21:06 -0700
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_6F195680-3332-48D4-9238-936C1DA7DB1E"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Wed, 27 Mar 2019 11:20:56 -0400
References: <2a40ff1d-45d0-bc2c-eeee-5a28b5bcd3fd@nostrum.com>
To: rum@ietf.org
In-Reply-To: <2a40ff1d-45d0-bc2c-eeee-5a28b5bcd3fd@nostrum.com>
Message-Id: <21080EDE-D5F5-48EF-9CFA-C26B992E65BA@standardstrack.com>
X-Mailer: Apple Mail (2.3445.104.8)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/yh-cqt_6wRvvjYIIYk5oTp6b4tE>
Subject: [Rum] Minimum Technical Features in RUM?
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Mar 2019 15:21:09 -0000

Is there a compelling reason to go here?

> On Mar 27, 2019, at 9:49 AM, A. Jean Mahoney <mahoney@nostrum.com> wrote:
> 
> Brian asked if the draft was missing anything. If there is a required minimum frame rate, it would need to be captured in the draft. Adam said that once the WG started importing WebRTC information into the draft, they would find things to add. FEC for instance. Adam said he could be the WG contact for WebRTC information.

I agree: it would be nice to say, “The device MUST be usable.” However, doesn’t the definition of usable change over time? Looking at my real-time messaging work in the late 1990’s, we might have said something like, “You MUST have an ultra high-speed, 384kb/s connection.” Wouldn’t that look quaint today.

In other words, talking about FEC, minimum frame rates, minimum display sizes, etc. is IMHO is way out of scope. If someone chose to build a device that was unusable, that is not our problem. They would find adoption to be about 0%. Conversely, if someone is seriously building a device that meets RUM, they would presumably check to see what would be viable in the (then current) market.