From nobody Fri Aug 7 14:42:45 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B751A02F1 for ; Fri, 7 Aug 2015 14:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nk0rlr62I8i0 for ; Fri, 7 Aug 2015 14:42:41 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 663731A0169 for ; Fri, 7 Aug 2015 14:42:41 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so76195112wib.0 for ; Fri, 07 Aug 2015 14:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CA7Hq3kXrWOhAPEisRiK9N8ukI6Cl2g/qWXfdar0WZg=; b=ut+ByMepjS7JyxPnASQPnunECwUkO/4IJrNTSl/1WE6mCARc7Y/hcdwbxiq1aNL6eZ xZOVKe6sWW5VbXvpi1QNx4aEqLC/5sOprULi33DnjKGg89bFaBdChGpuMG5fqMQw8j8Q kuhjaVBd0gnlrNpgqcluSbWzMCOf/eoHyqjan+h99lQXsafN5gocZjLNsaz3remlvhYF yLmeZIU6xcCUomtsK4T0/8/A7B3UD7qJUFr+LuUgGNvjY6v77TB7zoPkhTcAUiCRLPgy B7l1SjO2Fa/yjajjM06ElPK71YSkSPUxWA8XVz1BWrmjAkuOdZQa5rMPpk/3sjeLbvze Ez1g== MIME-Version: 1.0 X-Received: by 10.180.19.36 with SMTP id b4mr527516wie.33.1438983760107; Fri, 07 Aug 2015 14:42:40 -0700 (PDT) Received: by 10.27.178.209 with HTTP; Fri, 7 Aug 2015 14:42:40 -0700 (PDT) Date: Fri, 7 Aug 2015 14:42:40 -0700 Message-ID: From: Sean Gillies To: DISPATCH list Content-Type: multipart/alternative; boundary=bcaec53d5d77dbddcb051cbf8376 Archived-At: Subject: [dispatch] Starting the GeoJSON working group X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 21:42:43 -0000 --bcaec53d5d77dbddcb051cbf8376 Content-Type: text/plain; charset=UTF-8 Dear all, May I move that we start the GeoJSON WG using the charter below? (Also forwarded to the geopriv list and to the original, not-IETF, geosjon list) Proposed GeoJSON WG Charter =========================== GeoJSON ------- GeoJSON is a format for encoding data about geographic features using JavaScript Object Notation (JSON) [RFC7159]. Geographic features need not be physical things; any thing with properties that are bounded in space may be considered a feature. GeoJSON provides a means of representing both the properties and spatial extent of features. The GeoJSON format specification was published at http://geojson.org in 2008. GeoJSON today plays an important and growing role in many spatial databases, web APIs, and open data platforms. Consequently the implementers increasingly demand formal standardization, improvements in the specification, guidance on extensibility, and the means to utilize larger GeoJSON datasets. This WG will work on a GeoJSON Format RFC that specifies the format more precisely, serves as a better guide for implementers, and improves extensibility of the format. The work will start from an Internet-Draft written by the original GeoJSON authors: draft-butler-geojson [1]. This WG will work on GeoJSON mappings of 'geo' URIs, reinforcing the use of RFC 5870. This WG will work on a format for a streamable sequence of GeoJSON texts based on RFC 7464 to address the difficulties in serializing very large sequences of features or feature sequences of indeterminate length. 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. Deliverables: * A GeoJSON format specification document including mappings of 'geo' URIs * A document describing a format for a streamable sequence of GeoJSON texts [1] https://tools.ietf.org/html/draft-butler-geojson -- Sean Gillies --bcaec53d5d77dbddcb051cbf8376 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

May I move that we start = the GeoJSON WG using the charter below?

(Also forwarded to the geopr= iv list and to the original, not-IETF, geosjon list)

Proposed = GeoJSON WG Charter
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

GeoJSON
-------

