added note to discuss naming for new optional profile/namespace membe…

…r and enhanced section security considerations by motivating and pointing to the relevant section in the JSON RFC
geojson · May 11, 2013 · be82b46 · be82b46
1 parent 9ae9b1d
commit be82b46
Show file tree

Hide file tree

Showing 9 changed files with 165 additions and 125 deletions.
diff --git a/CHANGES.txt b/CHANGES.txt
@@ -1,3 +1,4 @@
+20130511 - added note to discuss naming for new optional profile/namespace member and enhanced section security considerations by motivating and pointing to the relevant section in the JSON RFC
 20130402 - reduced crsRef to single label with domain RFC 5165 like URN, thus renamed it to crsURN
 20130430 - moved repo to GeoJSONWG organization at https://github.com/GeoJSONWG/draft-geojson
 20130428 - typos corrected, editorial changes throughout the document and several notes partly explaining thes or requesting further changes or additions. Correction of inconsistent may in GeoJSON Object first list item into MUST, merge with second listitem and provision of js and bib folders

diff --git a/README.md b/README.md
@@ -15,6 +15,8 @@ Some issues are to be resolved, others are not yet known:
 
 * Is the migration from the crs object to a crs reference ok?
 
+* Namespace or profile - howto enable optional hints (for consumers of GeoJSON objects) in a natrual way
+
 * Are the formal changes applied to the existing community spec at <http://geojson.org/geojson-spec.html> ok?
 
 * Is there consensus, that the mostly editorial changes apllied are also an enhancement or where these have to be reversed or completed?
@@ -30,4 +32,4 @@ Some issues are to be resolved, others are not yet known:
 * There is also an Acknowledgments section possible in addition to (or replacing) a contributor section, where the former is mor for lengthy thanks, which might not fit so well with the approx 15 pages total of the to be submitted paginated text RFC draft ...
 
 
- 
+
diff --git a/draft-unpaginated.txt b/draft-unpaginated.txt
@@ -5,12 +5,12 @@
 Independent                                                    H. Butler
 Internet-Draft                                                 Hobu Inc.
 Intended status: Informational                                   M. Daly
-Expires: October 03, 2013                                        Cadcorp
+Expires: November 12, 2013                                       Cadcorp
                                                                 A. Doyle
                                                                      MIT
                                                               S. Gillies
                                                          UNC-Chapel Hill
-                                                              April 2013
+                                                            May 11, 2013
 
 
 The Geospatial JavaScript Object Notation (GeoJSON) Format Specification
@@ -36,7 +36,7 @@ Status of This Memo
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on October 03, 2013.
+   This Internet-Draft will expire on November 12, 2013.
 
 Copyright Notice
 
@@ -93,12 +93,12 @@ Table of Contents
 Independent                                                    H. Butler
 Internet-Draft                                                 Hobu Inc.
 Intended status: Informational                                   M. Daly
-Expires: October 03, 2013                                        Cadcorp
+Expires: November 12, 2013                                       Cadcorp
                                                                 A. Doyle
                                                                      MIT
                                                               S. Gillies
                                                          UNC-Chapel Hill
-                                                              April 2013
+                                                            May 11, 2013
 
 
 The Geospatial JavaScript Object Notation (GeoJSON) Format Specification
@@ -124,7 +124,7 @@ Status of This Memo
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on October 03, 2013.
+   This Internet-Draft will expire on November 12, 2013.
 
 Copyright Notice
 
@@ -262,6 +262,11 @@ Copyright Notice
    unclear provenience when being consumed by the client.  Alternatively
    one might prefix all wonderful type names with say "geo" and a dot or
    so (not preferred) or even the names of the members (shiver).
+   Ammendment-20130511-sdrees: I would not call it profile as I am used
+   to profiles as changing the look of some core construct: adding
+   something, removing some other thing.  But as we have no core concept
+   published, but two wide used dialects GeoJSON vs.  ArcGIS JSON a
+   namespace should be the concept that fits more natrually.
 
 1.3.  Example
 
