[rtcweb] Use cases: summary of status

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Thu, 04 August 2011 07:57 UTC

Return-Path: <stefan.lk.hakansson@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6073321F8B6E for <rtcweb@ietfa.amsl.com>; Thu, 4 Aug 2011 00:57:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.235
X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4THnueqQ586S for <rtcweb@ietfa.amsl.com>; Thu, 4 Aug 2011 00:57:20 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net []) by ietfa.amsl.com (Postfix) with ESMTP id 6522F21F8B7A for <rtcweb@ietf.org>; Thu, 4 Aug 2011 00:57:20 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-28-4e3a50eda047
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain []) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FD.3D.20773.DE05A3E4; Thu, 4 Aug 2011 09:57:33 +0200 (CEST)
Received: from ESESSCMS0362.eemea.ericsson.se ([]) by esessmw0191.eemea.ericsson.se ([]) with mapi; Thu, 4 Aug 2011 09:57:33 +0200
From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Thu, 04 Aug 2011 09:57:32 +0200
Thread-Topic: Use cases: summary of status
Thread-Index: AQHMUnwqEjlFeNrbIU+Jw5nErkrerQ==
Message-ID: <BBF498F2D030E84AB1179E24D1AC41D616C389F16D@ESESSCMS0362.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: [rtcweb] Use cases: summary of status
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: Thu, 04 Aug 2011 07:57:21 -0000

sorry for cross-posting.
As one of the editors for the use case doc, I would like to summarize the use case discussion a bit. A and B below is my understanding of the status regarding use cases after attending the webrtc meeting Sat July 23rd and the first rtcweb session of IETF 81, and after trying to digest the mail lists. C discusses how we could move forward, D where we should discuss and finally E my opinion as an individual.

Input/feedback is appreciated.
A. Existing (old) use cases 
The use cases listed in http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ where not questioned, all survived. However, the document type should be changed.

B. New use cases
I noted (as not immediately dismissed) the following proposals:
    1. Distributed music band, discussed at the webrtc meeting
    2. Use cases regarding different situations when being invited to a “session”, e.g. browser open, browser open but another tab active, browser open but active in session, browser closed, …. (Matthew Kaufman); discussed at webrtc meeting
    3. Different TURN provider scenarios (Cullen Jennings); discussed at the webrtc meeting
    4. More challenging NAT case (Matthew Kaufman); UDP blocked http://www.ietf.org/mail-archive/web/rtcweb/current/msg00468.html
    5. E911 (Paul Beaumont) http://www.ietf.org/mail-archive/web/rtcweb/current/msg00525.html
    6. Local Recording (John Ewell) at webrtc meeting
    7. Remote recording (John)  http://www.ietf.org/mail-archive/web/rtcweb/current/msg00472.html
    8. Emergency access for disabled (Bernard Aboba) http://www.ietf.org/mail-archive/web/rtcweb/current/msg00478.html
    9. Clue use cases (Roni Even) http://tools.ietf.org/html/draft-ietf-clue-telepresence-use-cases-01
    10. Rohan red cross (Cullen Jennings); proposed a bit earlier http://www.ietf.org/mail-archive/web/rtcweb/current/msg00323.html

Probably I have missed a few.
C. Way forward
The proper way forward would probably be to have people draft text describing these use cases and derive requirements they add, and then have a discussion on whether they should be included for version one of the standard or not.
In some cases the description exists already (Rohan red cross, emergency access for disabled, clue use cases) but not requirements.
Are there volunteers (maybe the ones proposing them)?

D. Where to discuss
This mail is sent to both public-webrtc at w3.org and to rtcweb at ietf.org. We have discussed that there should be only one use case document that is common for the webrtc and the rtcweb WGs, possibly the current ietf use case doc (http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/). Does this mean that it would be OK to discuss use cases on the rtcweb list only, or should we cross post?

Some of the proposed new use cases (2, 6) have relatively little bearing on IETF IMO; they are more W3C related, perhaps they should be documented and discussed in a webrtc context only.

E. Opinion as individual
My personal opinion is that we at this stage should focus on the basic use cases, and solve those in a good way. To me that would mean that we should add 3 (to allow different providers) and 4 (if you can’t connect no use case can be supported). I think that these use cases can be added as twists of/extensions to the first use case (Simple Video Communication Service).
In my view it also means that we should add text and requirements for 2 to make sure that the communication capabilites we are adding to the browser is usable in everyday scenarios. Presumable this would lead requirements (e.g. background execution capability) that are transferred to other W3C WGs - not to requirements in the webrtc/rtcweb space.
>From a W3C perspective it could also make sense to add a recording use case (as it seems that other W3C WGs rely on webrtc to provide an API for recording).

The rest of the new proposed use cases, IMO, could be looked into in a second stage when we've established the basics.