Subject: RE: AW: [Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-lo -profile-00

From: "James Winterbottom" <[email-masked]>
Date: Wed, 13 Jul 2005 10:58:48 +1000

I agree with Marc's comments about the cost of providing Civic, I think that
it is going to be way out there.

I agree with the Marc's comments on the altitude component in WGS-84 and
like, and I think that the draft more or less says exactly that.

For now I would like to leave floor in, and allow the definition of a
location complex consisting of a geo area and a floor number. If more
compelling arguments come to light as to why we should remove this I am
happy to listen.

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Marc Linsner
Sent: Wednesday, 13 July 2005 9:38 AM
To: 'Brian Rosen'
Cc: 'GEOPRIV'
Subject: RE: AW: [Geopriv]
Quickrandomcommentsondraft-ietf-geopriv-pdif-lo-profile-00

In-line... 

> I don't understand this question.

Civic has all the problems, plus associated costs ($$), that we've been
discussing for over 2 years. Ambiguity. Geo is not ambiguous.

> 
> First of all, it is far easier to use civic in a multistory
> building -- 35th floor, suite 3510, Room 25 (or cubicle 
> 25-6).

As long as I state it in your format, then verify that your format doesn't
change at some frequency prescribed by you.  Hence, my statement that civic
has baggage associated with it.

 Certainly, until we get accurate floor plans, 
> accurately aligned to GPS coordinates, we would strongly prefer civic.
> 
> Secondly, if you do have a way to measure accurate lat/lon
> inside a multistory building, you could get accurate altitude.

Not necessarily.  Besides, take your GIS system and tell me what floor
equates to 83.4 meters?

-Marc-

> 
> For the foreseeable future, if your device measures lat/lon,
> by all means send that.  If not, please send civic.  Never 
> convert.  If you know you are on the 35th floor, in Suite 
> 3510, Room 25, and you are looking at some sort of map that 
> would tell you what the lat/lon is, you are converting.  
> Don't do that. If you have a WiFi mechanism that is 
> triangulating, and the only reasonable output is lat/lon, 
> please make darn sure your base station location is accurate, 
> and send geo.
> 
> Brian
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Marc Linsner
> Sent: Tuesday, July 12, 2005 4:59 PM
> To: 'Henning Schulzrinne'; 'Tschofenig, Hannes'
> Cc: 'GEOPRIV'
> Subject: RE: AW: [Geopriv] Quick
> randomcommentsondraft-ietf-geopriv-pdif-lo-profile-00
> 
> Henning,
> 
> > 
> > Given that we have very limited deployments (to put it
> > generously) of either civic or geo options, another path forward to
> > consider: Deprecate the use of floors in the geo DHCP 
> option and don't
> > carry it in PIDF-LO unless it is part of the full civic option.
> > Logically, floors were always a bad fit for the geo option, but 
> > necessary until we had others.
> > 
> > The geo floor option has known problems (cannot represent certain
> > floors) and I can't picture a scenario where the floor (and
> > geo) is known, but the street address isn't. Having to
> merge floor and
> > country information from geo and civic just adds complexity
> and error
> > cases, for no increase in functionality.
> > 
> 
> I can't agree with 'Deprecate the use of floors in the geo
> DHCP option and
> don't carry it in PIDF-LO unless it is part of the full civic option.'
> 
> With all the extraeous baggage associated with supporting
> civic addresses,
> why would you want to force the operator of a multistory 
> building to support
> only civic???
> 
> Geo is simply easier/cheaper to support.
> 
> -Marc-
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked] https://www1.ietf.org/mailman/listinfo/geopriv
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked] https://www1.ietf.org/mailman/listinfo/geopriv

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

---

From: "James Winterbottom" <[email-masked]>
Date: Thu, 14 Jul 2005 09:24:58 +1000

This means that I should now provision both, something I see as unnecessary.
The problem that I see with Civic is that to use it for routing it needs to
be validated to ensure that it will provide a valid route (for those people
familiar with NENA I2 you will know what I mean). The same is not true for
geo. In the situation that we have discussed so far, the floor component is
as I see it ancillary information for people receiving the location, rather
than a critical component for routing (I am not aware of anywhere that
routes based on the altitude). The argument that seems to be being waged is
more civic vs geo which is silly, each has their own place, advantages and
disadvantages.