@@ -553,6 +558,13 @@ Copyright Notice
 
    This memo raises no security issues.
 
+   As GeoJSON directly builds on JSON, security considerations of JSON
+   also apply.
+
+   For JSON relevant security implications please cf.  at least the
+   relevant subsections of [RFC4627] (inside 6.  IANA Considerations
+   without separate sectionin number) as starting point.
+
 6.  IANA Considerations
 
    This document has no actions for IANA.

diff --git a/draft.html b/draft.html
@@ -392,7 +392,7 @@
 
   <meta name="dct.creator" content="Butler, H., Daly, M., Doyle, A., and S. Gillies" />
   <meta name="dct.identifier" content="urn:ietf:id:draft-sdrees-geojson-format-spec-01" />
-  <meta name="dct.issued" scheme="ISO8601" content="2013-4" />
+  <meta name="dct.issued" scheme="ISO8601" content="2013-5-11" />
   <meta name="dct.abstract" content="GeoJSON is a geospatial data interchange format based on JavaScript Object Notation (JSON).  " />
   <meta name="description" content="GeoJSON is a geospatial data interchange format based on JavaScript Object Notation (JSON).  " />
 
@@ -416,7 +416,7 @@
   <td class="right">M. Daly</td>
 </tr>
 <tr>
-  <td class="left">Expires: October 03, 2013</td>
+  <td class="left">Expires: November 12, 2013</td>
   <td class="right">Cadcorp</td>
 </tr>
 <tr>
@@ -437,7 +437,7 @@
 </tr>
 <tr>
   <td class="left"></td>
-  <td class="right">April 2013</td>
+  <td class="right">May 11, 2013</td>
 </tr>
 
 
@@ -457,7 +457,7 @@ <h1 id="rfc.status">
 <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
 <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF).  Note that other groups may also distribute working documents as Internet-Drafts.  The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
 <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.  It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
-<p>This Internet-Draft will expire on October 03, 2013.</p>
+<p>This Internet-Draft will expire on November 12, 2013.</p>
 <h1 id="rfc.copyrightnotice">
   <a href="#rfc.copyrightnotice">Copyright Notice</a>
 </h1>
@@ -557,7 +557,7 @@ <h1 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2.</a> <a href="#definitio
 <ul>
   <li>The namespace member SHOULD be on the top-level GeoJSON object in the following canonical hierarchical ordering, i.e. if present on a feature collection, else if present on a feature, else on a geometry and MUST NOT be repeated or overridden on children or grandchildren of the object.  </li>
 </ul>
-<p id="rfc.section.1.2.p.5">Motivation for above proposal: The benefit would be, that we a) remain backwards compatible, but b) avoid future clashes with JSON of unclear provenience when being consumed by the client.  Alternatively one might prefix all wonderful type names with say "geo" and a dot or so (not preferred) or even the names of the members (shiver).  </p>
+<p id="rfc.section.1.2.p.5">Motivation for above proposal: The benefit would be, that we a) remain backwards compatible, but b) avoid future clashes with JSON of unclear provenience when being consumed by the client.  Alternatively one might prefix all wonderful type names with say "geo" and a dot or so (not preferred) or even the names of the members (shiver). Ammendment-20130511-sdrees: I would not call it profile as I am used to profiles as changing the look of some core construct: adding something, removing some other thing.  But as we have no core concept published, but two wide used dialects GeoJSON vs. ArcGIS JSON a namespace should be the concept that fits more natrually.  </p>
 <h1 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3.</a> <a href="#example" id="example">Example</a></h1>
 <p id="rfc.section.1.3.p.1">A GeoJSON feature collection: </p>
 <pre>
@@ -735,6 +735,8 @@ <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#bounding-box" i
 <p class="figure"></p>
 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> Security Considerations</h1>
 <p id="rfc.section.5.p.1">This memo raises no security issues.</p>
