RE: [Geopriv] Message Flow

["Marc Berryman" <[e-mail]>]

Martin,
 I do appreciate your (long-winded) response as it puts your comment
into context.
For your example I would think that the location determination used for
routing is not a major flaw, actually it is not a flaw but simply a
manner in which to route on the best available information.

I would think the PSAP would indeed to a "dynamic reassessment" based on
any new information and / or the uncertainty associated with the
location. This is exactly what happens today with a wireless call, so no
problem there. 

I would prefer we make the architecture/implementation as cost effective
and simple as possible, we can always tweak it later if needed.

Thanks for taking the time to provide the response.

Marc B

-----Original Message-----
From: Dawson, Martin [mailto:[e-mail]] 
Sent: Monday, November 26, 2007 7:40 AM
To: Marc Berryman; Winterbottom, James; Brian Rosen; Hannes Tschofenig
Cc: [e-mail]
Subject: RE: [Geopriv] Message Flow

Hi Marc,

Yes - the comment is out of context.

The (very long-winded) question is:

If the location used for routing is determined some number of seconds
earlier and possibly to less precision than the location that is
actually provided at the PSAP, and given there is some subset of
circumstances where the caller may have moved sufficiently from the
point in time at which the location for routing was determined and the
time that the location provided to the PSAP was determined that the
latter may represent a different route, would this represent a major
flaw in the architecture?

Would the PSAP do a dynamic "reassessment of routing" to see whether the
uncertainty associated with the provided location should have resulted
in the call coming to them?

In whatever (I would expect quite small) proportion of calls that this
situation would occur in, would it cause a major issue for dealing with
or assessing the call, or would the assumption simply be that perhaps
the caller moved sufficiently in the elapsed seconds to cross the
routing boundary?

Note that this has nothing to do with whether the call gets to the PSAP
or a different one. It's just a question of whether the recipient PSAP
gets the actual location that was used for routing versus one that was
determined at the time of call receipt. How complex should the
architecture/implementation be in order that the location for routing is
also provided? How big can the cost be and still provide a cost-benefit?

Cheers,
Martin

-----Original Message-----
From: Marc Berryman [mailto:[e-mail]] 
Sent: Tuesday, 27 November 2007 12:13 AM
To: Winterbottom, James; Brian Rosen; Hannes Tschofenig
Cc: [e-mail]
Subject: RE: [Geopriv] Message Flow

Re: "I am remain unconvinced however that it actually matters if the
PSAP
gets a slightly different location. Can you indicate what the
significant impact is?"

The location has a major impact on the proper emergency responders to
send to the "call", just being on the other side of a two-lane road
often makes a difference due to taxation boundaries.

Having only a slightly different location could make the difference
between sending a heavy rescue or water rescue rather than a singe EMS
or pumper fire truck.

Maybe I am taking James comment out of context, but at the PSAP LOCATION
MATTERS.

Marc Berryman


-----Original Message-----
From: Winterbottom, James [mailto:[e-mail]] 
Sent: Sunday, November 25, 2007 3:19 AM
To: Brian Rosen; Hannes Tschofenig
Cc: [e-mail]
Subject: RE: [Geopriv] Message Flow

Why?

I would just create 2 contexts, one snapshot, one not. Mark the snapshot
one as the one used-for-routing, and include the second URI for updates.

I am remain unconvinced however that it actually matters if the PSAP
gets a slightly different location. Can you indicate what the
significant impact is?

Cheers
James 



> -----Original Message-----
> From: Brian Rosen [mailto:[e-mail]]
> Sent: Sunday, 25 November 2007 2:00 PM
> To: Winterbottom, James; 'Hannes Tschofenig'
> Cc: [e-mail]
> Subject: RE: [Geopriv] Message Flow
> 
> But that wouldn't let the recipient get updated location, right?  So
it
> wouldn't generally be useful.  To be useful, it would have to have
both a
> snapshot and a "regular" reference, send both and mark them
appropriately.
> 
> The context draft doesn't match the syntax of -conveyance, which means
we
> have information loss from the proxy to the recipient.  That means
"mark
> them appropriately" is hard.
> 
> Brian
> 
> > -----Original Message-----
> > From: Winterbottom, James [mailto:[e-mail]]
> > Sent: Friday, November 23, 2007 11:38 PM
> > To: Brian Rosen; Hannes Tschofenig
> > Cc: [e-mail]
> > Subject: RE: [Geopriv] Message Flow
> >
> > Brian,
> >
> > Inline.
> >
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:[e-mail]]
> > > Sent: Saturday, 24 November 2007 11:18 AM
> > > To: 'Hannes Tschofenig'
> > > Cc: [e-mail]
> > > Subject: RE: [Geopriv] Message Flow
> > >
> > > > >> There is obviously a difference between the end host doing
the
> > job
> > > and
> > > > >> the proxy doing it. There is no difference between the two
> > > approaches.
> > > > >>
> > > > > I'm pointing out a difference between them.  In the endpoint
> > route,
> > > the
> > > > PSAP
> > > > > knows the location used for routing.  In the proxy case, it
> > doesn't.
> > > > >
> > > >
> > > > Well. That's not entirely correct if you consider the context
draft
> > in
> > > > addition. It allows you to indicate to what the reference
points.
> > > >
http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-
> > > context-
> > > > 01.txt
> > > No, that is not sufficient.  The PSAP (or any location recipient)
> > can't do
> > > anything that would get it the location the proxy got.
> > >
> > [AJW] This is not true. The proxy can request a snapshot location
which
> > means that the reference will always point to the same location.
> >
> > >
> >
> >
------------------------------------------------------------------------
> --
> > ----------------------
> > 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]
> 

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



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




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

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





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