- 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