Re: [Geopriv] Stephen Farrell's Block on charter-ietf-geojson-00-01: (with BLOCK)

["Carl Reed" <[e-mail]>]

Sorry to jump in. I have now read the entire thread, reviewed the charter, 
and reviewed a number of RFCs on this topic (starting with 4119). Been a 
while! Before starting, I wish to state that I am not opposed to this WG 
activity - GeoJSON is an important spec and one now being used in OGC 
standards work as informational. I just have some concerns.

In my mind, there is perhaps a more fundamental question: What is a Location 
Object? Back with the LO activity first started, the focus was on extending 
PIDF to include location content. From that perspective, privacy and 
location are closely coupled. However, over time the use of the location 
object became uncoupled from PIDF and as a result a number of other RFCs now 
speak to how to use a LO with SIP, RADIUS, and so on. Essentially, a LO can 
also be viewed as a stand alone package of location content with additional 
attributes such as uncertainty. When I worked on these RFC, I never viewed 
LO as being tightly coupled with privacy but always viewed the LO as a data 
package that could be used with any number of other standards/specs or even 
as a standard alone payload. This is exactly what has happened. Don't get me 
wrong - the privacy implications associated with location are critical - and 
scary. Predictive analytics experiments have shown that future individual 
movement activity can be predicted with close to 95% accuracy by analyzing 
past movement behavior (a joint Harvard/MIT study).

Therefore, I would suggest that a GeoJSON encoded payload is a location 
object. Consider that the PIDF-LO geodetic model is encoded using GML. The 
abstract model for geometry used in GML is ISO 19107: Spatial Schema (which 
is now in revision). The GeoJSON geometry model is also based on ISO 19107. 
The main difference between the two (other than the LO requirement for 
additional geometry types) is that GeoJSON encodes coordinates as 
longitude/latitude. GML encodes coordinates as latitude-longitude. There are 
also differences in how other coordinate reference systems are handled. 
While these differences are properly documented, I would strongly encourage 
the planned activity to consider:

1. Documenting the relationship (similarities and differences) between 
GeoJSON and a LO. This would allow developers to choose the appropriate 
implementation approach.
2. Have a section on threat analysis and security
3. Speak to how privacy issues could be addressed (back to item 1 also).

Perhaps I am being overly sensitive but location and privacy (along with 
provenance and uncertainty) are coming to the fore as major standards 
issues. The OGC is working these standards related issues more and more. 
Much of this is being driven by requirements to use location content 
associated "citizens as scientists" activities, volunteered geographic 
information, IoT, Smart Cities, and on and on.

I know the GeoJSON authors do not wish to "overload" the GeoJSON spec. As 
such, I suspect many of my concerns could be easily addressed by referencing 
appropriate content from existing IETF RFCs. For example, the content of 
7459 Uncertainty and Confidence is quite appropriate for a GeoJSON encoding. 
Also, 7459 was reviewed and commented on by OGC Members :-)

Sorry for the long posting.

Regards

Carl Reed
Geospatial Standards geek

-----Original Message----- 
From: Alissa Cooper
Sent: Thursday, September 03, 2015 9:02 AM
To: Stephen Farrell
Cc: [e-mail] ; [e-mail] ; Erik Wilde ; IESG
Subject: Re: [Geopriv] Stephen Farrell's Block on 
charter-ietf-geojson-00-01: (with BLOCK)

Ok, one more try and we’re there I think:

OLD
As the WG considers extensibility it will be careful not to
preclude extensions that would allow GeoJSON objects to become location 
objects
unless the group determines such extensibility would be harmful.

NEW
Extensions that would allow GeoJSON objects to become location objects are 
not expected to be defined in the WG. Should that be needed, re-chartering 
will be required.

> On Sep 3, 2015, at 7:58 AM, Stephen Farrell <[e-mail]> 
> wrote:
>
>
> Better again. You could maybe add that's not expected to happen
> during the lifetime of this wg but that'd be fine.
>
> S
>
> On 03/09/15 15:57, Alissa Cooper wrote:
>> NEW Should extensions that would allow GeoJSON objects to become
>> location objects be needed, re-chartering will be required.

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