Ge= oJSON is a format for encoding data about geographic features using
Java= Script Object Notation (JSON) [RFC7159]. Geographic features need
not be= physical things; any thing with properties that are bounded in
space ma= y be considered a feature. GeoJSON provides a means of
representing both= the properties and spatial extent of features.

The GeoJSON format s= pecification was published at http://geojson= .org in
2008. GeoJSON today plays an important and growing role in m= any spatial
databases, web APIs, and open data platforms. Consequently t= he
implementers increasingly demand formal standardization, improvements= in
the specification, guidance on extensibility, and the means to utili= ze
larger GeoJSON datasets.

This WG will work on a GeoJSON Format= RFC that specifies the format more
precisely, serves as a better guide = for implementers, and improves
extensibility of the format. The work wil= l start from an Internet-Draft
written by the original GeoJSON authors: = draft-butler-geojson [1].

This WG will work on GeoJSON mappings of &= #39;geo' URIs, reinforcing the use
of RFC 5870.

This WG will = work on a format for a streamable sequence of GeoJSON texts
based on RFC= 7464 to address the difficulties in serializing very large
sequences of= features or feature sequences of indeterminate length.

GeoJSON obje= cts represent geographic features only and do not specify
associations b= etween geographic features and particular devices, users,
or facilities.= Any association with a particular device, user, or
facility requires an= other protocol. As such, a GeoJSON object does not
fit the "Locatio= n Information" definition according to Section 5.2 of
RFC 3693, bec= ause there is not necessarily a "Device" involved. Because
the= re is also no way to specify the identity of a "Target" within th= e
confines of a GeoJSON object, it also does not fit the specification o= f
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 identifi= es the
location of a Target, it becomes subject to the architectural, se= curity,
and privacy considerations in RFC 6280. The application of those=
considerations is specific to protocols that make use of GeoJSON object= s
and is out of scope for the GeoJSON WG.

Deliverables:

* = A GeoJSON format specification document including mappings of 'geo'=
=C2=A0 URIs
* A document describing a format for a streamable sequen= ce of GeoJSON
=C2=A0 texts

[1] https://tools.ietf.org/html/draft-butler-geojson=



--
Sean Gillies
--bcaec53d5d77dbddcb051cbf8376-- From nobody Sun Aug 9 01:41:54 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932A41ACE5B for ; Sun, 9 Aug 2015 01:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YmIC3RIPJkb for ; Sun, 9 Aug 2015 01:41:52 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2041ACE5A for ; Sun, 9 Aug 2015 01:41:52 -0700 (PDT) Received: by pabyb7 with SMTP id yb7so84905353pab.0 for ; Sun, 09 Aug 2015 01:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=dVnfbrH9QGZxEbZ4XkUJqe99PKyQuUSqdfWD3FF9IoA=; b=f7PqrQM71QpWupuhjG2rZ+SIfTwRQobyEpo60LanoFSI5JMDndEU1AHihuT/3uNQzM 4qfzkpS61e7gCcrCEGcrc74gfyESixq+rA8Go5jdB0r7RXymM+rCsBXkBx1RkknkjuXK GL7DHCptAvi4pJ2NDHaZDXeD6nEo7aB3wERchEsXAoHaxgZ2TFD3fbWQxLAZ/S4IWtbz LfVluLPOHLlpcRD4JS5KWqWq5WdVzhFXYugfI2lNtI7H07PeHokfHV+KGToWzZwgpvDG emk28VXYSfMsGTwGF6urE+OXBznEmDj+6Ah73aj3fRywoG+eudKaAByk0BqXRleiKV4J R+Lw== X-Received: by 10.68.136.234 with SMTP id qd10mr33477607pbb.162.1439109711828; Sun, 09 Aug 2015 01:41:51 -0700 (PDT) Received: from [192.168.1.100] ([1.144.24.185]) by smtp.gmail.com with ESMTPSA id bc10sm15792932pbd.14.2015.08.09.01.41.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Aug 2015 01:41:51 -0700 (PDT) From: James Winterbottom Content-Type: multipart/alternative; boundary="Apple-Mail=_F1D38186-5664-4256-BB4C-FB704067D936" Message-Id: Date: Sun, 9 Aug 2015 18:41:47 +1000 To: DISPATCH list Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [dispatch] draft-winterbottom-dispatch-locparam X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 08:41:53 -0000 --Apple-Mail=_F1D38186-5664-4256-BB4C-FB704067D936 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All, I have gone through the note of the dispatch meeting for this draft as = well as relying only my memory for what was discussed and I am at a bit = of a loss as to how to update this draft in a way so that it can = proceed. I totally agree with Keith=E2=80=99s assessment about the relevancy of = the privacy issue raised by Cullen. Keith is right, in that the current primary intended use is not = =E2=80=9Cinside=E2=80=9D and IMS network, though I believe that the = nodes employing this mechanism will have strong relationships with IMS = nodes, most likely an E-CSCF or something resembling one. Paul is also right. While IMS is not the chief customer, it is likely to = be one of the downstream recipients and as such it does rely on strong = trust relationships. So to this end a tie to RFC3325 is probably = warranted. Would it be reasonable then to: Add a tie in to RFC3325 with regards to trust Explicitly say that the loc-src needs to be a fully qualified host name = and that IP address must not be used? These seem to be be the two main points I took away. If this were done = could we do a list-based dispatch for this draft? Cheers James= --Apple-Mail=_F1D38186-5664-4256-BB4C-FB704067D936 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi All,

