Re: [rtcweb] Use Case draft

Randell Jesup <> Mon, 30 April 2012 21:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBB3B21F86F5 for <>; Mon, 30 Apr 2012 14:01:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.289
X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tu81PXVcqSzC for <>; Mon, 30 Apr 2012 14:01:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 00C8321F86F4 for <>; Mon, 30 Apr 2012 14:01:14 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1SOxic-0001bI-1X for; Mon, 30 Apr 2012 16:01:14 -0500
Message-ID: <>
Date: Mon, 30 Apr 2012 17:00:16 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [rtcweb] Use Case draft
X-Mailman-Version: 2.1.12
Precedence: list
List-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, 30 Apr 2012 21:01:15 -0000

On 4/30/2012 7:41 AM, Stefan Hakansson LK wrote:
> On 04/27/2012 06:43 PM, Timothy B. Terriberry wrote:
>> Ted Hardie wrote:
>>> The chairs would like to ask the working group to focus on the use
>>> case draft. If you have use cases that need to be added to the
>>> document or text changes you'd like to suggest, please send them in
>> I proposed the following use-case back in February, but there wasn't
>> much discussion on actually adding it to the document:
>> Let me know if the WG would like to proceed with something like this.
> I think adding another small derivative of the simple video chat (this
> one with peer-to-peer file transfer added) makes a lot of sense. For
> one, we get a use case that requires reliable data (now we only have a
> req for "short latency datagram" which sound like unreliable to me); in
> addition we get a requirement for the data channel API to be able to use
> blobs (as defined in the File API W3C rec) as input/output.

The game case can need both reliable and unreliable data at the same 
time, which gets us reliable, unreliable and multiple streams.

> A third good requirement that can be derived (if we want to) is the
> ability to prioritize data in relation to audio/video.

File transfer or "let me show you the photo I took" while talking would 
do I think.

Randell Jesup