The GeoJSON Format
RFC 7946

Note: This ballot was opened for revision 03 and is now closed.

Alissa Cooper Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Ben Campbell) No Objection

Comment (2016-06-01 for -03)
No email
send info
For the most part, this is clear and readable. I only have a few comments:

- I agree with Stephen's comments.

- I note several instances of 2119 "MUST" in what looks to me like definitions, rather than requirements. For example, 'For type "MultiPoint", the "coordinates" member MUST be an array of positions.' If that is a choice among options, and you want to make sure implementers do the right thing, then MUST makes sense. On the other hand, if that is really a definitions (e.g. "... the coordinates member is an array of positions"), then MUST is not appropriate. (For the record, I'm not sure which case these fall into.)

- Abstract:  If I understand correctly, the document only allows a single coordinate system. That’s stronger than “recommends”.

- 1.3: Does this document become the authoritative spec? That is, will people need to pay attention to GJ2008 at all after this is published? if not, then maybe "obsoletes" is the correct word. (Recognizing of course that IETF procedure words may not quite apply here.)

- 3.1.6, 4th bullet: Why SHOULD? Can you imagine situations where it would be reasonable to not follow the right-hand rule?

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2016-06-01 for -03)
No email
send info
- The last bullet of section 3 says "any number of other
members" and in general there are no limits here on size
or complexity of the objects. (There are some should
statements, which is good.) I wonder if there's a
potential DoS vector there?  Speculating, a DoS couuld be
based on the CPU if calculations based on the object are
complex, or it could be based on the size of the object
being VERY BIG. Are either of those realistic? (I'm not
saying they are, just asking.) I'm guessing it'd not make
sense to have a max size to these things, but is there any
guidance that you could offer to implementers or would it
be good to say that implementations SHOULD have some
maximum size (I don't care how you'd want to measure that)
with a recommendation that it be able to handle things up
to at least some nominated size? (Section 11.2 does talk
about this for senders/creators but says nothing for
recipients/readers.) 

- Section 10: I'd say it'd be good to add a reference to
something that describes some of the privacy issues with
objects such as these, and with potential mitigations, but
more importantly calling out that naively "fuzzing"
boundaries may not be as effective as seems at first the
case. I took a quick look and didn't find anything that
seems really good but maybe something like [1] would be a
good reference.

[1] http://www.sebastianzimmeck.de/riedererEtAlPhotograph2015ShortPaper.pdf

(Joel Jaeggli) No Objection

Suresh Krishnan No Objection

Comment (2016-05-31 for -03)
No email
send info
What are %maxlat%, %minlat%, %eastlon%, and %westlon% supposed to be? I am guessing they are max and min values for latitude and longitude (e.g.+/-90 and +/-180) but I think it would be helpful to be explicit here.

Mirja Kühlewind No Objection

(Terry Manderson) No Objection

Alexey Melnikov No Objection

Comment (2016-06-01 for -03)
No email
send info
In Section 12:

"applications that use this media type: various" - a bit more text about types of applications using it would be good! Please provide some examples (this is not supposed to be exhaustive list.)

"Author" and "Change Controller" fields are missing from the media type registration. These are especially important as the document was originally developed outside of IETF.

(Kathleen Moriarty) No Objection

Comment (2016-06-01 for -03)
No email
send info
I support Stephen's comments and will follow the responses.

Alvaro Retana No Objection