+<p id="rfc.section.5.p.2">As GeoJSON directly builds on JSON, security considerations of JSON also apply.</p>
+<p id="rfc.section.5.p.3">For JSON relevant security implications please cf. at least the relevant subsections of [RFC4627] (inside 6. IANA Considerations without separate sectionin number) as starting point.</p>
 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> IANA Considerations</h1>
 <p id="rfc.section.6.p.1">This document has no actions for IANA.</p>
 <h1 id="rfc.references"><a href="#rfc.references">7.</a> References</h1>

diff --git a/draft.nroff b/draft.nroff
@@ -1,4 +1,4 @@
-.\" automatically generated by xml2rfc v2.4.1 on 2013-05-02T04:55:04Z
+.\" automatically generated by xml2rfc v2.4.1 on 2013-05-11T11:06:03Z
 
 .pl 10.0i
 .po 0
@@ -10,22 +10,22 @@
 .ad l
 .ds LH Internet-Draft
 .ds CH GeoJSON Format Specification
-.ds RH April 2013
+.ds RH May 2013
 .ds LF Butler, et al.
-.ds CF Expires October 03, 2013
+.ds CF Expires November 12, 2013
 .ds RF FORMFEED[Page %]
 
 .in 0
 .nf
 Independent                                                    H. Butler
 Internet-Draft                                                 Hobu Inc.
 Intended status: Informational                                   M. Daly
-Expires: October 03, 2013                                        Cadcorp
+Expires: November 12, 2013                                       Cadcorp
                                                                 A. Doyle
                                                                      MIT
                                                               S. Gillies
                                                          UNC-Chapel Hill
-                                                              April 2013
+                                                            May 11, 2013
 .fi
 
 
@@ -59,7 +59,7 @@ and may be updated, replaced, or obsoleted by other documents at any
 time.  It is inappropriate to use Internet-Drafts as reference
 material or to cite them other than as "work in progress."
 
-This Internet-Draft will expire on October 03, 2013.
+This Internet-Draft will expire on November 12, 2013.
 
 .ti 0
 Copyright Notice
@@ -232,6 +232,11 @@ remain backwards compatible, but b) avoid future clashes with JSON of
 unclear provenience when being consumed by the client.  Alternatively
 one might prefix all wonderful type names with say "geo" and a dot or
 so (not preferred) or even the names of the members (shiver).
+Ammendment-20130511-sdrees: I would not call it profile as I am used
+to profiles as changing the look of some core construct: adding
+something, removing some other thing.  But as we have no core concept
+published, but two wide used dialects GeoJSON vs.  ArcGIS JSON a
+namespace should be the concept that fits more natrually.
 
 .ti 0
 1.3.  Example
@@ -587,6 +592,13 @@ Example of a bbox member on a feature collection:
 
 This memo raises no security issues.
 
+As GeoJSON directly builds on JSON, security considerations of JSON
+also apply.
+
+For JSON relevant security implications please cf.  at least the
+relevant subsections of [RFC4627] (inside 6.  IANA Considerations
+without separate sectionin number) as starting point.
+
 .ti 0
 6.  IANA Considerations
 
@@ -615,6 +627,7 @@ Protocol -- HTTP/1.1", RFC 2616, June 1999.
 [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January
 2005.
+.bp
 
 .ti 3
 [RFC4627]  Crockford, D., "The application/json Media Type for
@@ -625,7 +638,6 @@ JavaScript Object Notation (JSON)", RFC 4627, July 2006.
 Open Geospatial Consortium (OGC)", RFC 5165, April 2008.
 
 .ti 0
-.bp
 7.2.  Informative References
 
 .ti 3
@@ -671,6 +683,7 @@ Position"):
 
 
 .ti 0
+.bp
 A.3.  Polygon
 
 Coordinates of a Polygon are an array of LinearRing (cf.  "2.1.6
@@ -680,7 +693,6 @@ interior rings (or holes).
 
 No holes:
 .nf
-.bp
 
   {
       "type": "Polygon",