Re: Update on geo-hint header

Hello,

If I might offer the thought that this data could be useful for those 
systems using http that require it, more so than being something 
designed to locate the server, it would give temporal and spatial data 
to the end point, For whichever reason it might be required. One might 
imagine a wiki in which each endpoint provides the date and location of 
its content, say a historical article, allowing for a far more 
comprehensive tool for filtering a search by time and location. I 
suspect that any attempt to achieve this without the data being a part 
of the protocol, would be quite impossible.

consider also a scientific experiment in which each result set requires 
a precise spacetime, or time and location stamp.

This combined with the use of a julian day date format would be a means 
to add the time zone without any dependency upon the foibles of 
political timezone manipulation and remove the need for consequent 
database lookup for TZ offsets. Another upside to this type of time 
keeping is that, even when the location data is not present, the time is 
more likely to be correct; This is not the case when no location data is 
stored and a local time is used, in which case temporal data is truncated.

Kind regards.

Iain Hill.

On 07/07/2022 01:15, Tommy Pauly wrote:
> Hello HTTP WG,
>
> At our February interim 
> <https://httpwg.org/wg-materials/interim-22-02/agenda.html>, I shared 
> a proposal to share a geolocation hint in HTTP headers as a geohash. 
> During the meeting, we got a lot of useful feedback for how this could 
> be misused and abused.
>
> The motivating use case was more about ensuring that a server 
> understands the “correct” geo-location mapping for an IP address that 
> it already is seeing, as opposed to trying to reveal new information 
> about location. This is specifically useful when going through a VPN / 
> privacy proxy service where the client is aware of its IP selection. 
> Specifically, this works around cases where geo-IP databases are out 
> of date, or have the incorrect granularity (for example, some 
> intermediate databases try to place every IP in a city, so they’ll 
> incorrectly map country-wide IPs to a city in the center of the country).
>
> As such, we’ve revised the proposal to instead provide a header that 
> contains the geo IP database entry that corresponds to the client’s 
> IP, along information in the parameters that points to the 
> authoritative database.
>
> https://www.ietf.org/archive/id/draft-pauly-httpbis-geoip-hint-00.html
>
> Happy to hear thoughts on this direction, and have further discussion 
> at IETF 114.
>
> Best,
> Tommy & David