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@ietf.org mailing lists by 2012-07-23. Exceptionally, comments may be sent to iesg@ietf.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. ====================================
