[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is the IP layer the right place to support location information
Hi,
There is no question that broad availability of spatial information on the
Internet (including both mobile and stationary devices) is important. This
includes location of course, but also information about extent and a host of other
spatial relationships. We have proposed encoding standard for such information
based on XML called GML. You can find a description of GML at
https://feature.opengis.org/rfc11/GMLRFCV1_0.html. Note that a single global
specification of even a simple idea like location is not possible since it is
truly application specific. A notion of location suited to one application is not
suited to another. None of this information in my view belongs anywhere but in
the application layer. Of course there will be cases where application information
might be used to control the network - but that does not mean that the information
itself should be encoded in lower network layers.
Ron Lake
rlake@galdosinc.com
EXT Albert Godfrind wrote:
> "C. Wegrzyn" wrote:
> >
> > I tend to disagree with the assessment provided here. In fact there are very
> > real needs for position location even with non-mobile devices. I doubt the
> > example about bus schedules is all that useful - this same thing can be done
> > very simply without resorting to anything else: the user can go to a website
> > and select the location (since it might very well be somewhere else other
> > than the location of the mobile device doing the request).
>
> 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.
>
> But then again, those considerations are not too relevant for the
> subject at hand, I realize.
>
> > The example I think as most useful has to do with hosting content.
> Right now
> > if I go to www.microsoft.com, I tend to traverse the entire network until I
> > end up in Redmond. Now image a situation like Disney or MSNBC or maybe even
> > the Victoria Secret show - the entire network clogs up with traffic to a set
> > of clustered machines. If we have positioning information in the system, in
> > other words I am at a machine in Boston, I can construct a DNS environment
> > that could factor in the location and identify a machine that can stream the
> > content to me, one that is closer. Of course this means that MS or Victoria
> > Secret might have to have multiple machines around the world, and stream
> > content (or maintain them in real-time), but the end result is that the
> > network load is more evenly distributed.
>
> Here again, I have to take exception. The efficiency of the network -
> the bandwith effectively available between two end-points (the Microsoft
> site and your own machine) has nothing or very little to do with
> geographical location and all to do with the topology of the network,
> specifically the path taken by the packets to travel between the
> end-points.
>
> 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 ...
>
>
> > Take it for what it is worth...
> > Chuck Wegrzyn
> >
> > ----- Original Message -----
> > From: EXT Albert Godfrind <agodfrin@fr.oracle.com>
> > To: EXT Sharman,Richard <richard.sharman@roke.co.uk>
> > Cc: <ext-ip-location@research.nokia.com>
> > Sent: Wednesday, January 12, 2000 3:25 AM
> > Subject: Re: Is the IP layer the right place to support location information
> >
> > Sharman,Richard wrote:
> >
> > > Also, I agree that the requirement itself hasn't been totally
> > articulated.
> > > The evidence of the archive on this discussion group is ambiguous. On the
> > > one hand it would be nice to have a few specific examples of services with
> > a
> > > compelling commercial justification, from which some generic capability
> > > requirement could be extracted. Of course, if the business case is too
> > > compelling it could lead to some short term, proprietary solutions which
> > > might not be best in the long run. Again, this needs amplification.
> >
> > I don't know that there is a definite need for locating devices
> > generally, but there sure is a business opportunity for providing
> > location-dependent services to mobile devices. Note however the specific
> > environment:
> >
> > - this opportunity concerns MOBILE devices, i.e. today generally GSM
> > phones, preferably WAP-enabled, and soon more complex devices (palmtops,
> > etc). That topic is already being covered by the WAP and W3C consortia.
> > Note that a joint workshop in february is going to cover those issues
> > (see http://www.w3.org/Mobile/posdep-workshop).
> >
> > - this opportunity concerns the delivery of information or the access to
> > services that are dependent on the current position of the mobile
> > device. For instance, the scheduled time for a bus to pass next at the
> > nearest bus stop, or the nearest hotel with rooms available in my price
> > range, etc.
> >
> > Adding a location capture/transport capability into the IP protocol
> > stack would enable those services on a more general basis. However, the
> > vast majority of IP devices today are static - i.e. they do not move:
> > they sit on a desk somewhere. [Of course, the laptops are "mobile" in a
> > way - but not really so when you compare them with a GSM phone. Plus
> > laptops only connect to the network today when they are stable - i.e. in
> > some office or home or hotel room or other well-known fairly static
> > location.]
> >
> > I doubt that the opportunity for providing location-dependent services
> > or information to static devices exists. After all, you know where you
> > are. If you need to order something from some web service (say a book),
> > you just supply the delivery address yourself manually. Or the supplier
> > already knowe your delivery address because he holds it on file ... Why
> > would it depend on your physical location ? As for location for
> > emergency services, I personally would not want to depend on my laptop
> > or workstation to direct help to me ...
> >
> > This is different for mobile devices, where you are out on the street
> > somewhere, possibly don't know where you are, and are moving (walking,
> > in a car, on a train, etc).
> >
> > The situation may well change in the future if we move in the direction
> > of IP being THE ubiquitous transport for EVERYTHING (i.e. each and every
> > device has an IP address). Location information at the IP level then
> > becomes more meaningful - but again under the assumption that devices
> > are mobile. Even if my fridge has an IP address, I still know where it
> > is. On the other hand, if my TV remote control does have an IP address
> > and includes a device that is able to advertise its location, then that
> > would help in finding the damn thing under the sofa ;-)
> >
> > /albert
> > --
> > Albert Godfrind Oracle Data Server Division
> > Oracle Corporation Multimedia and GeoSpatial Technologies
> > C.I.C.A Email: agodfrin@fr.oracle.com
> > 2229 Route des Crêtes Phone: +33/4/92.94.21.37
> > 06560 Sophia-Antipolis Mobile: +33/6/09.97.27.23
> > France FAX: +33/4/92.94.21.45
> > http://www.oracle.com
>
> --
> Albert Godfrind Oracle Data Server Division
> Oracle Corporation Multimedia and GeoSpatial Technologies
> C.I.C.A Email: agodfrin@fr.oracle.com
> 2229 Route des Crêtes Phone: +33/4/92.94.21.37
> 06560 Sophia-Antipolis Mobile: +33/6/09.97.27.23
> France FAX: +33/4/92.94.21.45
> http://www.oracle.com
begin:vcard
n:Lake;Ron
tel;cell:604-657-0756
tel;fax:604-687-1837
tel;work:604-687-7311
x-mozilla-html:TRUE
url:www.galdosinc.com
org:Galdos Systems Inc
adr:;;#1360 605 Robson Street;Vancouver;British Columbia;V6B-5J3;Canada
version:2.1
email;internet:rlake@galdosinc.com
title:President
fn:Ron Lake
end:vcard