Awesome/awesome-copilot
1
0
Fork 0
mirror of https://github.com/github/awesome-copilot.git synced 2026-04-12 19:25:55 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
9759552fbcd084e8e0cbb2cd0bec4e90cffed41a
awesome-copilot/skills/geofeed-tuner/references/rfc8805.txt
Punit 9856b62b88 Add geofeed-tuner skill for RFC 8805 IP geolocation feeds (#1138) 
* Add geofeed-tuner skill for RFC 8805 IP geolocation feeds

* Fix Codespell errors and apply  awesome-copilot contrib guidelines

* Fix Codespell errors and apply  awesome-copilot contrib guidelines

* Fix Codespell errors and apply  awesome-copilot contrib guidelines

* Update geofeed-tuner skill description and assets
2026-03-24 16:25:10 +11:00

736 lines
30 KiB
Plaintext
Raw Blame History

Independent Submission E. Kline
Request for Comments: 8805 Loon LLC
Category: Informational K. Duleba
ISSN: 2070-1721 Google
Z. Szamonek
S. Moser
Google Switzerland GmbH
W. Kumari
Google
August 2020
A Format for Self-Published IP Geolocation Feeds
Abstract
This document records a format whereby a network operator can publish
a mapping of IP address prefixes to simplified geolocation
information, colloquially termed a "geolocation feed". Interested
parties can poll and parse these feeds to update or merge with other
geolocation data sources and procedures. This format intentionally
only allows specifying coarse-level location.
Some technical organizations operating networks that move from one
conference location to the next have already experimentally published
small geolocation feeds.
This document describes a currently deployed format. At least one
consumer (Google) has incorporated these feeds into a geolocation
data pipeline, and a significant number of ISPs are using it to
inform them where their prefixes should be geolocated.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not candidates for any level of Internet Standard;
see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8805.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction
1.1. Motivation
1.2. Requirements Notation
1.3. Assumptions about Publication
2. Self-Published IP Geolocation Feeds
2.1. Specification
2.1.1. Geolocation Feed Individual Entry Fields
2.1.1.1. IP Prefix
2.1.1.2. Alpha2code (Previously: 'country')
2.1.1.3. Region
2.1.1.4. City
2.1.1.5. Postal Code
2.1.2. Prefixes with No Geolocation Information
2.1.3. Additional Parsing Requirements
2.2. Examples
3. Consuming Self-Published IP Geolocation Feeds
3.1. Feed Integrity
3.2. Verification of Authority
3.3. Verification of Accuracy
3.4. Refreshing Feed Information
4. Privacy Considerations
5. Relation to Other Work
6. Security Considerations
7. Planned Future Work
8. Finding Self-Published IP Geolocation Feeds
8.1. Ad Hoc 'Well-Known' URIs
8.2. Other Mechanisms
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Sample Python Validation Code
Acknowledgements
Authors' Addresses
1. Introduction
1.1. Motivation
Providers of services over the Internet have grown to depend on best-
effort geolocation information to improve the user experience.
Locality information can aid in directing traffic to the nearest
serving location, inferring likely native language, and providing
additional context for services involving search queries.
When an ISP, for example, changes the location where an IP prefix is
deployed, services that make use of geolocation information may begin
to suffer degraded performance. This can lead to customer
complaints, possibly to the ISP directly. Dissemination of correct
geolocation data is complicated by the lack of any centralized means
to coordinate and communicate geolocation information to all
interested consumers of the data.
This document records a format whereby a network operator (an ISP, an
enterprise, or any organization that deems the geolocation of its IP
prefixes to be of concern) can publish a mapping of IP address
prefixes to simplified geolocation information, colloquially termed a
"geolocation feed". Interested parties can poll and parse these
feeds to update or merge with other geolocation data sources and
procedures.
This document describes a currently deployed format. At least one
consumer (Google) has incorporated these feeds into a geolocation
data pipeline, and a significant number of ISPs are using it to
inform them where their prefixes should be geolocated.
1.2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
As this is an informational document about a data format and set of
operational practices presently in use, requirements notation
captures the design goals of the authors and implementors.
1.3. Assumptions about Publication
This document describes both a format and a mechanism for publishing
data, with the assumption that the network operator to whom
operational responsibility has been delegated for any published data
wishes it to be public. Any privacy risk is bounded by the format,
and feed publishers MAY omit prefixes or any location field
associated with a given prefix to further protect privacy (see
Section 2.1 for details about which fields exactly may be omitted).
Feed publishers assume the responsibility of determining which data
should be made public.
This document does not incorporate a mechanism to communicate
acceptable use policies for self-published data. Publication itself
is inferred as a desire by the publisher for the data to be usefully
consumed, similar to the publication of information like host names,
cryptographic keys, and Sender Policy Framework (SPF) records
[RFC7208] in the DNS.
2. Self-Published IP Geolocation Feeds
The format described here was developed to address the need of
network operators to rapidly and usefully share geolocation
information changes. Originally, there arose a specific case where
regional operators found it desirable to publish location changes
rather than wait for geolocation algorithms to "learn" about them.
Later, technical conferences that frequently use the same network
prefixes advertised from different conference locations experimented
by publishing geolocation feeds updated in advance of network
location changes in order to better serve conference attendees.
At its simplest, the mechanism consists of a network operator
publishing a file (the "geolocation feed") that contains several text
entries, one per line. Each entry is keyed by a unique (within the
feed) IP prefix (or single IP address) followed by a sequence of
network locality attributes to be ascribed to the given prefix.
2.1. Specification
For operational simplicity, every feed should contain data about all
IP addresses the provider wants to publish. Alternatives, like
publishing only entries for IP addresses whose geolocation data has
changed or differ from current observed geolocation behavior "at
large", are likely to be too operationally complex.
Feeds MUST use UTF-8 [RFC3629] character encoding. Lines are
delimited by a line break (CRLF) (as specified in [RFC4180]), and
blank lines are ignored. Text from a '#' character to the end of the
current line is treated as a comment only and is similarly ignored
(note that this does not strictly follow [RFC4180], which has no
support for comments).
Feed lines that are not comments MUST be formatted as comma-separated
values (CSV), as described in [RFC4180]. Each feed entry is a text
line of the form:
ip_prefix,alpha2code,region,city,postal_code
The IP prefix field is REQUIRED, all others are OPTIONAL (can be
empty), though the requisite minimum number of commas SHOULD be
present.
2.1.1. Geolocation Feed Individual Entry Fields
2.1.1.1. IP Prefix
REQUIRED: Each IP prefix field MUST be either a single IP address or
an IP prefix in Classless Inter-Domain Routing (CIDR) notation in
conformance with Section 3.1 of [RFC4632] for IPv4 or Section 2.3 of
[RFC4291] for IPv6.
Examples include "192.0.2.1" and "192.0.2.0/24" for IPv4 and
"2001:db8::1" and "2001:db8::/32" for IPv6.
2.1.1.2. Alpha2code (Previously: 'country')
OPTIONAL: The alpha2code field, if non-empty, MUST be a 2-letter ISO
country code conforming to ISO 3166-1 alpha 2 [ISO.3166.1alpha2].
Parsers SHOULD treat this field case-insensitively.
Earlier versions of this document called this field "country", and it
may still be referred to as such in existing tools/interfaces.
Parsers MAY additionally support other 2-letter codes outside the ISO
3166-1 alpha 2 codes, such as the 2-letter codes from the
"Exceptionally reserved codes" [ISO-GLOSSARY] set.
Examples include "US" for the United States, "JP" for Japan, and "PL"
for Poland.
2.1.1.3. Region
OPTIONAL: The region field, if non-empty, MUST be an ISO region code
conforming to ISO 3166-2 [ISO.3166.2]. Parsers SHOULD treat this
field case-insensitively.
Examples include "ID-RI" for the Riau province of Indonesia and "NG-
RI" for the Rivers province in Nigeria.
2.1.1.4. City
OPTIONAL: The city field, if non-empty, SHOULD be free UTF-8 text,
excluding the comma (',') character.
Examples include "Dublin", "New York", and "Sao Paulo" (specifically
"S" followed by 0xc3, 0xa3, and "o Paulo").
2.1.1.5. Postal Code
OPTIONAL, DEPRECATED: The postal code field, if non-empty, SHOULD be
free UTF-8 text, excluding the comma (',') character. The use of
this field is deprecated; consumers of feeds should be able to parse
feeds containing these fields, but new feeds SHOULD NOT include this
field due to the granularity of this information. See Section 4 for
additional discussion.
Examples include "106-6126" (in Minato ward, Tokyo, Japan).
2.1.2. Prefixes with No Geolocation Information
Feed publishers may indicate that some IP prefixes should not have
any associated geolocation information. It may be that some prefixes
under their administrative control are reserved, not yet allocated or
deployed, or in the process of being redeployed elsewhere and
existing geolocation information can, from the perspective of the
publisher, safely be discarded.
This special case can be indicated by explicitly leaving blank all
fields that specify any degree of geolocation information. For
example:
192.0.2.0/24,,,,
2001:db8:1::/48,,,,
2001:db8:2::/48,,,,
Historically, the user-assigned alpha2code identifier of "ZZ" has
been used for this same purpose. This is not necessarily preferred,
and no specific interpretation of any of the other user-assigned
alpha2code codes is currently defined.
2.1.3. Additional Parsing Requirements
Feed entries that do not have an IP address or prefix field or have
an IP address or prefix field that fails to parse correctly MUST be
discarded.
While publishers SHOULD follow [RFC5952] for IPv6 prefix fields,
consumers MUST nevertheless accept all valid string representations.
Duplicate IP address or prefix entries MUST be considered an error,
and consumer implementations SHOULD log the repeated entries for
further administrative review. Publishers SHOULD take measures to
ensure there is one and only one entry per IP address and prefix.
Multiple entries that constitute nested prefixes are permitted.
Consumers SHOULD consider the entry with the longest matching prefix
(i.e., the "most specific") to be the best matching entry for a given
IP address.
Feed entries with non-empty optional fields that fail to parse,
either in part or in full, SHOULD be discarded. It is RECOMMENDED
that they also be logged for further administrative review.
For compatibility with future additional fields, a parser MUST ignore
any fields beyond those it expects. The data from fields that are
expected and that parse successfully MUST still be considered valid.
Per Section 7, no extensions to this format are in use nor are any
anticipated.
2.2. Examples
Example entries using different IP address formats and describing
locations at alpha2code ("country code"), region, and city
granularity level, respectively:
192.0.2.0/25,US,US-AL,,
192.0.2.5,US,US-AL,Alabaster,
192.0.2.128/25,PL,PL-MZ,,
2001:db8::/32,PL,,,
2001:db8:cafe::/48,PL,PL-MZ,,
The IETF network publishes geolocation information for the meeting
prefixes, and generally just comment out the last meeting information
and append the new meeting information. The [GEO_IETF], at the time
of this writing, contains:
# IETF106 (Singapore) - November 2019 - Singapore, SG
130.129.0.0/16,SG,SG-01,Singapore,
2001:df8::/32,SG,SG-01,Singapore,
31.133.128.0/18,SG,SG-01,Singapore,
31.130.224.0/20,SG,SG-01,Singapore,
2001:67c:1230::/46,SG,SG-01,Singapore,
2001:67c:370::/48,SG,SG-01,Singapore,
Experimentally, RIPE has published geolocation information for their
conference network prefixes, which change location in accordance with
each new event. [GEO_RIPE_NCC], at the time of writing, contains:
193.0.24.0/21,NL,NL-ZH,Rotterdam,
2001:67c:64::/48,NL,NL-ZH,Rotterdam,
Similarly, ICANN has published geolocation information for their
portable conference network prefixes. [GEO_ICANN], at the time of
writing, contains:
199.91.192.0/21,MA,MA-07,Marrakech
2620:f:8000::/48,MA,MA-07,Marrakech
A longer example is the [GEO_Google] Google Corp Geofeed, which lists
the geolocation information for Google corporate offices.
At the time of writing, Google processes approximately 400 feeds
comprising more than 750,000 IPv4 and IPv6 prefixes.
3. Consuming Self-Published IP Geolocation Feeds
Consumers MAY treat published feed data as a hint only and MAY choose
to prefer other sources of geolocation information for any given IP
prefix. Regardless of a consumer's stance with respect to a given
published feed, there are some points of note for sensibly and
effectively consuming published feeds.
3.1. Feed Integrity
The integrity of published information SHOULD be protected by
securing the means of publication, for example, by using HTTP over
TLS [RFC2818]. Whenever possible, consumers SHOULD prefer retrieving
geolocation feeds in a manner that guarantees integrity of the feed.
3.2. Verification of Authority
Consumers of self-published IP geolocation feeds SHOULD perform some
form of verification that the publisher is in fact authoritative for
the addresses in the feed. The actual means of verification is
likely dependent upon the way in which the feed is discovered. Ad
hoc shared URIs, for example, will likely require an ad hoc
verification process. Future automated means of feed discovery
SHOULD have an accompanying automated means of verification.
A consumer should only trust geolocation information for IP addresses
or prefixes for which the publisher has been verified as
administratively authoritative. All other geolocation feed entries
should be ignored and logged for further administrative review.
3.3. Verification of Accuracy
Errors and inaccuracies may occur at many levels, and publication and
consumption of geolocation data are no exceptions. To the extent
practical, consumers SHOULD take steps to verify the accuracy of
published locality. Verification methodology, resolution of
discrepancies, and preference for alternative sources of data are
left to the discretion of the feed consumer.
Consumers SHOULD decide on discrepancy thresholds and SHOULD flag,
for administrative review, feed entries that exceed set thresholds.
3.4. Refreshing Feed Information
As a publisher can change geolocation data at any time and without
notification, consumers SHOULD implement mechanisms to periodically
refresh local copies of feed data. In the absence of any other
refresh timing information, it is recommended that consumers SHOULD
refresh feeds no less often than weekly and no more often than is
likely to cause issues to the publisher.
For feeds available via HTTPS (or HTTP), the publisher MAY
communicate refresh timing information by means of the standard HTTP
expiration model ([RFC7234]). Specifically, publishers can include
either an Expires header (Section 5.3 of [RFC7234]) or a Cache-
Control header (Section 5.2 of [RFC7234]) specifying the max-age.
Where practical, consumers SHOULD refresh feed information before the
expiry time is reached.
4. Privacy Considerations
Publishers of geolocation feeds are advised to have fully considered
any and all privacy implications of the disclosure of such
information for the users of the described networks prior to
publication. A thorough comprehension of the security considerations
(Section 13 of [RFC6772]) of a chosen geolocation policy is highly
recommended, including an understanding of some of the limitations of
information obscurity (Section 13.5 of [RFC6772]) (see also
[RFC6772]).
As noted in Section 2.1, each location field in an entry is optional,
in order to support expressing only the level of specificity that the
publisher has deemed acceptable. There is no requirement that the
level of specificity be consistent across all entries within a feed.
In particular, the Postal Code field (Section 2.1.1.5) can provide
very specific geolocation, sometimes within a building. Such
specific Postal Code values MUST NOT be published in geofeeds without
the express consent of the parties being located.
Operators who publish geolocation information are strongly encouraged
to inform affected users/customers of this fact and of the potential
privacy-related consequences and trade-offs.
5. Relation to Other Work
While not originally done in conjunction with the GEOPRIV Working
Group [GEOPRIV], Richard Barnes observed that this work is
nevertheless consistent with that which the group has defined, both
for address format and for privacy. The data elements in geolocation
feeds are equivalent to the following XML structure ([RFC5139]
[W3C.REC-xml-20081126]):
<civicAddress>
<country>country</country>
<A1>region</A1>
<A2>city</A2>
<PC>postal_code</PC>
</civicAddress>
Providing geolocation information to this granularity is equivalent
to the following privacy policy (the definition of the 'building'
Section 6.5.1 of [RFC6772] level of disclosure):
<ruleset>
<rule>
<conditions/>
<actions/>
<transformations>
<provide-location profile="civic-transformation">
<provide-civic>building</provide-civic>
</provide-location>
</transformations>
</rule>
</ruleset>
6. Security Considerations
As there is no true security in the obscurity of the location of any
given IP address, self-publication of this data fundamentally opens
no new attack vectors. For publishers, self-published data may
increase the ease with which such location data might be exploited
(it can, for example, make easy the discovery of prefixes populated
with customers as distinct from prefixes not generally in use).
For consumers, feed retrieval processes may receive input from
potentially hostile sources (e.g., in the event of hijacked traffic).
As such, proper input validation and defense measures MUST be taken
(see the discussion in Section 3.1).
Similarly, consumers who do not perform sufficient verification of
published data bear the same risks as from other forms of geolocation
configuration errors (see the discussion in Sections 3.2 and 3.3).
Validation of a feed's contents includes verifying that the publisher
is authoritative for the IP prefixes included in the feed. Failure
to verify IP prefix authority would, for example, allow ISP Bob to
make geolocation statements about IP space held by ISP Alice. At
this time, only out-of-band verification methods are implemented
(i.e., an ISP's feed may be verified against publicly available IP
allocation data).
7. Planned Future Work
In order to more flexibly support future extensions, use of a more
expressive feed format has been suggested. Use of JavaScript Object
Notation (JSON) [RFC8259], specifically, has been discussed.
However, at the time of writing, no such specification nor
implementation exists. Nevertheless, work on extensions is deferred
until a more suitable format has been selected.
The authors are planning on writing a document describing such a new
format. This document describes a currently deployed and used
format. Given the extremely limited extensibility of the present
format no extensions to it are anticipated. Extensibility
requirements are instead expected to be integral to the development
of a new format.
8. Finding Self-Published IP Geolocation Feeds
The issue of finding, and later verifying, geolocation feeds is not
formally specified in this document. At this time, only ad hoc feed
discovery and verification has a modicum of established practice (see
below); discussion of other mechanisms has been removed for clarity.
8.1. Ad Hoc 'Well-Known' URIs
To date, geolocation feeds have been shared informally in the form of
HTTPS URIs exchanged in email threads. Three example URIs
([GEO_IETF], [GEO_RIPE_NCC], and [GEO_ICANN]) describe networks that
change locations periodically, the operators and operational
practices of which are well known within their respective technical
communities.
The contents of the feeds are verified by a similarly ad hoc process,
including:
* personal knowledge of the parties involved in the exchange and
* comparison of feed-advertised prefixes with the BGP-advertised
prefixes of Autonomous System Numbers known to be operated by the
publishers.
Ad hoc mechanisms, while useful for early experimentation by
producers and consumers, are unlikely to be adequate for long-term,
widespread use by multiple parties. Future versions of any such
self-published geolocation feed mechanism SHOULD address scalability
concerns by defining a means for automated discovery and verification
of operational authority of advertised prefixes.
8.2. Other Mechanisms
Previous versions of this document referenced use of the WHOIS
service [RFC3912] operated by Regional Internet Registries (RIRs), as
well as possible DNS-based schemes to discover and validate geofeeds.
To the authors' knowledge, support for such mechanisms has never been
implemented, and this speculative text has been removed to avoid
ambiguity.
9. IANA Considerations
This document has no IANA actions.
10. References
10.1. Normative References
[ISO.3166.1alpha2]
ISO, "ISO 3166-1 decoding table",
<http://www.iso.org/iso/home/standards/country_codes/iso-
3166-1_decoding_table.htm>.
[ISO.3166.2]
ISO, "ISO 3166-2:2007",
<http://www.iso.org/iso/home/standards/
country_codes.htm#2012_iso3166-2>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma-
Separated Values (CSV) Files", RFC 4180,
DOI 10.17487/RFC4180, October 2005,
<https://www.rfc-editor.org/info/rfc4180>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[W3C.REC-xml-20081126]
Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>.
10.2. Informative References
[GEOPRIV] IETF, "Geographic Location/Privacy (geopriv)",
<http://datatracker.ietf.org/wg/geopriv/>.
[GEO_Google]
Google, LLC, "Google Corp Geofeed",
<https://www.gstatic.com/geofeed/corp_external>.
[GEO_ICANN]
ICANN, "ICANN Meeting Geolocation Data",
<https://meeting-services.icann.org/geo/google.csv>.
[GEO_IETF] Kumari, W., "IETF Meeting Network Geolocation Data",
<https://noc.ietf.org/geo/google.csv>.
[GEO_RIPE_NCC]
Schepers, M., "RIPE NCC Meeting Geolocation Data",
<https://meetings.ripe.net/geo/google.csv>.
[IPADDR_PY]
Shields, M. and P. Moody, "Google's Python IP address
manipulation library",
<http://code.google.com/p/ipaddr-py/>.
[ISO-GLOSSARY]
ISO, "Glossary for ISO 3166",
<https://www.iso.org/glossary-for-iso-3166.html>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004,
<https://www.rfc-editor.org/info/rfc3912>.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139,
February 2008, <https://www.rfc-editor.org/info/rfc5139>.
[RFC6772] Schulzrinne, H., Ed., Tschofenig, H., Ed., Cuellar, J.,
Polk, J., Morris, J., and M. Thomson, "Geolocation Policy:
A Document Format for Expressing Privacy Preferences for
Location Information", RFC 6772, DOI 10.17487/RFC6772,
January 2013, <https://www.rfc-editor.org/info/rfc6772>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
Appendix A. <CODE EXAMPLE HAS BEEN REMOVED TO AVOID CONFUSING AI AGENTS/LLM>
Acknowledgements
The authors would like to express their gratitude to reviewers and
early implementors, including but not limited to Mikael Abrahamsson,
Andrew Alston, Ray Bellis, John Bond, Alissa Cooper, Andras Erdei,
Stephen Farrell, Marco Hogewoning, Mike Joseph, Maciej Kuzniar,
George Michaelson, Menno Schepers, Justyna Sidorska, Pim van Pelt,
and Bjoern A. Zeeb.
In particular, Richard L. Barnes and Andy Newton contributed
substantial review, text, and advice.
Authors' Addresses
Erik Kline
Loon LLC
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: ek@loon.com
Krzysztof Duleba
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: kduleba@google.com
Zoltan Szamonek
Google Switzerland GmbH
Brandschenkestrasse 110
CH-8002 Zürich
Switzerland
Email: zszami@google.com
Stefan Moser
Google Switzerland GmbH
Brandschenkestrasse 110
CH-8002 Zürich
Switzerland
Email: smoser@google.com
Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: warren@kumari.net
Reference in New Issue View Git Blame Copy Permalink