Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

["Winterbottom, James" <[e-mail]>]

Marc inline.

> >
> > I don't quite not where to start since your response is so
> > utterly incorrect, and full of misrepresentations.
> 
> Do you agree that self-measured location determination either doesn't
> support 'uncertainty' or supports it via the use of significant
digits?
> 
> Do you agree that network-measured location determination provides
> 'uncertainty' as additional data points to the position data?
>

[AJW] No I don't. A point with uncertainty radius is a circle or as may
calculate it, and ellipsoid. This is what I got from the GPS that I
used. Not a dodgey 3825 "thick point".

> >
> > You seem to imply that 3825 is about "self-measuring" device,
> > there is no mention of this in 3825 at all. In fact 3825 says:
> 
> There must be something lost in the translation process between
northern
> and
> southern hemisphere :^).  I never stated that 3825 is any kind of
device.
> I
> stated that 3825 supports the data output from common self-measuring
> location determination mechanisms.  These mechanisms are most akin to
> building the wire-map database that dhcp would utilize in support of
the
> LCP
> function.
> 

[AJW] This is not stated in 3825, it is a post supposition that you are
introducing now. It is irrelevant to the argument, and as I stated
above, I don't believe that that is how GPS reports location.


> 
> >
> > "This document specifies a Dynamic Host Configuration Protocol [1]
> >    Option for the coordinate-based geographic location of the
> > client, to
> >    be provided by the server."
> >
> > To me this is clearly a network determined location, or is
> > the DHCP server in the end-device?
> 
> I am not going to answer this ridiculous question.  And I do believe
you
> understand the difference between the location measuring piece of
location
> determination vs. wiremap data and the act of passing this data to the
end
> host.
> 

[AJW] Fair enough, though you have stated on occasion that 3825 is not
dependent on DHCP relay, where the opening text suggests that it is a
predicate for the mechanism to work.


> >
> > Just to cut your response before you start, I have wandered
> > around quite large areas of Dallas in the past with a
> > differential GPS unit that quite clearly provided me with a
> > location as a circle, point with radius, and not a "thick point".
> 
> OK, good, you've now got experience.
> 
> Would you agree this application utilized a self-measured location
> determination mechanism?
> 
> Was the circle, point with radius coming from the actual GPS or due to
the
> resolution of the map data?

[AJW] From the GPS. It was expressed as an ellipsoid point +- X metres.

I didn't say anything about a mapping function, not sure where this left
field argument came from. I didn't require a mapping application for the
activity I was performing.

> >
> > I asked John S, a very simple question in an email yesterday,
> > that he has declined to respond to, I think that the answer
> > to that question would solve a great deal of trouble. Just in
> > case it got lost in the noise, I shall provide a link to it here:
> >
> > http://www.ietf.org/mail-archive/web/geopriv/current/msg05189.html
> 
> I noticed your question and view it again as an attempt to take this
> conversation down the road of comparing the merits of self-measured
> location
> determination mechanisms to network-measured location determination
> mechanisms.  Again, I going to ask that these types of debates take
place
> in
> a the proper venue, not the IETF.

[AJW] Then you have completely misunderstood why the question was asked.
John implied that a way to convey a circular uncertainty through DHCP
was not required, because the existing option could convey a rectangular
uncertainty. I was merely asking him to confirm that I had interpreted
his statement correctly, and I am waiting for an answer.


Cheers
James


 
------------------------------------------------------------------------------------------------
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]
http://www.ietf.org/mailman/listinfo/geopriv