[dispatch] geojson charter suggestion

Alissa Cooper <alissa@cooperw.in> Thu, 16 July 2015 20:23 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id CAB881A8A8B for <dispatch@ietfa.amsl.com>; Thu, 16 Jul 2015 13:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id oPSy87HfTAyI for <dispatch@ietfa.amsl.com>; Thu, 16 Jul 2015 13:23:35 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236271A8A43 for <dispatch@ietf.org>; Thu, 16 Jul 2015 13:22:41 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 7F111207F2 for <dispatch@ietf.org>; Thu, 16 Jul 2015 16:22:40 -0400 (EDT)
Received: from frontend2 ([]) by compute5.internal (MEProxy); Thu, 16 Jul 2015 16:22:40 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-type:date:from:message-id:mime-version:subject:to :x-sasl-enc:x-sasl-enc; s=mesmtp; bh=KwkWUfZFhzqZ7CoE1vjaofqmyP8 =; b=JEXyXFUHNwO8scIQbjTER5DalvbTY+kXv3vV2p9NwcTyGGRsXulbt6Jizf1 Csp5rUAmIvTSJnZT6Bd0e3q6+CzvOrKHsFhqnr7tYQmKByx30hyKkoUuhndHrcb5 RWLJT62luL11NcdwFesKruU8AU7wNoJ1NRFplqbXiYH5lk7Y=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Kw kWUfZFhzqZ7CoE1vjaofqmyP8=; b=PcI6CWZN08mrTwfqiS3RgVbgoTTW6xkhY8 E05eKQeDhYtwbptZPm4rYA9XmyPTDxBWR5ZbIFoQeG0eI7vPDb/W+B+NZcohV5Lq RcMEy5YqvNRXFxUPSk9aLeTri9cExfX92yawiNKyE2E/CFWcp8dtSOaIhp5nBaw2 HFSZqS6Hg=
X-Sasl-enc: hzZEkaI/5gb6C7ShFmBuQm0X6AZSYMl1uoxm5zMTE3aS 1437078160
Received: from sjc-alcoop-8818.cisco.com (unknown []) by mail.messagingengine.com (Postfix) with ESMTPA id EEAFD6800FF for <dispatch@ietf.org>; Thu, 16 Jul 2015 16:22:39 -0400 (EDT)
From: Alissa Cooper <alissa@cooperw.in>
Content-Type: multipart/alternative; boundary="Apple-Mail=_26F9BC16-529D-4C4D-A41D-AED0C9AC2B12"
Message-Id: <A4D9E835-3365-4F0B-A373-A68A6E4C4AE2@cooperw.in>
Date: Thu, 16 Jul 2015 13:22:37 -0700
To: dispatch@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/8jVe0c0qlvTQplb8-lwiLn9vnLE>
Subject: [dispatch] geojson charter suggestion
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jul 2015 20:23:36 -0000

I was looking at the proposed geojson charter [1] and back at the minutes from dispatch at IETF 92 [2]. As discussed at IETF 92, the charter needs to be clearer about the relationship to the work done in geopriv. I think there is text from RFC 5870 that can be adapted for this purpose, at least partially. I would suggest adding something along the following lines to the charter:

GeoJSON objects represent geographic features only and do not specify associations between geographic features and particular devices, users, or facilities. Any association with a particular device, user, or facility requires another protocol. As such, a GeoJSON object does not fit the "Location Information" definition according to Section 5.2 of RFC 3693, because there is not necessarily a "Device" involved. Because there is also no way to specify the identity of a "Target" within the confines of a GeoJSON object, it also does not fit the specification of a "Location Object" (Section 5.2 of RFC 3693, Section 3.2 of RFC 6280). When a GeoJSON object is used in a context where it identifies the location of a Target, it becomes subject to the architectural, security, and privacy considerations in RFC 6280. The application of those considerations is specific to protocols that make use of GeoJSON objects and is out of scope for the GeoJSON WG.


[1] https://github.com/geojson/draft-geojson/blob/master/charter.md/
[2] https://www.ietf.org/proceedings/92/minutes/minutes-92-dispatch