Geographic JSON
charter-ietf-geojson-01

[Ballot comment]
Very consistent feedback with my previous review:

One readability improvement.
So many RFC numbers I have to lookup, in this charter: 5870, 7464, 3693,
6280. Sorry I don't know them all by heart.
A good convention is name + RFC, such as "JavaScript Object Notation
(JSON) [RFC7159]"

I guess it's a short-lived WG, right? Two deliverables and then closed,
right?
Would be worth mentioning IMO. In the milestones, that would be fine.

[Ballot comment]
One readability improvement.
So many RFC numbers I have to lookup, in this charter: 5870, 7464, 3693, 6280. Sorry I don't know them all by heart.
A good convention is name + RFC, such as "JavaScript Object Notation (JSON) [RFC7159]"

I guess it's a short-lived WG, right? Two deliverables and then closed, right?
Would be worth mentioning IMO. In the milestones, that would be fine.

[Ballot block]

This seems like a fine thing to do, but I have one
concern I'd like to chat about before we go ahead.

I could buy the "no privacy issues here" argument except
for the last sentence which says: "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." Aside from being hard to
parse, that seems to mean that some extensions could mean
this format does become a RFC6280 Location object, which
would then bring in the privacy and security issues,
previously argued to be out of scope. I think that's a
contradiction. As it happens, I also think that, despite
folks best efforts, RFC6280 isn't an architecture that
worked out that well, so I'd not suggest that this wG try
emulate that with square brackets. Instead, I'd suggest
that this WG be chartered to never take on work with does
have security or privacy consequences (without a
re-charter).

That'd maybe mean a change in the last sentence such as:

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:

  In order to continue to validly avoid having to deal
  with the security and privacy issues that would arise,
  this WG will not define any extensions that would have
  the effect of making a geojson object an RFC6280
  location object or location information as defined by
  RFC3693.  Should such an extension be needed,
  re-chartering will be required.

My propsed NEW text is very clunky so probably needs
improving.

[Ballot comment]
is the specification, intended (as the draft is today) to remain informational. and is there therefore any additional work related to the specification itslef other than publishing it to be done in the IETF?