I = have gone through the note of the dispatch meeting for this draft as = well as relying only my memory for what was discussed and I am at a bit = of a loss as to how to update this draft in a way so that it can = proceed.

I = totally agree with Keith=E2=80=99s assessment about the relevancy of the = privacy issue raised by Cullen.

Keith is right, in that the current = primary intended use is not =E2=80=9Cinside=E2=80=9D and IMS network, = though I believe that the nodes employing this mechanism will have = strong relationships with IMS nodes, most likely an E-CSCF or something = resembling one.

Paul is also right. While IMS is not the chief customer, it = is likely to be one of the downstream recipients and as such it does = rely on strong trust relationships. So to this end a tie to RFC3325 is = probably warranted.

Would it be reasonable then to:
  1. Add a tie in to RFC3325 with = regards to trust
  2. Explicitly say that the loc-src = needs to be a fully qualified host name and that IP address must not be = used?

These seem to be be the two main points I took away. If this = were done could we do a list-based dispatch for this draft?

Cheers
James
= --Apple-Mail=_F1D38186-5664-4256-BB4C-FB704067D936-- From nobody Mon Aug 10 06:22:44 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A321B3553 for ; Mon, 10 Aug 2015 06:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqNJzmmho1Dl for ; Mon, 10 Aug 2015 06:22:41 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5BB1B3551 for ; Mon, 10 Aug 2015 06:22:41 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-05v.sys.comcast.net with comcast id 31Mj1r0072Udklx011Ngbg; Mon, 10 Aug 2015 13:22:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-18v.sys.comcast.net with comcast id 31Ng1r00A3Ge9ey011NgG8; Mon, 10 Aug 2015 13:22:40 +0000 Message-ID: <55C8A59F.5060809@alum.mit.edu> Date: Mon, 10 Aug 2015 09:22:39 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dispatch@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1439212960; bh=ZnIUl8lxZU/wA1FTIfuDrZ7L6+Qf3k/Jv7LpyqotFUo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=uolJ4X5F7bLDa3o+zfFQe93PuUm4jEgt5EtrWQi8DQdGNPcz0bASspRrIk+j8V96R MDRINxIZTmRIx0wgaFjaiYTko63HvEqNa6lXo12OGpKf3ghD2otg00pkccFOK51006 YxFVwHqD9PEN+CX/nlKU9Vm9NaualnR4LRq04wNV/pg1Ps6xRdCJZKZ5DDi7BkYIqU DyMEKON5I8WI7X9xoRWN+c408Rq7p4a7g1EpSa9mNtnQ65DYAsNQsda1wW4ejUwkOD FcZtwjc/y4UCamc5M9S7rvaStAaP5ovyMtO9aQRjAuBSllB4SuYAdMwP+/OBqrhu0F uh3zphwr3Cq0g== Archived-At: Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 13:22:42 -0000 On 8/9/15 4:41 AM, James Winterbottom wrote: > Hi All, > > I have gone through the note of the dispatch meeting for this draft as > well as relying only my memory for what was discussed and I am at a bit > of a loss as to how to update this draft in a way so that it can proceed. > > I totally agree with Keith’s assessment about the relevancy of the > privacy issue raised by Cullen. > > Keith is right, in that the current primary intended use is not “inside” > and IMS network, though I believe that the nodes employing this > mechanism will have strong relationships with IMS nodes, most likely an > E-CSCF or something resembling one. > > Paul is also right. While IMS is not the chief customer, it is likely to > be one of the downstream recipients and as such it does rely on strong > trust relationships. So to this end a tie to RFC3325 is probably warranted. > > Would it be reasonable then to: > > 1. Add a tie in to RFC3325 with regards to trust This would make me happy. Without an explanation of the expectations of the trust relationship the contents of this header field are meaningless. Thanks, Paul > 2. Explicitly say that the loc-src needs to be a fully qualified host > name and that IP address must not be used? > > > These seem to be be the two main points I took away. If this were done > could we do a list-based dispatch for this draft? > > Cheers > James > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Thu Aug 13 01:36:56 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5697D1B3771 for ; Thu, 13 Aug 2015 01:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWXgRYds9lG9 for ; Thu, 13 Aug 2015 01:36:52 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E321B376F for ; Thu, 13 Aug 2015 01:36:52 -0700 (PDT) Received: by pacgr6 with SMTP id gr6so33222134pac.2 for ; Thu, 13 Aug 2015 01:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=x9motYAW0JSGJtwfMj/mDAXgyl64WOyaoCStJpvAQqk=; b=n+Z6mB3krgul4Z99/YMPraSsfVzM4CpIsoq3qtLwq9/K0DdW76l96SaTafxfDq7fvO QsVIjBPF7QM3zpiaNXGhALDFPaQd9ntAV56B57XSheE7Ah9WuIczSSm9Vy8l7AVf4Hny NIw79rNCuE3+oRwM+a4G+73z5/lUQaP2pXzfRX+u81mlKkyyd79MEskYencaAXJhgX08 20OJ534tcOCuSZ0KuZ5iutyz08Nj3gSKJyAytbZZqU51xfkrIFCmCJ9nns1Hobq6YjDB Xzco5JSoawTmyDNV8tcdo3u9dRXQdoTwonx1QLAY8MYQexc0RYK24ltZj8VLfIVoZK+P jIVA== X-Received: by 10.68.250.98 with SMTP id zb2mr75715329pbc.40.1439455012041; Thu, 13 Aug 2015 01:36:52 -0700 (PDT) Received: from [192.168.1.100] ([1.129.86.150]) by smtp.gmail.com with ESMTPSA id sp1sm1726811pab.4.2015.08.13.01.36.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Aug 2015 01:36:51 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B5AE5395-CEBA-4CE2-B1DF-5D89AF7FFF9B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: James Winterbottom In-Reply-To: <55C8A59F.5060809@alum.mit.edu> Date: Thu, 13 Aug 2015 18:36:48 +1000 Message-Id: References: <55C8A59F.5060809@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.2098) Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 08:36:54 -0000 --Apple-Mail=_B5AE5395-CEBA-4CE2-B1DF-5D89AF7FFF9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Paul. > On 10 Aug 2015, at 11:22 pm, Paul Kyzivat = wrote: >=20 > On 8/9/15 4:41 AM, James Winterbottom wrote: >> Hi All, >>=20 >> I have gone through the note of the dispatch meeting for this draft = as >> well as relying only my memory for what was discussed and I am at a = bit >> of a loss as to how to update this draft in a way so that it can = proceed. >>=20 >> I totally agree with Keith=92s assessment about the relevancy of the >> privacy issue raised by Cullen. >>=20 >> Keith is right, in that the current primary intended use is not = =93inside=94 >> and IMS network, though I believe that the nodes employing this >> mechanism will have strong relationships with IMS nodes, most likely = an >> E-CSCF or something resembling one. >>=20 >> Paul is also right. While IMS is not the chief customer, it is likely = to >> be one of the downstream recipients and as such it does rely on = strong >> trust relationships. So to this end a tie to RFC3325 is probably = warranted. >>=20 >> Would it be reasonable then to: >>=20 >> 1. Add a tie in to RFC3325 with regards to trust >=20 > This would make me happy. Without an explanation of the expectations = of the trust relationship the contents of this header field are = meaningless. >=20 > Thanks, > Paul >=20 >> 2. Explicitly say that the loc-src needs to be a fully qualified host >> name and that IP address must not be used? >>=20 >>=20 >> These seem to be be the two main points I took away. If this were = done >> could we do a list-based dispatch for this draft? >>=20 >> Cheers >> James >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch = >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = --Apple-Mail=_B5AE5395-CEBA-4CE2-B1DF-5D89AF7FFF9B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thanks Paul.


