W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2016

[mediacapture-main] Reinstate strong language on permission ending when tracks stop, lost by editorial mistake

From: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Fri, 26 Aug 2016 23:23:59 +0000
To: public-media-capture@w3.org
Message-ID: <issues.opened-173561843-1472253837-sysbot+gh@w3.org>
jan-ivar has just created a new issue for 
https://github.com/w3c/mediacapture-main:

== Reinstate strong language on permission ending when tracks stop, 
lost by editorial mistake ==
In February, [the spec 
said](https://w3c.github.io/mediacapture-main/archives/20160222/getusermedia.html#source-stopped):

"When all tracks using a source have been stopped or ended by some 
other means, the source is stopped. Unless there is a stored 
permission for the source in question, the given permission is revoked
 and the User Agent SHOULD also remove the "permission granted" 
indicator for the source."

This predates editorial attempts at integrating with the permissions 
spec, and says that while removing the indicator is optional, revoking
 permission is not, unless it's been "stored". 

Compare to 
[today](https://w3c.github.io/mediacapture-main/getusermedia.html#source-stopped):

"When all tracks using a source have been stopped or ended by some 
other means, the source is stopped. If there is no stored permission 
for the source, the User Agent SHOULD also remove the "permission 
granted" indicator for the source. If the data is being generated from
 a live source (e.g., a microphone or camera), then the User Agent 
SHOULD remove any active "on-air" indicator for that source."

This no longer says anything should happen to the permission, and 
makes it sounds like stopping all tracks SHOULD revoke permisson. We 
should clarify that this is not the case with stronger language closer
 to the February consensus.

Please view or discuss this issue at 
https://github.com/w3c/mediacapture-main/issues/387 using your GitHub 
account
Received on Friday, 26 August 2016 23:24:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:37 UTC