RE: Forward/backward compatibility

Andrei,

Your response to this email is helpful to me in understanding where you are coming from.  Unfortunately, it also indicates that there is a serious misalignment in expectations.

I refer in particular to this:

> > -- A fixed-line ISP that has a database of service addresses that
> they offer
> > as a location provider
> 
> I'm not sure I understand this example, can you please explain?

I'll explain.  As Aza pointed out [1], location is one aspect that people tend to associate very strongly with the "mobile" web.  And this is where I see your misunderstanding arising from.  You are thinking of GPS, or some other form of radio-based location determination method (TDOA, trilateration, etc...).  Naturally, you think that this is the way that a "device" will acquire location.

This doesn't consider the fact that the majority of web devices do not use radio communications.  Most are in fact sitting on desktops, using a wire for communications.

How does a wired device get location information?  This is easy - manually.  The simplest method is where the person at the computer tells the computer where it is.  What does a person know?  Rarely geodetic, particularly indoors (a common place for such devices) where GPS signals are badly attenuated, often to the point of being non-existent.  Most often it’s a street address that the person knows.

Take this a step further back and remove the responsibility from the user.  Now the person operating the network does the work.  In an enterprise, the admin makes a database that has the location of each of the data ports in the network.  If it were a DSL or cable network, the admin uses the billing address information provided by you (or the LEC - the person who owns the cable plant) and puts that in a database.  Now the information is managed by the network operator and made available over their network to each device attached to that network.

This is the basis for the location configuration protocol (LCP) work in GEOPRIV.  We are defining a protocol for the acquisition of location information from the network provider.  That's HELD [2].

Of course, none of this removes the fact that a person creates and manages the information.  And civic addresses work.

Hence the continued discussion on civic address support.  For those of us that have this background, geodetic is only part of the picture.

What do you do when you have only one type of information and not the other?  Well, I suspect that (reverse-)geocoding will become more popular as time goes by.  That doesn't mean that it needs to be forced on browser implementations--or, more likely, location provider implementations.

I am of the opinion that the current approach is likely to have the opposite effect to what is intended - that is, it will reinforce the fragmentation of the "mobile" and "fixed" webs simply because mobile devices will have geodetic, fixed devices will not.  What Richard proposed is robust, not as hard to manage as you make it out to be (the difference between position.latitude and position.geodetic.latitude is so subtle as to be irrelevant), and it means that you don't force v2 implementations to support geocoding by forcing them to provide geodetic information.

Cheers,
Martin
 
[1] <http://www.azarask.in/blog/post/geolocation-in-firefox-and-beyond/>
  See also Mitchell's keynote - she says the same thing more eloquently.
[2] <http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery>

------------------------------------------------------------------------------------------------
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]

Received on Thursday, 13 November 2008 22:08:53 UTC