On 10 Aug 2015, at 11:22 pm, Paul Kyzivat = <pkyzivat@alum.mit.edu> wrote:

On 8/9/15 4:41 AM, James Winterbottom = wrote:
Hi All,

I have gone = through the note of the dispatch meeting for this draft as
well as relying only my memory for what was discussed and I = am at a bit
of a loss as to how to update this draft in a = way so that it can proceed.

I totally agree = with Keith=92s assessment about the relevancy of the
privacy= issue raised by Cullen.

Keith is right, in = that the current primary intended use is not =93inside=94
and IMS network, though I believe that the nodes employing = this
mechanism will have strong relationships with IMS = nodes, most likely an
E-CSCF or something resembling = one.

Paul is also right. While IMS is not = the chief customer, it is likely to
be one of the = downstream recipients and as such it does rely on strong
trust relationships. So to this end a tie to RFC3325 is = probably warranted.

Would it be reasonable = then to:

1. Add a tie in to RFC3325 with = regards to trust

This would make me happy. Without an explanation = of the expectations of the trust relationship the contents of this = header field are meaningless.

Thanks,
Paul

2. Explicitly say that the loc-src needs to be a fully = qualified host
   name and that IP address = must not be used?


These seem = to be be the two main points I took away. If this were done
could we do a list-based dispatch for this draft?

