Re: wording for the privacy section

On Oct 29, 2008, at 1:28 AM, Ian Hickson wrote:
>
> Just out of interest, could you show what you think the API should  
> look
> like to handle Geopriv, along with all on-the-wire examples? (Please  
> be
> thorough, i.e. don't say "and then you send a geopriv XML packet" or
> whatever, please actually show the entirety of all data that is to  
> be sent
> in all directions so that we can have a full view of what it is you  
> are
> proposing.) It may be that our disagreement is just based on my  
> ignorance
> of what you are actually considering.
>


This is exactly the discussion we would like to have with the group:  
how can Geopriv be best implemented within the API?

I've put together one incomplete implementation idea below. This is by  
no means the best or only way Geopriv could be implemented here, and  
in fact if those who worked on Geopriv saw this they might have a  
completely different idea about the best approach. As John explained  
in his last email, I am new to the Geopriv effort, and would need a  
fuller understanding of its architecture before I would say this is  
the way to go. I'm also not out there implementing the W3C API like  
others in this group, so this suggestion lacks that perspective. But  
this is exactly the conversation we want to have, and exactly the  
reason why liaising with those involved in and implementing other  
standards efforts is so important.

So, FWIW:

In addition to the Position attribute in the Geolocation interface, we  
could have a UsageRules attribute:

	readonly attribute UsageRules usageRules;

where the UsageRules interface is defined as:

	interface UsageRules {
   		readonly attribute boolean retransmissionAllowed;
   		readonly attribute DOMTimeStamp retentionExpires;
   		readonly attribute DOMString rulesetReference;
   		readonly attribute DOMString noteWell;
	};

This data structure maps to the usage-rules element defined in [1],  
the Geopriv location object format specification. A full Geopriv  
implementation would adopt the whole data structure outlined in that  
specification, but since the privacy rules are the subject of our  
current discussion that is what my straw-man focuses on. Brief  
descriptions of each attribute (as adapted from [1]):

retransmissionAllowed: A value of false means the recipient of the  
position is not permitted to share it with
     other parties.  When the value of this element is true,  
distribution is permitted (barring an existing out-
     of-band agreement or obligation to the contrary).

  retentionExpires: This field specifies an absolute date at which
     time the recipient of the position is no longer permitted to  
possess it.  By default,
     the value must be assumed to be twenty-four hours from the  
position timestamp.

  rulesetReference: This field contains a URI that indicates where a
     fuller ruleset of policies, related to this object, can be found.

  noteWell: This field contains a text containing further
     generic privacy directives.  These directives are intended to be
     human-readable only.

Handling the event of a position request would then take two arguments  
instead of one -- the position and the usage rules:

	interface PositionCallback {
		void handleEvent(in Position position, in UsageRules usageRules);
	};

If the position obtained from the host does not come in the form of a  
Geopriv object, the UA would use the default rules or prompt the user  
for rules. If the position object is a Geopriv object, the UA would  
set (and comply with) the rules as they already exist in the object.

To be clear, this is a quick-and-dirty effort just to illustrate how  
to go about implementing Geopriv. I hope it's helpful.

Alissa

[1] http://www.ietf.org/rfc/rfc4119.txt

Received on Wednesday, 29 October 2008 21:47:00 UTC