Metalink/HTTP: Mirrors and Hashes
draft-bryan-metalinkhttp-22

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'Metalink/HTTP: Mirrors and Hashes' to Proposed Standard (draft-bryan-metalinkhttp-22.txt)

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/

Ballot Text

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.

RFC Editor Note