Re: [rtcweb] More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07

Harald Alvestrand <harald@alvestrand.no> Sun, 10 June 2012 21:50 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAE521F8552 for <rtcweb@ietfa.amsl.com>; Sun, 10 Jun 2012 14:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2++v+UyJknMZ for <rtcweb@ietfa.amsl.com>; Sun, 10 Jun 2012 14:50:46 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0661921F8550 for <rtcweb@ietf.org>; Sun, 10 Jun 2012 14:50:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 70E7639E106 for <rtcweb@ietf.org>; Sun, 10 Jun 2012 23:51:00 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCUJ0fi2gaFg for <rtcweb@ietf.org>; Sun, 10 Jun 2012 23:50:59 +0200 (CEST)
Received: from [192.168.11.193] (c213-89-143-9.bredband.comhem.se [213.89.143.9]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id A0B0A39E056 for <rtcweb@ietf.org>; Sun, 10 Jun 2012 23:50:59 +0200 (CEST)
Message-ID: <4FD516B3.40501@alvestrand.no>
Date: Sun, 10 Jun 2012 23:50:43 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120411 Thunderbird/11.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5A2F246E-9D77-4B72-B3F1-681B00FA99FD@cisco.com> <F3D4ABD6AB47084B84337CF4F3446A464B2F11B52E@ESESSCMS0362.eemea.ericsson.se> <AAB6A6B6-BEC7-436C-B1EB-2C117596C7C6@cisco.com> <F3D4ABD6AB47084B84337CF4F3446A464B2F2631AC@ESESSCMS0362.eemea.ericsson.se> <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF021B53@MCHP04MSX.global-ad.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] More Comments on draft-ietf-rtcweb-use-cases-and-requirements-07
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: Sun, 10 Jun 2012 21:50:47 -0000

On 06/10/2012 05:33 PM, Hutton, Andrew wrote:
> Hi,
>
> Some comments on draft-ietf-rtcweb-use-cases-and-requirements-07.
>
> Section 4.1.1.1 (Simple Video Communication Service) contains the statement "Each user can also pause sending of media (audio, video, or both) and mute incoming media".  I think this and the associated requirements need some clarification for example whether the requirement is to control the direction of the media and therefore requires the generation of a new SDP offer with for example a direction of "recvonly/inactive".  The only associated requirement seems to be A8 but this does not help clarify what is meant by "pause" in the use case. It needs to be clarified whether the pause/resume/mute are actions within the browser or are actions which result in notifications to the remote user.
>
> Maybe we could add a use case which involves controlling the direction of multiple streams to emulate switching between different users in a multiparty call scenario.
>
>
> The statement "It is essential that the communication cannot be eavesdropped" appears in all use cases so could be moved to section 4.1 but I think it needs to be reworded in terms of the media always being encrypted as I don't like the term "eavesdropped" which is not defined.
If we want to define the term, we might want to use the term 
"wiretapping", and refer to RFC 2804 for the definition.

(having been involved in that discussion, I've got some personal 
fondness for that definition...)


>
> Regards
> Andy
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb