Protocol Action: 'Forwarded HTTP Extension' to Proposed Standard (draft-ietf-appsawg-http-forwarded-10.txt)
The IESG <iesg-secretary@ietf.org> Fri, 12 October 2012 15:38 UTC
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD0921F8646 for <ietf-announce@ietfa.amsl.com>; Fri, 12 Oct 2012 08:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.507
X-Spam-Level:
X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjI7wXydzcz8; Fri, 12 Oct 2012 08:38:39 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13AE21F8658; Fri, 12 Oct 2012 08:38:38 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'Forwarded HTTP Extension' to Proposed Standard (draft-ietf-appsawg-http-forwarded-10.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20121012153838.19308.80457.idtracker@ietfa.amsl.com>
Date: Fri, 12 Oct 2012 08:38:38 -0700
Cc: RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Oct 2012 15:38:39 -0000
The IESG has approved the following document: - 'Forwarded HTTP Extension' (draft-ietf-appsawg-http-forwarded-10.txt) as Proposed Standard This document is the product of the Applications Area Working Group. The IESG contact persons are Barry Leiba and Pete Resnick. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ Technical Summary This document standardizes an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, such as the originating IP address of a request and the 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 is meant to replace several ad-hoc solutions already deployed today. Working Group Summary Nothing worth noting. Document Quality There are several implementations of similar header fields already in use. Personnel Alexey Melnikov is the document shepherd. Barry Leiba is the responsible AD. RFC Editor Note: 1. In the ABNF in Section 4, there are two items that have angle-bracketed text in them: token = <Defined in [I-D.ietf-httpbis-p1-messaging], Section 3.2.4> quoted-string = <Defined in [I-D.ietf-httpbis-p1-messaging], Section 3.2.4> The line breaks are artifacts of the editing and the length of the reference text. It's important that in the final version, there be no line break between the "<" and the ">". For example: token = <Defined in [RFC9999], Section 3.2.4> 2. Please make the following change in Section 8.3, paragraph 1: OLD A proxy that intends or is widely used to anonymize the user MUST NOT use the header field described in this document. NEW A proxy that intends to or is widely used to anonymize the user MUST NOT use the header field described in this document. For any proxy, if the HTTP request contains header fields that specifically request privacy semantics, the proxy SHOULD NOT use the header field described in this document.