Subject: RE: [Geopriv] Geo-HTTP/HTML and location URIs

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 8 Nov 2005 18:02:36 -0600

Andrew,

I have a few suggestions; inline...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Andrew Daviel
> Sent: Wednesday, 9 November 2005 10:03 AM
> To: Andrew Newton
> Cc: [email-masked]
> Subject: Re: [Geopriv] Geo-HTTP/HTML and location URIs
> 
> 
> On Tue, 8 Nov 2005, Andrew Newton wrote:
> 
> 
> Again my apologies for not making it to all meetings or even
> reading all geopriv mail (reading ALL my mail is impossible, thanks to
> spammers and over-zealous webzine subscriptions)
> 
> >    It was the consensus of the participants that draft-daviel-kaegi-
> > html-geo-tag be accepted as a working group document so long as it
> > described static location information meant for public consumption,
> > and that this draft should reference GEOPRIV work for any other work.
> 
> OK. How should I proceed with this ? (there had been significant changes
> to boilerplate since the original drafts, which I probably still have not
> fully addresses).

I might suggest that you look at a tool that generates the text - for example, a number of us use the tool from xml.resource.org, which automates a lot of the task of generating boilerplate, references, table of contents, numbering, etc...

> Any suggestions for specific text changes ?

I have a few little things:
Section 3: Suggest that you register a URN with IANA for the metadata profile.  Unfortunately, I can't tell you which of the types in RFC 3688 are applicable.
Section 4: Suggest that you use XHTML for your examples: <meta name="x" value="y" />
Section 8: Suggest that you remove "This draft raises no security issues."

> 
> >    It was the consensus of the participants that draft-daviel-kaegi-
> > http-geo-header would only be accepted as a working group item if it
> > were first rewritten to use PIDF-LO.
> 
> 
> Using the privacy features established by the WG is reasonable; I had not
> intended that users write HTTP headers by hand  :-)
> 
> The application I had envisaged was as follows:
> 
> - I have a mobile device that somehow knows its location to a certain
> accuracy (it has a GPS device connected, or it determines it from its IP
> address, or it's just hard-wired in a config file)
> 
> - I wish to include this location information transparently to
> certain websites, to facilitate local searching, or to return localized
> pages in response to standard http GETs, in the same way as webservers may
> return pages in different natural languages using content-negotiation (as
> opposed to queries with location embedded)
> 
> - I have a control panel which will block, fuzz, or allow location
> information going to various sites, in the same manner as is now done
> for cookies or images. The control panel would typically be part of
> the browser preferences, and is associated with a particular user or
> user profile
> 
> - the application should not depend on the user having a webserver
> somewhere on which their preferences are stored. But maybe this is
> allowable, providing that there is also provision for local
> storage of preferences.

The application you have in mind is very much along the lines of what we are addressing with GEOPRIV.  The generation of location information is likewise out of scope, and we are concerned with protocols that move location information and control access to it.  Common-policy and geopriv-policy (both WG documents) are aimed at blocking and "fuzzing" as per your third step.

> 
> I had conceived of a local http proxy that could add HTTP headers to
> a standard browser request, rather than requiring changes to he browser
> software.

Such a feature has been discussed (at length) in relation to SIP.  There are still some grey areas, but any conclusions made for SIP would be largely applicable to HTTP.

> Andrew Daviel
> Vancouver Webpages

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Andrew Daviel <[email-masked]>
Date: Tue, 08 Nov 2005 16:46:50 -0800 (PST)

> Section 4: Suggest that you use XHTML for your examples: <meta name="x"

I had considered this. I think it is true that in general browsers
understand/do not barf on XHTML, if whitespace is placed before the
terminating "/>". So it would be "safe", and "would work". As it was
intended that the metadata be inserted in legacy documents, I'm not so
certain whether a document validated to, say, HTML3.2 would still validate
with XHTML included. However, the Web is full of invalid pages that most
people can read, and authors that care would probably reformat to XHTML
throughout. So I think I concur with the suggestion.

> Section 8: Suggest that you remove "This draft raises no security issues."

I thought this section was now mandatory, or at least that it was required
in IDs even thought the RFC editor may remove it before RFCs.

I'm not sure what security issues it does raise, apart from IMO silliness
like "if this document describes the location of something valuable, then
someone reading this document might steal it", which could, I suppose, be
passed off as the author's responsibility. I'm not sure that
this needs to be stated formally. Maybe it does now.

Andrew Daviel
Vancouver Webpages