Subject: Re: [Geopriv] Draft Updates "GEO TAGS for HTML and HTTP"

From: "James M. Polk" <[email-masked]>
Date: Mon, 16 May 2005 13:00:28 -0500

Andrew

I apologize for not seeing this response until just now.

I like what you wrote below wrt draft-daviel-kaegi-html-geo-tag-07.txt and 
would recommend (as an individual) that it be revised with a better template.

At 10:55 AM 4/23/2005 -0700, Andrew Daviel wrote:

>On Tue, 22 Mar 2005, James M. Polk wrote:
>
> > comments on draft-daviel-kaegi-html-geo-tag-07.txt
> >
> > - someone needs to clean up the template used to be appropriate
>
>yes, I think the templates have changed a bit since the original version
>
> >
> > - I don't believe I like the applicability section that limits the tags to
> > fixed, non-moving objects, and "...may not be used for multinational
> > companies...". I think this will be misunderstood to be used for "where's
> > the nearest Pizza Hut?", which is disallowed because it is multinational,
> > but "where's Bob's Ace Hardware store?" is fine because it is magically
> > local in nature.
>
>The intent is to say that the geographic location of "Fermat's
>Theorem" or "Ford Motor Company" is meaningless, and to suggest that
>the geographic data space not be polluted with, for instance, every
>document that Joe User wrote after he added his office location to
>his default template. Suggestions for better examples or wording are
>welcome.
>
>A position for a moving object is certainly reasonable, though using HTML
>to publish it may not be the best method. The HTML metadata was intended
>to provide primarily an interface for a search engine, which typically has
>an update cycle of several weeks.
>
> >
> > - the ID mentions this is for "where a river is", yet that is not going to
> > be given in a single coordinate pair (x,y); thus making this specific
> > reference highly ambiguous in use;
>
>"river" is a counter-example, of an object that is ill-suited to
>being described by a single co-ordinate pair.
>
> >
> > - I also don't like the ambiguity about datums (none is specified), and the
> > lack of a definition of what is meant by altitude. The text seems to point
> > out some of the problems, but not really deal with how to address them.
>
>The draft specifies WGS84, if position is specified with sufficient
>accuracy for this to make a difference. The draft deliberately
>does not include a datum field - allowing users to specify alternate
>datums would increase the burden on search engines to provide conversion
>routines from multiple datums and formats to the internal datum,
>canonically WGS84.
>
>Altitude is defined as elevation above WGS84 datum, with the caveat that
>this may not be what a user expects in terms of "metres above ground
>level". Altitude is, I believe, difficult to deal with. Elevations
>shown by regular GPS sets are less accurate than horizontal measurements,
>while the scale of human structures in terms of floor level is
>more sensitive to altitude errors than horizontal errors - a 3 metre
>error in altitude when you are trying to find your car in a multi-storey
>car park is more serious than a 3 metre error North.
>Even if an altitude were specified accurately wrt. some well-defined
>datum, that doesn't easily translate into levels in the car park.
>
>The only reason for including an altitude field is that it shows up
>on a GPS display and if a user wants to include it, they can. Sometimes
>it may be useful - "this photo was taken at 2300m".
>
> >
> > - the draft raises no security issues by not dealing with privacy and
> > revelation according to anyone who may believe they have the right to
> > provide a location of a thing.
> >
> > Thus, I object to this effort if privacy cannot be adequately addressed as
> > to who is allowed to associate a location with a tag.
>
>Privacy issues must be handled offline through common courtesy or legal
>proceedings. There is nothing that one can put in a public web page that
>will prevent an agent from retrieving it. This is same situation
>as someone publishing telephone numbers or email addresses.
>
>
>The HTML metadata is an embodiment of the KISS principle enabling Web
>authors to add simple location data to a public page. In terms of
>RFC3693, it is not an instance of a "publication interface" or
>a "notification interface", but an interface between a Location Recipient
>(the process that has published the location data into the public domain
>on a webserver) and a search engine. A structured privacy query system
>is only valid over an authenticated, preferably encrypted, channel - the
>location generator and location server authenticate each other, then apply
>the rules to determine what location data is exchanged. The public Web is,
>almost by definition, not such a secure channel. In fact, security
>considerations dictate that information about scope, credentials etc.
>NOT be published on a public page - such information may give an attacker
>clues as to the fact that more sensitive data exists, and the methods
>that may be used to obtain it.
>
>
>
> > comments on draft-daviel-kaegi-http-geo-header-05.txt
> >
> > - the example section chose a poor example. If my laptop doesn't know where
> > it is, it cannot supply enough information to know which weather map is
> > which URI. This seems to be an attempt to get around a tunneling search for
> > where a user is to learn information to is available if the person
> > identifies what they want.
>
>I don't follow this.
>
>If the laptop does not know where it is, either by live feed or stored
>location, then it is true that the method cannot work.
>
> >
> > - section 2 says
> >   "In cases where the object being described is an area, such as a lake
> >     or a building, the position of the object should not in general be
> >     given to greater precision than the width of the object."
> >
> > then how would Lake Michigan be described? Or how would the Mississippi
> > River be described?
>
>"44;-87".  It's not intended to replace a GML polygon, or to convey a
>statistical measure of accuracy, just to suggest normal engineering-type
>usage of not giving the answer to 10 places of decimal if the original
>measurement is "50 paces North"
>
>This sentence should probably not be in the HTTP draft, only the HTML one.
>
>
> > - section 4 - where are all these values (and their hierarchies) assigned?
> > CA-ON is Ontario, Canada to you,  having spent time in Southern California
> > (it washed off BTW) I misunderstood CA-ON for Ontario, California very 
> quickly.
>
>ISO3166.
>
>ISO-3166-1 is in most cases the Internet country code (top-level-domain)
>ISO-3166-2 is, for the USA and Canada, the well-known state/province
>abbreviations e.g. WA, BC.
>It's pretty unambiguous in most cases, e.g. US = United States, FR =
>France, DE = Deutchland = Germany, though there are a few differences.
>GB = Great Britain, while the top level domain is UK = United Kingdom
>
>
> >
> > BTW - at the site http://geotags.com/geo/DMS3.html I typed in CA for the
> > country code, and ON for the region code, and got a failure - I did not get
> > Canada anything, nor did I get California anything. This may be a function
> > of the website, or it may be a function of ISO3166-2 not being specific
> > enough. I'm not sure, but this error has be questioning what would we use
> > that works?
>
>The page is confusing, I agree. It wants a country selected first, which
>changes the drop-down list  for the region. When a state/province is
>selected, it fills in the region code (e.g. US-AL for Alabama) which can
>then be converted to a meta tag. If the two-element region code is known,
>it can be entered directly, bypassing these steps.
>
> >
> > - there is no normative text discussing security, privacy or other such
> > considerations. I think that is bad.
> >
>There is a section 8, "Security Considerations", which I understood to be
>normative at the time the draft was originally submitted.
>
>
> > Therefore, I have strong concerns with this effort moving forward until
> > these issues can be addressed in direction first, specifics later.
> >
>
>Andrew Newton writes:
>
>
> > It would seem the disconnect between these drafts and the work-to-date
> > within GEOPRIV centers on the use cases - given the regard to privacy
> > GEOPRIV has taken.
>
>I know that there is somewhat of a disconnect. These drafts were
>originally referred to this WG by the RFC editor, because they both dealt
>with geographic data and the Internet.
>
>If the scope of these drafts (operating on publicly published data)
>is outside the purview of the geopriv WG, then perhaps the WG could
>state this and the reworked drafts could be resubmitted to the RFC editor.
>
>I still feel there is a need for something like this - schemes such as WML
>are essentially too complex for amateurs - Joe Blogger with his camera and
>GPS , though they may be excellent for professionals to exchange GIS
>information.
>
>
> > Perhaps we could get a list of places where these drafts have been
> > implemented so we can better understand the uses to which these specs
> > are being put.
>
>The HTML metadata is used in the geotags.com demonstration search engine
>and in the small number (hundreds) of pages submitted to it. There has
>been some interest from the blogging community.
>
>The HTTP headers have, as far as I know, been used only in
>proof-of-concept code interfacing to this search engine.
>
>Potential use includes wireless PDAs, in-car navigation systems etc.
>An interface has been described (http://gmap.glenmurphy.com/)
>to Google maps using a GPS. GPS interface to laptops is common
>in wardriving using e.g. NetStumbler. High-speed wireless
>Internet service to a laptop is available in limited areas
>(http://www.fido.ca/portal/en/support/ifido.shtml), and moderate-speed
>data services (GPRS, EDGE) are widely available.
>So the pieces are in place to make this work.
>
>
>
>I would probably now add a geo.postcode element. Although it has been
>stated that postcode is totally unsuited as a geographic description
>(irregular shaped postal boundaries, orders of magnitude differences in
>size between rural and urban postal areas), nevertheless it is being used
>by search engines (Google) and is, at least, well-defined and
>well-understood in modern urban society.
>
>
>Andrew Daviel
>Vancouver Webpages
>
>
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/geopriv

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

                      Alas, few *truths* exist without the math.

                             ...all else is a matter of perspective

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