Re: [Geopriv] Confused about draft-polk-geopriv-pidf-lo-4-agps-00.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 menst-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>,
<mailto:geopriv-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: geopriv-bounces at ietf.org
Errors-To: geopriv-bounces at ietf.org
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 tion 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
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
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
