Re: Is the IP layer the right place to support location information

[EXT Johan Hjelm <hjelm@w3.org>]

2 cents on this: 

You make some assumptions about the protocol and the use of the data below,
that need to be highlighted because it can be misleading if you do not. 

The first assumption is: What is it used for? An information retrieval
scenario assumes that you query (a database, a web page) and recieve a
response (with relevant information) in most cases (there are different
models, see below, but I do not think that is a practical approach). 
Queries for information are not continous, but discrete events (following a
request-response model). This also goes for the assumption that you present
a (simulation of) continous motion to the user. If the position information
is used within the device (for instance, parametrized queries to a local
database), the request-response model still works, albeit with a lot
shorter time periods (concievably, you could do it 24 times a second - the
user will not be able to tell that from continous motion - a typical movie
demonstrates this). 

However, if the position information is used for something else than
providing information to the user (e.g. keeping track of a heart transplant
transport), you could assume that you would need a continous update of the
information. However, if you assume that the device will continously
broadcast (or unicast, does not matter) its location to somewhere, a small
number of devices will quickly download any concievable network. 

At 16:16 2000-01-12 +0100, EXT Albert Godfrind wrote:
>I see what you mean, Chuck. However, there are several difference
>between a "mobile" and a "static" device. "going to a website" - the
>obvious answer for a static device - does not work for a mobile device.
>The mobile device is used on the street, while walking or just standing
>at a street corner, sitting in a moving vehicule (hopefully not while
>driving it ;-), and the questions asked tend to be of immediate use, and
>concern very local services. Hence the bus example: I want to know the
>time and destination of the next bus that passes the stop I am standing
>at - not the time table of buses in the city I will be visiting tomorrow
>(for which the "website" approach is OK). In addition, mobile devices
>have limited capabilities in terms or user interface (small screen,
>small keypad or touchpad) and are used in uncomfortable conditions, so
>require an underlying infrastructure that is able to filter, select and
>organize available services to minimize the interaction. 
>

You are assuming that you implicitly query something (a database?) for the
bus information. How is that different from the request-response model I
describe above? You have to come up with different usecases, if you are to
motivate a different model. You do not "go to a website", true, but you may
well go to a WAP site. The request-response model holds anyway, especially
if you parametrize your query with the position information.
 
There is a different model: Everyone in your vincinity who has information
continously broadcasts it, and your device filters out what is relevant.
But in that case, you strictly speaking do not need to know your position,
since you only filter out what is available in your local area. This is an
interesting research topic and could carry us very far from what we ought
to be discussing. 

>But then again, those considerations are not too relevant for the
>subject at hand, I realize.
>

On the contrary! This discussion need still constrain its unique
boundaries. I have not yet seen any evidence for why the IETF should do this. 

>
>A case in point: I am based in France. Like everyone, I download stuff
>from public internet sites. Many sites let you choose a mirror to
>download from. In almost all occasions, it is faster for me to pick US
>sites rather that a mirror site that could be thought of as local -
>geographically closer. This is because the topology of our internal
>corporate network combined with that of the internet is such that for
>the most US sites are closer in terms of packet travel time, than
>geographically closer systems ...
>
> 

Yes, that would come in handy. However, location in terms of network
topology is very different from location in spatial terms (and may well be
something the IETF *should* discuss!)

Johan

************************************************************
                         Johan HJELM
      Ericsson Research, User Applications Group 
         Currently visiting engineer at the W3C
Chair, CC/PP Working Group and WCA Interest Group
             The World Wide Web Consortium
                         hjelm@w3.org
   http://www.w3.org/People/W3Cpeople.html#Hjelm
    Fax +1-617-258 5999, Phone +1-617-253-9630
   MIT/LCS, 545 Tech. Sq. Cambridge MA 02139 USA 
        Opinions are personal, always my own, 
  and not necessarily those of Ericsson or the W3C. 
============================================================