So I have a question about this draft that wasn't
resolved on apps-discuss and is maybe more suited
for IETF LC anyway.
With geopriv, we've gone to a lot of trouble to
support end-users having some control over their
location privacy.
This HTTP header will be used by proxies to forward
on the IP address of a client, and that will be used
via geo-ip services to locate the HTTP client.
But in this case, there's no control whatsoever
for the end user, nor are they even told that
its happened.
That seems to me to be quite a disconnect, but
I'm not sure what if anything ought be done about
it, since in this case, there's a non-standard
header that's widely deployed that does this.
So if we did try encourage taking the geopriv
approach we'd presumably just be ignored.
Any ideas?
Ta,
S.
On 07/09/2012 05:28 PM, The IESG wrote:
The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'Forwarded HTTP Extension'
<draft-ietf-appsawg-http-forwarded-06.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2012-07-23. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
This document standardizes an HTTP extension header field that allows
proxy components to disclose information lost in the proxying
process, for example, the originating IP address of a request or IP
address of the proxy on the user-agent-facing interface. Given a
trusted path of proxying components, this makes it possible to
arrange it so that each subsequent component will have access to, for
example, all IP addresses used in the chain of proxied HTTP requests.
This document also specifies guidelines for a proxy administrator to
anonymize the origin of a request.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/
No IPR declarations have been submitted directly on this I-D.
====================================
A specific point for Last Call discussion, please:
During AD Evaluation, the registration policy for the new "HTTP
Forwarded parameters" registry (see Section 9) was changed to
"Specification Required" from "RFC Required". This needs further
review during Last Call, for two reasons:
1. While RFC Required forces new registrations through the IETF RFC
process, and might discourage registrations from individuals or
organizations that are unfamiliar with or averse to that process,
Specification Required necessitates the appointment of a Designated
Expert to review the requests and associated specifications. Each of
these policies comes with baggage, and we have to make sure we're
weighing it down with the *right* baggage.
2. If we stay with Specification Required we should include a short
paragraph with rough guidelines for the Designated Expert: what to
consider when approving registration requests. If we want the DE to
approve most requests, just checking the associated specifications for
sanity, we need to say that. If we want the DE to put some judgment
into deciding whether the requested parameters make sense and fit into
the usage model, or whatever, we should say something about that.
Comments and proposed text for this are encouraged.
====================================