- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Mon, 24 Feb 2014 15:31:42 +0000
- To: Eric Rescorla <ekr@rtfm.com>, "Mandyam, Giridhar" <mandyam@quicinc.com>
- CC: Dominique Hazael-Massieux <dom@w3.org>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 2014-02-22 00:09, Eric Rescorla wrote: > To be honest, I don't care which WG document this is specified in. When > we initially agreed to put identity into the specifications, the guidance > was to put the pieces that were arguments to gUM in the media capture > spec and the pieces that were relevant to WebRTC in the WebRTC spec. > > If people prefer they all go in WebRTC, that seems like a not very important > document structure question. But maybe I'm missing the bigger picture :) I agree, this is mostly a document structure question. But to get me on the right page: the idea with connecting the identity with the tracks is to be able to inform the user in the permission prompt that the media can only be sent to a certain user. Is that right? Stefan > > -Ekr > > > > On Fri, Feb 21, 2014 at 8:12 AM, Mandyam, Giridhar <mandyam@quicinc.com > <mailto:mandyam@quicinc.com>> wrote: > > If the UA wants to display a dialog with specific text, I don't > think that actual text needs to be specified in this document. As a > comparison point, refer to the guidance in HTML Media Capture for > security: http://www.w3.org/TR/html-media-capture/#security. But as > far as I can tell, none of the DAP WG specs lay out any normative > requirements as to the actual text displayed in dialog boxes (but if > I'm wrong, please correct me). > > I also don't understand what "identity-of-peer-user" means in a > Media Capture context. Moreover, there exist applications that do > not require P2P communications, and I don't see why this kind of > constraint would be relevant in this case. Moreover, it is clear > that there is no consensus within the group on this particular > topic, so I don't know why the editors pulled this into the spec in > the first place. > > This constraint may be more meaningful as part of any permissions > prompt for WebRTC, but that issue should be discussed in that WG. > If it has already been discussed there and rejected, then this > looks like venue shopping; > > -----Original Message----- > From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com > <mailto:stefan.lk.hakansson@ericsson.com>] > Sent: Friday, February 21, 2014 4:20 AM > To: Mandyam, Giridhar; Dominique Hazael-Massieux > Cc: public-media-capture@w3.org <mailto:public-media-capture@w3.org> > Subject: Re: [Bug 22594] noaccess / peerIdentity as constraints > > Giri, > > can you develop your thoughts a bit? > > I have on the list proposed that much of the peerIdentity stuff > should be moved to the WebRTC document, but if the UA would want to > display a special dialogue with the gUM prompt ("the app asking for > access to your camera will no be able to record the media, or be > able to send to anyone else than identity-of-peer-user") it should > be documented in this document I think. > > Br, > Stefan > > On 2014-02-20 17:47, Mandyam, Giridhar wrote: > > Sounds good. I can file if you don't mind. > > > > Thanks, > > -Giri > > > > -----Original Message----- > > From: Dominique Hazael-Massieux [mailto:dom@w3.org > <mailto:dom@w3.org>] > > Sent: Thursday, February 20, 2014 8:46 AM > > To: Mandyam, Giridhar > > Cc: public-media-capture@w3.org <mailto:public-media-capture@w3.org> > > Subject: Re: [Bug 22594] noaccess / peerIdentity as constraints > > > > Hi Giri, > > > > On jeu., 2014-02-20 at 16:34 +0000, Mandyam, Giridhar wrote: > >> I apologize, but we don't think this particular bug is fixed. > QuIC's > >> opinion is that all mention of peerIdentity should be removed from > >> this particular document. We will not support this document > going to > >> last call otherwise. > > > > The bug I had raised was specifically on the fact that > peerIdentity/noaccess where not MediaStreamTrack-level constraint, > which has now been fixed. I think the move of peerIdentity to the > WebRTC document might deserve a separate bug for clarity sake. > > > > Dom > > > > > > >
Received on Monday, 24 February 2014 15:32:11 UTC