Hi, what do you think about the following changes to the intro of the Internet Draft?
Please read closely, the changes affect 50% of the intro. A patch is attached to this mail that details the changes. I re-wrapped the text before to make the changes easier visible. In particuluar, I'd be thankful if you provide feedback to the last paragraph. I don't know if it the whole intro too long now by enumerating more of the benefits that metalinks brings. I think that these are significant points, but it *could* be too much. That's also why I made it a separate paragraph, anyway. I'm committing the change now, because it is probably easier to revert (or amend) those things that you didn't like. Thanks, Peter
Index: draft-bryan-metalink-23.xml
===================================================================
--- draft-bryan-metalink-23.xml (revision 463)
+++ draft-bryan-metalink-23.xml (working copy)
@@ -64,42 +64,53 @@
<section title="Introduction">
<t>Metalink is an XML-based document format that describes a file or list
- of files to be added to a download queue. Metalinks can list a number of
- files, each with an extensible set of attached metadata. For example,
- each file can have a description, checksum, and list of URIs that it is
+ of files to be downloaded from a server. Metalinks can list a number of
+ files, each with an extensible set of attached metadata.
+ Each listed file can have a description, checksum, and a list of URIs that it is
available from.</t>
- <t>Identical copies of a file are frequently accessible in multiple
- locations on the Internet over a variety of protocols (FTP, HTTP, and
- Peer-to-Peer). In some cases, Users are shown a list of these multiple
- download locations (mirrors) and must manually select a single one on the
- basis of geographical location, priority, or bandwidth. This distributes
- the load across multiple servers. At times, individual servers can be
+ <t>Often, identical copies of a file are accessible in multiple locations
+ on the Internet over a variety of protocols (FTP, HTTP, and
+ Peer-to-Peer). In some cases, users are shown a list of these multiple
+ download locations (mirror servers) and must manually select a single one on the
+ basis of geographical location, priority, or bandwidth. This is done to distribute
+ the load across multiple servers, and to give human users the opportunity
+ to choose a download location that they expect to work best for them.
+ At times, individual servers can be
slow, outdated, or unreachable, but this can not be determined until the
download has been initiated. This can lead to the user canceling the
download and needing to restart it. During downloads, errors in
transmission can corrupt the file. There are no easy ways to repair
- these files. For large downloads this can be extremely troublesome. Any
+ these files. For large downloads this can be especially troublesome. Any
of the number of problems that can occur during a download lead to
- frustration on the part of users.</t>
+ frustration on the part of users, and bandwith wasted with retransmission.</t>
- <t>All the information about a download, including mirrors, checksums,
+ <t>Knowledge about availability of a download on mirror servers can be
+ acquired and maintained by the operators of the origin server, or by third
+ a party. This knowledge, together with checksums,
digital signatures, and more can be stored in a machine-readable Metalink
- file. This Metalink file transfers the knowledge of the download server
- (and mirror database) to the client. Clients can fall back to alternate
- mirrors if the current one has an issue. With this knowledge, the client
- is enabled to work its way to a successful download even under adverse
- circumstances. All this is done transparently to the user and the
+ file. The Metalink file can transfer this knowledge to the user agent,
+ which can peruse it in automatic ways or present the information to a human user.
+ This guidance provided, user agents can fall back to alternate
+ mirrors if the current one has an issue. Thereby, clients
+ are enabled to work their way to a successful download even under adverse
+ circumstances. All this can be done transparently to the human user and the
download is much more reliable and efficient. In contrast, a traditional
- HTTP redirect to a mirror conveys only extremely minimal information -
- one link to one server, and there is no provision in the HTTP protocol to
- handle failures. Other features that some clients provide include
- multi-source downloads, where chunks of a file are downloaded from
- multiple mirrors (and optionally, Peer-to-Peer) simultaneously, which
- frequently results in a faster download. Metalinks also provide
- structured information about downloads that can be indexed by search
- engines.</t>
+ HTTP redirect to one mirror conveys only comparatively minimal information -
+ a referral to a single server, and there is no provision in the HTTP protocol to
+ handle failures.</t>
+ <t>Other features that some clients provide include multi-source
+ downloads, where chunks of a file are downloaded from multiple mirrors
+ (and optionally, Peer-to-Peer) simultaneously, which frequently results
+ in a faster download. Metalinks can leverage HTTP, FTP and Peer-to-Peer
+ protocols together, because regardless over which protocol the Metalink
+ was obtained, it can make a resource accessible through other protocols.
+ If the Metalink was obtained from a trusted source, included verification
+ metadata can solve trust issues when downloading files from replica
+ servers operated by third parties. Metalinks also provide structured
+ information about downloads that can be indexed by search engines.</t>
+
<t>[[ Discussion of this draft should take place on
[email protected]. Past discussion has gone on at the Metalink
discussion mailing list located at [email protected] /
pgp63YxOgiUEC.pgp
Description: PGP signature