Cheers
James


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_B5AE5395-CEBA-4CE2-B1DF-5D89AF7FFF9B-- From nobody Thu Aug 13 07:37:09 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6370A1A6F0A for ; Thu, 13 Aug 2015 07:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjo8VRFKe8lV for ; Thu, 13 Aug 2015 07:37:05 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0181A3BA7 for ; Thu, 13 Aug 2015 07:37:04 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7DEb32I038460 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Thu, 13 Aug 2015 09:37:04 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <55CCAB8A.8090908@nostrum.com> Date: Thu, 13 Aug 2015 09:36:58 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dispatch@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060103080009090502070109" Archived-At: Subject: Re: [dispatch] Starting the GeoJSON working group X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 14:37:07 -0000 This is a multi-part message in MIME format. --------------060103080009090502070109 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Since I ate some mic-line time at the DISPATCH meeting: I don't object to this charter. I reiterate that (if I understand the proposal correctly), these could be used as part of a location object, or could become a location object through extension. I suggest that you consider adding text to the charter to ask that the group consider its extension points carefully (in general since you note that the user community is asking for guidance on extensibility), and not _preclude_ extensions that would allow this to become a location object unless the group determines such extensibility would be harmful. RjS On 8/7/15 4:42 PM, Sean Gillies wrote: > Dear all, > > May I move that we start the GeoJSON WG using the charter below? > > (Also forwarded to the geopriv list and to the original, not-IETF, > geosjon list) > > Proposed GeoJSON WG Charter > =========================== > > GeoJSON > ------- > > GeoJSON is a format for encoding data about geographic features using > JavaScript Object Notation (JSON) [RFC7159]. Geographic features need > not be physical things; any thing with properties that are bounded in > space may be considered a feature. GeoJSON provides a means of > representing both the properties and spatial extent of features. > > The GeoJSON format specification was published at http://geojson.org in > 2008. GeoJSON today plays an important and growing role in many spatial > databases, web APIs, and open data platforms. Consequently the > implementers increasingly demand formal standardization, improvements in > the specification, guidance on extensibility, and the means to utilize > larger GeoJSON datasets. > > This WG will work on a GeoJSON Format RFC that specifies the format more > precisely, serves as a better guide for implementers, and improves > extensibility of the format. The work will start from an Internet-Draft > written by the original GeoJSON authors: draft-butler-geojson [1]. > > This WG will work on GeoJSON mappings of 'geo' URIs, reinforcing the use > of RFC 5870. > > This WG will work on a format for a streamable sequence of GeoJSON texts > based on RFC 7464 to address the difficulties in serializing very large > sequences of features or feature sequences of indeterminate length. > > 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. > > Deliverables: > > * A GeoJSON format specification document including mappings of 'geo' > URIs > * A document describing a format for a streamable sequence of GeoJSON > texts > > [1] https://tools.ietf.org/html/draft-butler-geojson > > > > -- > Sean Gillies > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------060103080009090502070109 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Since I ate some mic-line time at the DISPATCH meeting:

