draft-google-self-published-geofeeds has been brought to the ISE for
pulication as an Informational Independent Stream RFC.
The document has a long history. It came to the ISE in 2013 and received
several reviews, but then the authors lost focus and went away for a few
years. In March 2019 the authors revived the work and brought it back to
the ISE in April.
The draft bounced back and forwards between Informational and
Experimental, but we think this is right as an Informational RFC because
it documents a deployed format consumed by Google. As such it provides a
description of a mechanism that other companies and developers may wish
to implement to achieve interoperability.
We debated whether this should be labeled as "Google's Format" but
decided that, while Google is the principal existing consumer of these
feeds, the fact that some organizations already publish in this format
means that the case is slightly wider than that. It was noted by the
ISEB that the method described in the document is not necessarily ideal
and that better approaches may exist - if the IETF was to decide to
standardise a different format, that would be a fine thing, but this
document describes what is in the wild and so it not really open for
refinement in its current form.
As well as reviews by the ISE (previous and current), this document was
reviewed for the ISE by:
- Martin Thomson (for the previous ISE)
- a reviewer who wished to remain anonymous (for the previous ISE)
- Andrew Newton
- Subramanian Moonesamy
- Stephen Farrell (specifically on the privacy concerns)
- Andrew Alston
With so many reviews, the details are not included here but are
available to the IESG on request. Much of the reviewing focused on the
clarity of description of processes and meaning of fields. There was
some attention to future extensibility, and a little hand-wringing about
privacy especially with respect to how a user might know that
geolocation was in use so that they could stop it or simply not use the
service that was reporting their location.
On the privacy issue, it was felt that this document cannot enforce
behavior that allows a user to protect their privacy. Thus, the wording
(especially in Section 4) is presented as strong advice, but nothing
This document makes no request to IANA for action, and no IPR has been
- - - -
On 2020-01-12 the authors noted...
We have a minor change sitting in our edit buffer
We recently discovered that the example code in the Appendix doesn't correctly deal with lines that start with a # (comment lines).
We will be adding: