W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2010

RE: updated draft of Permissions for Device API access (was "Device API Features and Capabilities")

From: Suresh Chitturi <schitturi@rim.com>
Date: Wed, 29 Sep 2010 09:09:24 -0500
Message-ID: <D37CC1B151BD57489F4F89609F168FE8070EB599@XCH01DFW.rim.net>
To: "Dominique Hazael-Massieux" <dom@w3.org>
Cc: "public-device-apis" <public-device-apis@w3.org>
-----Original Message-----
From: Dominique Hazael-Massieux [mailto:dom@w3.org] 
Sent: Wednesday, September 29, 2010 4:23 AM
To: Suresh Chitturi
Cc: public-device-apis
Subject: RE: updated draft of Permissions for Device API access (was "Device API Features and Capabilities")

Le mardi 28 septembre 2010 à 13:07 -0500, Suresh Chitturi a écrit :
> Suresh>> The use case is I would only grant permission for one time
> which translates to getCurrentPosition() and in some cases I would be
> fine to grant permission for continuous monitoring and that is
> watchPosition() and yet in another case I don’t care about the details
> and grant for both getCurrentPosition() and watchPosition().

But who is "I" in this context? The user? thhe policy framework?

Suresh>> All of the above?

getCurrentPosition() is only distinguishable from watchPosition() when
it is limited in number, and wathcPosition() can be made equivalent to a
getCurrentPosition() by limiting it in duration. The number/duration
limitation parameter seems important, but I think it's orthogonal to the
actual permission that is granted, and probably ought to be specified
separately (e.g. through a <param> element in the <feature> element of
widgets P&C).

Maybe we should start collecting these parameters as part of the

> Suresh>> My understanding is that these identifiers can be used in
> with the <feature> element prefixed with a URI as described in the 1.
> Introduction. And what I was merely suggesting is that a complementary
> statement be added that these identifiers can also be used in
> conjunction with the <access> element. 

But that doesn't seem to match what WARP currently allows; I don't know
how you would specify that only example.com can make use of geolocation
within the current form of WARP:

That might be a worthwhile complement to WARP (in which case it should
be written up as a concrete specification), but I don't think it makes
to refer to it if it isn't specified yet.

Suresh>> This was my understanding that WARP allows you to control which domains can access the APIs listed under <feature> elements. Robin is an expert on this and we should seek his input.


This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Received on Wednesday, 29 September 2010 14:10:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:46 UTC