I don't object to this charter.

I reiterate that (if I understand the proposal correctly), these
could be used as part of a location object, or could become
a location object through extension.

I suggest that you  consider adding text to the charter to ask
that the group consider its extension points carefully (in general
since you note that the user community is asking for guidance on
extensibility), and not _preclude_ extensions that would allow this
to become a location object unless the group determines such
extensibility would be harmful.

RjS

On 8/7/15 4:42 PM, Sean Gillies wrote:
Dear all,

May I move that we start the GeoJSON WG using the charter below?

(Also forwarded to the geopriv list and to the original, not-IETF, geosjon list)

Proposed GeoJSON WG Charter
===========================

GeoJSON
-------

GeoJSON is a format for encoding data about geographic features using
JavaScript Object Notation (JSON) [RFC7159]. Geographic features need
not be physical things; any thing with properties that are bounded in
space may be considered a feature. GeoJSON provides a means of
representing both the properties and spatial extent of features.

The GeoJSON format specification was published at http://geojson.org in
2008. GeoJSON today plays an important and growing role in many spatial
databases, web APIs, and open data platforms. Consequently the
implementers increasingly demand formal standardization, improvements in
the specification, guidance on extensibility, and the means to utilize
larger GeoJSON datasets.

This WG will work on a GeoJSON Format RFC that specifies the format more
precisely, serves as a better guide for implementers, and improves
extensibility of the format. The work will start from an Internet-Draft
written by the original GeoJSON authors: draft-butler-geojson [1].

This WG will work on GeoJSON mappings of 'geo' URIs, reinforcing the use
of RFC 5870.

This WG will work on a format for a streamable sequence of GeoJSON texts
based on RFC 7464 to address the difficulties in serializing very large
sequences of features or feature sequences of indeterminate length.

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.

Deliverables:

* A GeoJSON format specification document including mappings of 'geo'
  URIs
* A document describing a format for a streamable sequence of GeoJSON
  texts

[1] https://tools.ietf.org/html/draft-butler-geojson



