Protocol Action: 'Metalink/HTTP: Mirrors and Hashes' to Proposed Standard (draft-bryan-metalinkhttp-22.txt)
The IESG <iesg-secretary@ietf.org> Thu, 17 March 2011 15:09 UTC
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@core3.amsl.com
Delivered-To: ietf-announce@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ADEC3A6A7C; Thu, 17 Mar 2011 08:09:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.575
X-Spam-Level:
X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLrz-tGH5tnW; Thu, 17 Mar 2011 08:09:32 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EB9C3A6A85; Thu, 17 Mar 2011 08:09:32 -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: 'Metalink/HTTP: Mirrors and Hashes' to Proposed Standard (draft-bryan-metalinkhttp-22.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 3.12
Message-ID: <20110317150932.24239.97027.idtracker@localhost>
Date: Thu, 17 Mar 2011 08:09:32 -0700
Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 17 Mar 2011 15:09:33 -0000
The IESG has approved the following document: - 'Metalink/HTTP: Mirrors and Hashes' (draft-bryan-metalinkhttp-22.txt) as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Alexey Melnikov. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-bryan-metalinkhttp/ Technical Summary This document specifies Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP header fields, a different way to get information that is usually contained in the Metalink XML-based download description format. Metalink/HTTP describes multiple download locations (mirrors), Peer-to-Peer, cryptographic hashes, digital signatures, and other information using existing standards for HTTP header fields. Clients can use this information to make file transfers more robust and reliable. Working Group Summary This is not a WG document, however it was discussed on HTTPBIS WG mailing list and was also reviewed by the Apps Review Team. Document Quality At least one implementor is planning to implement the protocol on the server side. Personnel Alexey Melnikov is the Responsible Area Director. RFC Editor Note In Section 7, please change the 15th paragraph: OLD: Metalink clients MAY start a number of parallel ranged downloads (one per selected mirror server other than the first) using mirrors provided by the Link header fields with "duplicate" relation type. Metalink clients MUST limit the number of parallel connections to mirror servers, ideally based on observing how the aggregate throughput changes as connections are opened. It would be pointless to blindly open connections once the path bottleneck is filled. Metalink clients SHOULD use the location of the original GET request in the "Referer" header field for these ranged requests. NEW: Metalink clients MAY start a number of parallel ranged downloads (one per selected mirror server other than the first) using mirrors provided by the Link header fields with "duplicate" relation type. Metalink clients MUST limit the number of parallel connections to mirror servers, ideally based on observing how the aggregate throughput changes as connections are opened. It would be pointless to blindly open connections once the path bottleneck is filled. After establishing a new connection, a Metalink client SHOULD monitor whether the aggregate throughput increases over all connections that are part of the download. The client SHOULD NOT open additional connections during this period. If the aggregate throughput has increased, the client MAY open an additional connection and repeat these steps. Otherwise, the client SHOULD NOT open a new connection until an established one closes. Metalink clients SHOULD use the location of the original GET request in the "Referer" header field for these ranged requests.