I agree with Marc that the floor makes sense and is useful when applied to a
geo location irrespective of other civic information.

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henning Schulzrinne
Sent: Thursday, 14 July 2005 8:52 AM
To: Marc Linsner
Cc: 'GEOPRIV'
Subject: Re: AW: [Geopriv]
Quickrandomcommentsondraft-ietf-geopriv-pdif-lo-profile-00

Let's get away from the deprecate discussion. A more productive 
discussion for the pidf-lo profile is to tell people what to do. My 
suggestion is that people should, for buildings where floor information 
is desired, provide both civic and geo information in DHCP and PIDF-LO, 
and send a LO that includes useful, complete information for both. This 
maximizes utility to the receiver and has no incremental cost.

Marc Linsner wrote:
>>However, altitude expressed in floors within a geo is an idea
>>whose time will never come.
>>
> 
> 
> I disagree, but if this is the case, why deprecate?
> 
> -Marc-
>

---

From: "James Winterbottom" <[email-masked]>
Date: Fri, 15 Jul 2005 07:47:34 +1000

Let me go away and read RFC-3825 again (spent a lot of time reading it a
week or so back), but it does have the notion of partial floors, as floors
are still expressed as decimal number. I am pretty sure that examples are
used also. They are however as explicit as the subfloor-basement B.

Henning, are you suggesting that if we do a DHCP request and a DHCP request
for Geo that we put the results into the same
tuple->status->GeoPriv->location-info?

My preference would be for there to be two tuples in this case, one for the
Geo and one for the civic, since they were provided with separate requests.
This being the case, I see a need for both. The selection of which location
to actually use in any PIDF-LO can then be addressed with the earlier rules.

---

From: "James Winterbottom" <[email-masked]>
Date: Fri, 15 Jul 2005 09:39:59 +1000

In Line

>They are however as explicit as the subfloor-basement B.
>
>Henning, are you suggesting that if we do a DHCP request and a DHCP
>request for Geo that we put the results into the same 

If a client requests a DHCP Option 123, the client will get a 3 axis geo 
back (if altitude is known. There is no civic here.

AJW-- If the altitude is expressed as floors, then yes you do have a civic
component. This in my opinion MUST be represented inside the same
location-info element. That is, the same location-info element will contain
a Geo for Lat Long, AND a civic detailing the floor.

If this is the only "location" a client knows - Henning - are you asking
for:

AJW-- We need to be very careful what we mean by a PIDF-LO here. Do you mean
2 location types in the same location-info element, 2 GeoPriv elements in
the same tuple->status, 2 separate tuples, or two PIDF documents? 

1) two PIDF-LOs (one for geo, and one just for the <FLR/> element)?

2) one PIDF-LO - with a full vert/hor gml elements and altitude in the 
separate gl elements?

3) something else?

>My preference would be for there to be two tuples in this case, one for 
>the Geo and one for the civic, since they were provided with separate 
>requests.

I think Henning is asking for two of your tuples from the same DHCP Option 
123 reply - and I don't like that.

AJW-- Not quite sure that I agree here, isn't the Civic DHCP draft going to
have its own DHCP option?.. My suggestion and thoughts are that one option,
1 location-info element, that is ONE GeoPriv status element.

>This being the case, I see a need for both. The selection of which 
>location to actually use in any PIDF-LO can then be addressed with the 
>earlier rules.
>
>

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "James Winterbottom" <[email-masked]>
Date: Fri, 15 Jul 2005 10:45:43 +1000

The example is spot on with the exception of where you have put method, it
resides outside the location-info. This is what I would support.

If I had also requested a DHCP Civic address then I would place this in a
separate tuple but inside the same PIDF document. That is, my PIDF would
contain two tuples, one for each location. The first tuple would be as shown
in your example, the second tuple would be the full civic.