--
Sean Gillies


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--------------060103080009090502070109-- From nobody Fri Aug 21 10:42:08 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AFD1ACCF3 for ; Fri, 21 Aug 2015 10:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X_29eZ9T0LRR for ; Fri, 21 Aug 2015 10:42:04 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFECF1ACCF0 for ; Fri, 21 Aug 2015 10:42:04 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 2751A205B8 for ; Fri, 21 Aug 2015 13:42:04 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Fri, 21 Aug 2015 13:42:04 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=6u8HG OXgcZQG9Jn2grXCBh22ziw=; b=Nm7LE6gCFTfqu2A6kMXCNe6NvvH3mX1/SFKuU IIzxiFEOT6zr5FdwBOMjfzqx46vDd8pXTCO29GJkcmoCxBRWGTWd7yrqNsdbQ/p6 04Xa3EqS7wURlG6t4aAWeUgirAx60jCGJVC9tZFM8aK7e70kmPoXeSdPopYXQeah 5tHJr0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=6u8HGOXgcZQG9Jn2grXCBh22ziw=; b=A4QLv 0zdBYAdL8VFeEMod1c6ds14HZxbPcWqDfrTO7Ne32yNVgYXzUDwOhxippuDJ2IJB hf7QTgBTQHXSUy8Yin3g9Ascnb6HZ9fDhEfKvkEZoNmLt1rjdewYPVEJWN14rM9t UJWDdpbM0Qt3vtd1v+tll7X1KxDxt0M/IgtH3U= X-Sasl-enc: j4vhggiDqZTqCgYtKcdu7/cegrAA9EzFCzbQB1xS8XMR 1440178923 Received: from sjc-alcoop-8814.cisco.com (unknown [128.107.241.169]) by mail.messagingengine.com (Postfix) with ESMTPA id 3DFB4C0001D; Fri, 21 Aug 2015 13:42:03 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E6624DAF-D92A-4444-9918-05BB1EDA16F6" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <55CCAB8A.8090908@nostrum.com> Date: Fri, 21 Aug 2015 10:42:01 -0700 Message-Id: <4A490114-F714-489E-ABA3-ABB33FE8D189@cooperw.in> References: <55CCAB8A.8090908@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Starting the GeoJSON working group X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 17:42:07 -0000 --Apple-Mail=_E6624DAF-D92A-4444-9918-05BB1EDA16F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 13, 2015, at 7:36 AM, Robert Sparks wrote: > Since I ate some mic-line time at the DISPATCH meeting: >=20 > I don't object to this charter. >=20 > I reiterate that (if I understand the proposal correctly), these > could be used as part of a location object, or could become > a location object through extension. >=20 > I suggest that you consider adding text to the charter to ask=20 > that the group consider its extension points carefully (in general > since you note that the user community is asking for guidance on > extensibility), and not _preclude_ extensions that would allow this=20 > to become a location object unless the group determines such=20 > extensibility would be harmful.=20 Thanks. I added a sentence to the last paragraph to capture this. = In the absence of other comments I=92ve put this charter on the = September 3 IESG telechat for approval for external review. Alissa >=20 > RjS >=20 > On 8/7/15 4:42 PM, Sean Gillies wrote: >> Dear all, >>=20 >> May I move that we start the GeoJSON WG using the charter below? >>=20 >> (Also forwarded to the geopriv list and to the original, not-IETF, = geosjon list) >>=20 >> Proposed GeoJSON WG Charter >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>=20 >> GeoJSON >> ------- >>=20 >> GeoJSON is a format for encoding data about geographic features using >> JavaScript Object Notation (JSON) [RFC7159]. Geographic features need >> not be physical things; any thing with properties that are bounded in >> space may be considered a feature. GeoJSON provides a means of >> representing both the properties and spatial extent of features. >>=20 >> The GeoJSON format specification was published at http://geojson.org = in >> 2008. GeoJSON today plays an important and growing role in many = spatial >> databases, web APIs, and open data platforms. Consequently the >> implementers increasingly demand formal standardization, improvements = in >> the specification, guidance on extensibility, and the means to = utilize >> larger GeoJSON datasets. >>=20 >> This WG will work on a GeoJSON Format RFC that specifies the format = more >> precisely, serves as a better guide for implementers, and improves >> extensibility of the format. The work will start from an = Internet-Draft >> written by the original GeoJSON authors: draft-butler-geojson [1]. >>=20 >> This WG will work on GeoJSON mappings of 'geo' URIs, reinforcing the = use >> of RFC 5870. >>=20 >> This WG will work on a format for a streamable sequence of GeoJSON = texts >> based on RFC 7464 to address the difficulties in serializing very = large >> sequences of features or feature sequences of indeterminate length. >>=20 >> 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. >>=20 >> Deliverables: >>=20 >> * A GeoJSON format specification document including mappings of 'geo' >> URIs >> * A document describing a format for a streamable sequence of GeoJSON >> texts >>=20 >> [1] https://tools.ietf.org/html/draft-butler-geojson >>=20 >>=20 >>=20 >> -- >> Sean Gillies >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_E6624DAF-D92A-4444-9918-05BB1EDA16F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Aug 13, 2015, at 7:36 AM, Robert Sparks = <rjsparks@nostrum.com> = wrote:

