One of my concerns with this is that there isn't enough detail in
the document to be able to decide either way if this is even
feasible. For instance, how would you articulate a filter on GPS
pseudoranges that would result in a meaningful result? That is,
what filter would you use that would be equivalent to a zone
trigger, a distance-moved trigger, or a speed trigger? The level of
sophistication required is, to be quite honest, beyond what I've
seen in either of your drafts.
Cheers,
Martin
> -----Original Message-----
> From: geopriv-bounces at ietf.org [mailto:geopriv-bounces at ietf.org] On
> Behalf Of James M. Polk
> Sent: Wednesday, 23 July 2008 4:56 AM
> To: Hannes Tschofenig
> Cc: geopriv at ietf.org; Tschofenig,Hannes (NSN - FI/Espoo)
> Subject: Re: [Geopriv] Confused about draft-polk-geopriv-pidf-lo-4-
> agps-00.txt
>
> At 12:47 AM 7/18/2008, Hannes Tschofenig wrote:
> >You mentioned the presence event package vs. the location event
> >package: When trying to implement some of the features we couldn't
> >figure out how to accomplish the semantic with SIP presence. Maybe a
> >lack of misunderstanding on how SIP presence works or maybe a real
> >issue. Don't know yet.
> >
> >
> >I don't understand your persistent connection requirement.
>
> take my triangulation draft for a second, because it is easier to
> explain this one;
>
> imagine an endpoint that sees multiple radio signals over a
> navigational system, be this a set of GPS satellites, or cell towers,
> or WiMAX towers.
>
> The endpoint has this positioning information of each of the sources
> it can see (direction, angle, time, source identifier, etc), but in
> some very real cases, the endpoint isn't the one that runs the
> location determination algorithm, a location server (of some form)
> does this calculation.
>
> Option#1 - The endpoint could send the server this information every
> single instance it moves, taking the bandwidth necessary to send this
> information to this server
>
> or
>
> Option#2 - this server could ask for a poll from the endpoint,
> attempting to either guess when the endpoint moves or just requesting
> an update a some interval in time
>
> or
>
> Option#3 - the location server could subscribe to the endpoint, state
> in that subscription what constitutes movement (i.e., defines it),
> and asked that the endpoint give an initial location plus an update
> every time it moves at least as far as the server said to look
> for. This could be the server clearly defining to the endpoint "I
> don't want an update unless either 3 minutes passes, or you've moved
> more than 50 feet since the last update to me".
>
> To me, it's clear that Option#3 is the most efficient, and requires
> the least amount of state at the server (because it is passively
> waiting for an answer whenever it has told the endpoint to update, it
> is not actively running timers - other for how long the subscription is
> for).
>
> This is a persistent connection, as mentioned in both drafts, and in
> my messages on this list.
>
>
> >James M. Polk wrote:
> >>At 02:03 PM 7/17/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> >>>have you been missing years of discussions around L7 LCPs? Henning
> even
> >>>had a proposal to use SIP, see
> >>>http://tools.ietf.org/html/draft-schulzrinne-geopriv-locationref-00
> >>>
> >>>Based on the decisions in Prague the group decided to go for HELD
> and
> >>>there was no need seen to create yet another LCP. Adding yet another
> >>>protocol does not make deployment a lot simpler...
> >>
> >>hmmm, let's see...
> >>
> >>A decision in Prague means I should know better than to bring it up
> >>now. That's interesting in a group that repeatedly DOESN'T follow
> >>it's own consensus (if it doesn't suit them or a particular author).
> >>
> >>Case in point (and just one example of this) is from IETF 69
> >>(that's less than 1 year ago), the WG decided "Presence" was the
> >>only event package to be used for location.
> >>
> >>That didn't James Winterbottom and Martin Thomson from writing a
> >>new SIP event package for THIS IETF proposing a new event package
> >>for location, nor did it stop the GEOPRV Secretary (Richard Barnes)
> >>from strongly suggesting and backing the idea of this new event
> >>package to another SDO last week.
> >>
> >>Seriously, if the Geopriv Secretary cannot follow his own WG's
> >>consensuses, how can we blame authors from following consensuses of
> >>the WG (i.e., James W and Martin).
> >>
> >>Or did everyone NOT pay attention to that consensus when it was
> >>taken but me (the author of the Conveyance document that is
> >>stipulating the event package to be used)?
> >>
> >>BTW -- regarding SIP and doing LCP-like things -- there is a new
> >>requirement from another SDO (which I mention by name in the agps
> >>and triangulation IDs) for persistent connections which look an
> >>awful lot like a subscription-based dialog -- something HTTP cannot
> >>do, nor can DHCP. These IDs are suggesting we revisit the SIP as
> >>an LCP *because* of this new requirement, and that's the only
> >>reason these docs were written.
> >>
> >>I guess the INTRO needs to be clearer in both IDs as to this
> >>requirement. I'll fix that in the next rev of both.
> >>
> >>>Ciao
> >>>Hannes
> >>
> >>_______________________________________________
> >>Geopriv mailing list
> >>Geopriv at ietf.org
> >>https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv at ietf.org
> https://www.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
Geopriv at ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
