headers
Kanai | 3 Jul 2002 02:19
Favicon

New I-D: Geopriv Service Scenarios

Folks,

I have submitted an Internet Draft, "Geopriv Service Scenarios"
(draft-kanai-geopriv-scenarios-00.txt).

ftp://ietf.org/internet-drafts/draft-kanai-geopriv-scenarios-00.txt

It introduces some Location-based service scenarios for Geopriv. 
I hope this will be a starting point of discussing Use Cases.
Any comments or suggestions are welcome.

Best,

---
Go Kanai <kanai.go <at> jp.fujitsu.com>
Fujitsu Laboratories, Japan
Permalink | Reply | 0 comments |
headers
Scott Keagy | 4 Jul 2002 01:28
Picon
Favicon

Geopolitical vs. geospatial location definition

Where do you all see as the most appropriate place to specify a location 
format required to support a specific application? In thinking in 
particular about E9-1-1 support in North America, and the location formats 
specified by the National Emergency Numbers Association in the document 
NENA 02-010:
         http://nena.org/9-1-1TechStandards/Standards_PDF/NENA_02-010.PDF

(Ignore the parts that don't refer to street addresses and bldg/room/floor 
location description).

As another example of emergency location information format (that is 
different because of country-specific methods of describing a street 
address and location) , take a look at the IPND in Australia:
         http://www.telstra.com.au/ipnd/docs/Ipndus1.1.7.pdf

I'm sure the CGALIES folks in Europe will come up with a different version 
for E1-1-2 (which will be more challenging given the number of countries 
and street address formats encompassed there)... not to mention every other 
part of the world that establishes an emergency location identification 
mechanism.

There is a real need for a geopolitical reference for location info, rather 
than just lat/long/alt. Consider that a police officer responding an 
emergency from a university dorm room may have a difficult time using the 
lat/long/alt to find the correct room (even if the accuracy and precision 
is good enough).  I suspect there is a general class of applications that 
would like a geopolitical location reference as opposed to a geo-spatial 
location reference. We can call that area out of scope for us, and rely on 
other black boxes to translate lat/long/alt to street addresses or other 
location formats, but this is something that I think makes more sense to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Henning Schulzrinne | 4 Jul 2002 10:03

Re: Geopolitical vs. geospatial location definition

There is an additional reason that civic location (I think that's the 
term...) are needed - in many cases, such as the location of network 
devices in offices, location information will need to be entered by 
humans, which are very unlikely to get long/lat right. It is also easier 
to provide human-meaningful imprecision in that space. For example, 
providing a postal code, city or country is all that's needed for 
demographics or other identification purposes, but this doesn't 
correspond neatly to any easily-specified boundary in long-lat. This 
also avoids some of the need for various randomization and fudging 
techniques. Specifying "New York" instead of having to specify random 
points within the five boroughs seems much easier for a human to observe 
and trust. (How would I know that my device isn't just accidentally 
providing random long/lat that (in)conveniently average out to my 
precise location?)

Scott Keagy wrote:
> Where do you all see as the most appropriate place to specify a location 
> format required to support a specific application? In thinking in 
> particular about E9-1-1 support in North America, and the location 
> formats specified by the National Emergency Numbers Association in the 
> document NENA 02-010:
>         http://nena.org/9-1-1TechStandards/Standards_PDF/NENA_02-010.PDF
> 
> (Ignore the parts that don't refer to street addresses and 
> bldg/room/floor location description).
> 
> As another example of emergency location information format (that is 
> different because of country-specific methods of describing a street 
> address and location) , take a look at the IPND in Australia:
>         http://www.telstra.com.au/ipnd/docs/Ipndus1.1.7.pdf
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ricardo Cuellar | 14 Jul 2002 08:56
Picon

Requirements draft: issues

All,

This is the current list of issues identified in the draft
<draft-ietf-geopriv-reqs-00.txt>.

The goal of this list is to identify the changes required to furhter
advance this document. Please submit comments to the presented issues,
or send more issues to the mailing list.  Please refer to the text in
the draft that relates to the issue. If possible, supply also the
suggested text that you would like to see.

Regards,

Jorge

---------  Out of town: -------------
    Fax & Voicebox: +49 (0) 12125-130-30-549 
    JorgeRicardo <at> web.de

################################################

Status of issues:
<Cl>: Closed, changes are reflected in the current verion of the draft
<Se>: Settled, but text in the draft is missing
<Op>: still open

Terminology
===========

