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

Andy, 

> 
> I think Brian has a point here.  If the IETF is defining 
> thick points, even implicitly as in 3825, then it should 
> probably defer to an organization with the bona fides to do 
> this subject justice.  

The IETF isn't defining anything.  The issue is a bunch of IETF participants
attempting to characterize/justify/evaluate (as engineers love to do) what
is already in use in the geo location discipline.  The term 'thick point' is
a characterization of how one might describe the effect of significant
digits in the application of geo location.  I haven't experienced this term
in the actual geo location discipline.

What I have witnessed in the geo location space is the mechanism of self
measuring location, ala gps, yielding results that either: (a) Do not convey
uncertainty surrounding the accuracy of the measurement, OR, (b) they convey
uncertainty via significant digits expressed.  This is simply a conclusion
drawn from the fact there is not any other usable data information, that may
be construed as 'uncertainty', in the output of this mechanism.  RFC3825
supports this mechanism.

We also have participants from a competing technology space to self
measuring, which is network measuring, within the discipline of geo
location, that utilize a mechanism where they convey uncertainty associated
with a measurement via additional data field(s).  This network measuring
mechanism is clearly, but not totally, in use in the cellular space.  The
utilization of this network measurement mechanism, to date, has been outside
the applicability of RFC3825.  I make this claim as RFC3825 clearly states
not for wireless hosts.  There has not been any evidence to suggest that
locating a wired host via network measurement is in use, feasible, or
planned.

The long tirades of discussion continually are drawn into the merits of
these competing technologies (self vs. network measuring) and their
corresponding lack of/use of measurement uncertainty.  This is adjacent to
the task at hand for GeoPriv and is the discussion I've attempted to
declare, 'Not for the IETF!'.  For unknown reasons, some still believe it's
a worthy venue to discuss such.

GEOPRIV uses the OGC's GML standard 
> quite heavily, and has in the past handed off work to them.  
> Hannes has suggested the definition of a DHCP option that is 
> more compatible with GML.  That is a good idea, if for no 
> other reason than the rest of the GEOPRIV standards use GML.

There have been recent claims that GML does not support my above hypothesis
of the self measuring space.  We need to figure out: (1) if this claim is
valid (2) whether this is a correctable oversight on OGC's part or (3)
RFC4119 needs updated to support GML version 3.2.1.

Carl Reed has offered to investigate this for us.

-Marc-

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
http://www.ietf.org/mailman/listinfo/geopriv