=20 =20
Since I ate some mic-line time at the DISPATCH meeting:

I don't object to this charter.

I reiterate that (if I understand the proposal correctly), these
could be used as part of a location object, or could become
a location object through extension.

I suggest that you  consider adding text to the charter to ask =
that the group consider its extension points carefully (in = general
since you note that the user community is asking for guidance on
extensibility), and not _preclude_ extensions that would allow this
to become a location object unless the group determines such
extensibility would be harmful. =

Thanks. I added a sentence to = the last paragraph to capture this. <http://data= tracker.ietf.org/doc/charter-ietf-geojson/>

In the absence of other comments I=92ve put this charter on the = September 3 IESG telechat for approval for external = review.

Alissa


RjS

On 8/7/15 4:42 PM, Sean Gillies = wrote:
Dear all,

May I move that we start the GeoJSON WG using the charter below?

(Also forwarded to the geopriv list and to the original, not-IETF, geosjon list)

Proposed GeoJSON WG Charter
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

GeoJSON
-------

GeoJSON is a format for encoding data about geographic features using
JavaScript Object Notation (JSON) [RFC7159]. Geographic features need
not be physical things; any thing with properties that are bounded in
space may be considered a feature. GeoJSON provides a means of
representing both the properties and spatial extent of features.

The GeoJSON format specification was published at http://geojson.org in
2008. GeoJSON today plays an important and growing role in many spatial
databases, web APIs, and open data platforms. Consequently the
implementers increasingly demand formal standardization, improvements in
the specification, guidance on extensibility, and the means to utilize
larger GeoJSON datasets.

This WG will work on a GeoJSON Format RFC that specifies the format more
precisely, serves as a better guide for implementers, and improves
extensibility of the format. The work will start from an Internet-Draft
written by the original GeoJSON authors: draft-butler-geojson [1].

This WG will work on GeoJSON mappings of 'geo' URIs, reinforcing the use
of RFC 5870.

This WG will work on a format for a streamable sequence of GeoJSON texts
based on RFC 7464 to address the difficulties in serializing very large
sequences of features or feature sequences of indeterminate length.

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.

Deliverables:

* A GeoJSON format specification document including mappings of 'geo'
  URIs
* A document describing a format for a streamable sequence of GeoJSON
  texts

[1] https://tools.ie= tf.org/html/draft-butler-geojson



--
Sean Gillies


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing = list
dispatch@ietf.org
https://www.iet= f.org/mailman/listinfo/dispatch

= --Apple-Mail=_E6624DAF-D92A-4444-9918-05BB1EDA16F6--