Does that clarify things?

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Friday, 15 July 2005 10:33 AM
To: Winterbottom, James [WOLL:5500:EXCH]
Cc: 'GEOPRIV'
Subject: RE: AW: [Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-lo
-profile-00

At 09:39 AM 7/15/2005 +1000, James Winterbottom wrote:

>If a client requests a DHCP Option 123, the client will get a 3 axis 
>geo back (if altitude is known. There is no civic here.
>
>location-info element. That is, the same location-info element will 
>contain a Geo for Lat Long, AND a civic detailing the floor.

so, under gml 3.0 speak (gml 3.1 replaces "point" with "pos" for position), 
you would produce something like this (subset) from a DHCP Option 123 Reply 
(I start at the status line, and omit all others above and below for
brevity):

<status>
  <gp:geopriv>
   <gp:location-info>
    <gml:location>
     <gml:Point gml:id="point96" srsName="epsg:4326">
       <gml:coordinates>33.001111N
                 96.68142W</gml:coordinates>
     </gml:Point>
    </gml:location>
    <method>dhcp</method>
    <gml:location>
    <cl:civilAddress>
     <cl:FLR>2</cl:FLR>
    <cl:civilAddress>
    <method>dhcp</method>
   <gp:location-info>
  <gp:geopriv>
<status>

[I also purposely left out the retention and distribution elements]

Or would you want to create a larger PIDF-LO with more information within 
the Civic location-info portion of the message body?

>If this is the only "location" a client knows - Henning - are you 
>asking for:
>
>AJW-- We need to be very careful what we mean by a PIDF-LO here. Do you
>mean 2 location types in the same location-info element, 2 GeoPriv 
>elements in the same tuple->status, 2 separate tuples, or two PIDF
documents?

this is what's not clear to me - which is the reason I give a partial 
example above to discuss.

> >My preference would be for there to be two tuples in this case, one 
> >for the Geo and one for the civic, since they were provided with 
> >separate requests.
>
>I think Henning is asking for two of your tuples from the same DHCP 
>Option 123 reply - and I don't like that.
>
>AJW-- Not quite sure that I agree here, isn't the Civic DHCP draft 
>going
>to have its own DHCP option?.. My suggestion and thoughts are that one 
>option, 1 location-info element, that is ONE GeoPriv status element.
>
> >location to actually use in any PIDF-LO can then be addressed with 
> >the earlier rules.
> >
> >
> ><https://www1.ietf.org/mailman/listinfo/geopriv>https://www1.ietf.org
> >/mai
> lman/listinfo/geopriv
>
>cheers,
>James
>
>                                  *******************

cheers,
James

                                 *******************

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 14 Jul 2005 20:12:04 -0500

At 10:45 AM 7/15/2005 +1000, James Winterbottom wrote:

>resides outside the location-info.

oops - of course it does

>This is what I would support.
>
>contain two tuples, one for each location. The first tuple would be as 
>shown in your example, the second tuple would be the full civic.
>

Now at least, you and I know what each other is talking about. I hope 
others do too. From this we can discuss a common thing.

>From: James M. Polk [<mailto:[email-masked]>mailto:[email-masked]]
> > ><<https://www1.ietf.org/mailman/listinfo/geopriv>https://www1.ietf.org/ 
> mailman/listinfo/geopriv>https://www1.ietf.org
> > >/mai
> > lman/listinfo/geopriv
> >
> >cheers,
> >James
> >
> >                                  *******************

cheers,
James

                                 *******************

---

From: "Tim Dunn" <[email-masked]>
Date: Sat, 16 Jul 2005 15:39:04 -0600

The issue, again, is routing a call to a Primary PSAP.  The Primary PSAP is assigned based upon an X and Y (or a civic address) of a particular point on the ground.  When that PSAP receives the call, there is a determination of what unit is to be dispatched to that address.  It is in the determination of response (fire, medical, law enforcement) where the -z becomes important, so the first responder can find out the problem and ask for other help.  

To the best of my knowledge, there isn't a federal PSAP that is wanting/waiting for the routing of a 911 call because the Dept. of Transportation office on the 4th floor (or the mezzanine or garden level or whatever it is called) of a building which is half office, half hotel has called for medical assistance, fire or because of a crime in progress.  The responding unit is a First Responder (police, fire or EMS) who is dispatched by a dispatcher who has received a request from the Primary PSAP as a result of that 911 call.  The first response unit is based upon written agreements or local custom knowing what is in that building and the nature of the call.  I agree, -z is needed to be unambiguous as a part of the information delivered to the RESPONDER.  In the emergency models, I don't believe routing decisions require -z, but it is nice/critical to have it when the call data are displayed at the PSAP.  

In the commercial model (pizza delivery person) you seem to imply the 5th floor would want to be routed to a different Pizza Hut than the 4th floor.  I'll suggest both floors want their call routed to the same Pizza Hut.  And, -z is not as critical in this model as typically the Pizza Hut call answerer (by their training) is going to validate the location on their screen with the caller.  

Now, in both emergency and commercial models, here's where the meters versus floors discussion comes into play.  From the Pizza example, do I want my pizza on the 4th floor, mezzanine or 135 meters above ground (so at 3 meters average level of a floor, that would be the 41st floor) or 6000 feet above sea level?  I'll suggest that this type of resolution is actually done by the calltaker ("What floor/room can we deliver your pizza, sir?"), not by any location determination method.  In the emergency situation, again, things are different because a caller may be unconscious and unable to respond to the "what floor are you on" question.  It is much better to tell the responder "garden level" or "41st floor" or "check floors 1-5".  135 m above ground tells them nothing (unless they have an altimeter with them).

Tim

  ----- Original Message ----- 
  From: Brian Rosen<mailto:[email-masked]> 
  To: 'Tim Dunn'<mailto:[email-masked]> ; 'Henning Schulzrinne'<mailto:[email-masked]> ; 'GEOPRIV'<mailto:[email-masked]> 
  Cc: 'Marc Linsner'<mailto:[email-masked]> ; 'James M. Polk'<mailto:[email-masked]> 
  Sent: Saturday, July 16, 2005 1:44 PM
  Subject: RE: AW:[Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-lo -profile-00

  The world is changing.  Technology makes things possible now that wasn't
  possible before.  Just because that's not the way we do it now, doesn't mean
  we don't want to; often it's because we couldn't.  In this case, I don't
  think we are arguing we want to wholesale change routing of emergency calls
  in North America.  I think we are asking that it be possible to route based
  on, among other things, z.  I don't think we have to optimize for it; just
  make it possible.  To route, or to respond, we need z to be unambiguous;
  whatever assumptions were made by the creator of the location information
  has to result in the user (router, dispatcher, responder, pizza delivery
  person,.) being able to get to the right place.  I think we want response to
  be reasonable without requiring information that cannot reasonably be known
  to the responder, and we have to assume they are not from the same
  organization.  Without some kind of mapping to, I guess, strings, it's not
  possible to use RFC3825 Altitude value when AT=2.  It is possible if you
  just always make altitude meters.  

  This is why propagation of the RFC3825 AT=2 option seems, to me, to be a bad
  idea.    On reflection of the needs for routing and responding to multistory
  buildings, where there is no reasonable way to interpret the value of the
  altitude by the contents of the Altitude field when AT=2, without
  information which seems difficult to assume the recipient can get, I
  conclude it was a nice idea that doesn't work; we should not use it, and we
  should not copy it into PIDF-LO.   I see no need to revise RFC3825.  I just
  don't want to see the mu=floors option in PIDF-LO.

  Brian

  ________________________________________
  From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf
  Of Tim Dunn
  Sent: Friday, July 15, 2005 11:40 PM
  To: Henning Schulzrinne; GEOPRIV
  Cc: Marc Linsner; James M. Polk
  Subject: Re: AW:[Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-lo
  -profile-00

  First let me introduce myself to the list. My name is Tim Dunn. I
  currently operate my own consulting firm, but was a principal product
  manager for Openwave/Signalsoft during the time the wireless location
  standards for emergency services were being promulgated and then implemented
  in the US. Prior to that, I was a PSAP manager for the City and County of
  Denver. I maintain my standing within various NENA technical committees,
  having participated in those committees for some 7 or more years and have
  participated in various FCC, ATIS, ETSI and other forums.

  I've been watching this thread over the past couple of days and find I have
  to respond. As a point of reference, in Denver, we had a building (a movie
  theatre) which had the lobby in Denver, and the theater itself in a
  neighboring jurisdiction. In cases such as these (to include WTC, the
  Interchurch Building and the like) there are typically agreements which have
  been set in place which discuss who is the first responder to a particular
  address, such as this movie theatre. 

  Neighboring jurisdictions spend a great deal of time determining who is the
  first responder for whole addresses, corresponding to the city, county and
  sometimes state boundaries, not who occupies floors 1, 3 and 4 of a
  building. If there is some sort of question as to which jurisdiction
  responds, the PSAP that is responsible for answering that call generally has
  responsibility for getting that call to a dispatcher who can send the
  correct unit(s). This would be local police, fire or EMS or some other
  response arrangement such as mutual aid or calling the FBI or University
  Police or whatever arrangement has been agreed upon.

  So, I'll suggest from the perspective of routing the call to the PSAP,
  routing on -z is not critical. It is much more critical to provide as
  accurate a -z as possible (be it attached to Geo or Civic message format) to
  the PSAP calltakers' screens so they can provide it as a more granular
  location to the responding unit when they arrive. 

  Tim Dunn
  Timothy N. Dunn Consulting
  [email-masked]<mailto:[email-masked]>

  ----- Original Message ----- 
  From: Henning Schulzrinne 
  To: James M. Polk 
  Cc: GEOPRIV ; Marc Linsner 
  Sent: Friday, July 15, 2005 9:00 PM
  Subject: Re: AW: [Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-lo
  -profile-00

  I don't know how to estimate this percentage, but I have a local 
  example: Columbia University occupies part of a building called the 
  Interchurch Building on 125th Street in Manhattan (called that since it 
  is also occupied by the HQ offices of a number of Christian 
  denominations). In that particular case, they are actually spread across 
  non-adjacent floors and maybe even partial floors.

  We discussed other examples, such as high-security or clandestine 
  installations in large office buildings. (The "classical" example were 
  the offices of the ATF and CIA in the WTC.)

  I agree that this is not likely to be common, but not terribly difficult 
  to support, either, should the need arise in the future. Given that 
  z-level information is carried in both civic and geo-derived formats, I 
  don't see much of an issue should somebody decide to factor that into 
  making routing decisions.

  Henning

  James M. Polk wrote:
  > At 12:42 PM 7/15/2005 -0400, Brian Rosen wrote:
  > 
  >> Henning has given examples where routing is dependent on z. One is 
  >> where you have an enterprise, which could be a university, which has 
  >> its own response capability. The enterprise could occupy a portion of 
  >> a high rise.
  > 
  > 
  > ok... so what is the percentage of these cases really?
  > 
  > How often will z be a factor in the routing decision?
  > 
  > A tenth of a percent of all 911 calls made?
  > A hundreth of a percent?
  > a ten-thousanth of a percent?
  > even less of a percent?
  > 
  > We're engineers who want to build an architecture as good as we can, but 
  > we can't take the case of the above percentages of a chance to steer our 
  > efforts. That's attempting to achieve too much without the imperical 
  > evidence of experience to make those decisions.
  > 
  > I'm a statistician by nature, and I deal in Standard Deviations, and 2 
  > is a good number to work towards, 3 is excellent, and 5 is unrealistic. 
  > The percentages above are getting past 4 SDs and up towards (and past) 6 
  > SDs.
  > 
  >> Brian
  > 
  > 
  > 
  > cheers,
  > James
  > 
  > *******************

  _______________________________________________
  Geopriv mailing list
  [email-masked]<mailto:[email-masked]>
  https://www1.ietforg/mailman/listinfo/geopriv<https://www1.ietforg/mailman/listinfo/geopriv>