I <Cl> 1.  Use of the word "user" at beginning of the draft
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henning Schulzrinne | 17 Jul 2002 13:44

Location Requirements - multicast

Another facet of this that it must be possible to include the location 
object in multicast-based using protocols. An example is a location 
beacon (e.g., imagine an 802.11 base station that announces its location.)

> 	3. The "geopriv protocol" needs to be at most a single packet
> 		exchange.  The first transaction in a tracking application
> 		could be more than this, but we need a low overhead
> 		mechanism for incremental updates
Permalink | Reply | 3 comments |
headers
Eric Brunner | 17 Jul 2002 20:28
Picon
Picon
Favicon

Re: Location Requirements - multicast

Henning,

I'll piggyback two comments.

I agree that multicast is desirable.

I agree that single packet is desirable.

Both of these are at odds with xml-over-a-unicast-connection.

Eric
Permalink | Reply | 2 comments |
headers
Henning Schulzrinne | 18 Jul 2002 01:48

Re: Location Requirements - multicast

I'm hoping that the architectural model is such that the location object 
is completely independent of properties of the using protocol(s), be 
these protocols designed expressly for geopriv (if any) or others. In 
particular, there should be no assumption that any using protocol is of 
the request-response variety.

Eric Brunner wrote:
> Henning,
> 
> I'll piggyback two comments.
> 
> I agree that multicast is desirable.
> 
> I agree that single packet is desirable.
> 
> Both of these are at odds with xml-over-a-unicast-connection.
> 
> Eric
Permalink | Reply | 1 comment |
headers
James M. Polk | 18 Jul 2002 02:11
Picon
Favicon

Re: Location Requirements - tracking

At 07:39 AM 7/17/2002 -0400, Rosen, Brian wrote:
>I would appreciate seeing a requirement that the object support
>tracking.  This has several implications:
>	1. The object may have to have a particularly small form
>		tracking is often used on a small device
>	2. We may want to specify a delta format in addition to an
>		absolute
>	3. The "geopriv protocol" needs to be at most a single packet
>		exchange.  The first transaction in a tracking application
>		could be more than this, but we need a low overhead
>		mechanism for incremental updates

I don't like this idea. It should be up to the Location Service or the
Location Seeker to calculate or determine if a subsequent Location request
is desired and then do whatever it wants with that information - be that
tracking or some other use.

In other words, the burden shouldn't be on the Target to determine a delta
- a vector and velocity perhaps as optional additional info - but not a
delta (that I can see in version 1 of this Protocol at least)

>
>Brian

cheers,
James 

              *************************************
"People generally demand more respect for their own rights than 
                         they are willing to allow for others"
(Continue reading)

Permalink | Reply | 0 comments |
headers
James M. Polk | 18 Jul 2002 02:15
Picon
Favicon

Re: Location Requirements - Data Details

At 07:29 AM 7/17/2002 -0400, Rosen, Brian wrote:
>The current requirements are pretty sparse in describing what has
>to be carried in a location.  I'd like to see some specificity,
>so that the following are accommodated:
>
>1. There must be formats for both lat/lon/altitude and "civil"
>locations

You mean "Postal", as in the street address? Shouldn't this be a valid
optional *additional* LO in the reply?
>
>2. Time of sighting (mentioned, but not a requirement)

I firmly believe the timestamp should be a requirement (using NTP)

>
>3. Motion and direction vectors

This is a good idea, but shouldn't be mandatory

>
>4. Precision (there is a more appropriate term, I forget what
>it is)

fuzziness, or fudge-factor.... I agree with this

>
>Brian

cheers,
(Continue reading)

Permalink | Reply | 8 comments |
headers
Henning Schulzrinne | 18 Jul 2002 02:29

Re: Location Requirements - Data Details

> You mean "Postal", as in the street address? Shouldn't this be a valid
> optional *additional* LO in the reply?

I'm not an addressing expert, but I believe that there is a difference 
between the two in some cases. The difference is that postal addresses 
are often "logical", i.e., expressed as PO boxes, APO/FPO, zip code 
only, etc.

Military addresses are also an example. (see 
http://www.airbornerecce.com/train/security.htm)

We often find this as the difference between the postal address and the 
"courier" address.

As a random example courtesy of Google, see 
http://www.unites.uqam.ca/tourisme/anglais/coordonnees.htm

The format is probably the same (except for PO box and similar), but we 
may need to mark what it is.

Henning
Permalink | Reply | 0 comments |

Gmane