Subject: Metalink: higher availability and integrity downloads

From: [email-masked]
Date: Wed, 25 Apr 2007 19:01:31 +0000

Hello,

Metalink is an XML format that lists multiple ways (FTP/HTTP/P2P/rsync) to retrieve files, along with checksums and other metadata. It is mostly used by download managers.

Metalink is not restricted to just HTTP, but Lisa Dusseault suggested I post here, looking for "expressions of interest in the basic concept, and volunteers to help with the work (at the very least, reviewers)."

Some basic features the information in a metalink can be used for:
- Listing multiple mirrors for higher availability.
- Automatic error recovery and repair of corrupted downloads.
- Add a file or multiple files to a download queue.
- Share a library of files between filesharing applications.
- Simplified download pages.

For more information:

http://en.wikipedia.org/wiki/Metalink

"Metalink solves the first problem — how to find the most speedy way to download a file — by grouping different download protocols into one protocol. This enables Metalink clients to automatically switch between different mirror servers without explicit user instructions. Not only multiple server information is described but also meta-data (e.g., the location of the server, document tags and license)."

http://www.geospatialsemanticweb.com/2007/02/25/metalink-unifies-internet-downloads

Thanks,

-- 
(( Anthony Bryan
  )) Metalink [ http://www.metalinker.org ]

---

From: Eric Lawrence <[email-masked]>
Date: Wed, 25 Apr 2007 14:42:57 -0700

One of my developers has raised some concerns about the proposed URI-formatted version of Metalink.

---
The meaning of the fragment of a URI is determined by the content type of the resource identified by the URI.  Changes to this should be discussed with the URI WG.

The current proposal does not appear to be extensible.  For instance in <http://BaseURL#!name1!http://value1URL#!name2!http://value2URL> you can't tell if name2 and its value belongs to BaseURL or value1URL.

If you were to encode the values in some fashion then it would be possible to tell.  For instance in <http://BaseURL#!name1!http%3a%2f%2fvalue1URL%23%21name2%21http%253a%252f%252fvalue2URL> it's possible to tell that BaseURL has only one name/value pair and that the value is a URI that has its own name/value pair embedded in the same fashion.  Or in the URI <http://BaseURL#!name1!http%3a%2f%2fvalue1URL%23!name2!http%3a%2f%2fvalue2URL> you can tell that BaseURL has two name/value pairs the value of both being a URL with no name/value pairs.

URLs locate specific resources based on the scheme name of the URL.  Embedding other information that usurps the decisions that would be made by the scheme name of the URL seems like a misuse of a URL as well as a potential security issue for implementers.  Alternate solutions should be discussed.
---

Thanks,

Eric Lawrence
Program Manager
Internet Explorer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, April 25, 2007 12:02 PM
To: [email-masked]
Subject: Metalink: higher availability and integrity downloads

Hello,

For more information:

"Metalink solves the first problem - how to find the most speedy way to download a file - by grouping different download protocols into one protocol. This enables Metalink clients to automatically switch between different mirror servers without explicit user instructions. Not only multiple server information is described but also meta-data (e.g., the location of the server, document tags and license)."

Thanks,

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Apr 2007 10:00:51 +0200

> http://www.geospatialsemanticweb.com/2007/02/25/metalink-unifies-internet-downloads

Anthony,

some thoughts...:

- Is your plan to turn this into an IETF publication? I wasn't really sure.

- If this is already deployed, you probably should start the 
registration process for the MIME type. See 
<http://tools.ietf.org/html/rfc4288>.

- There seems to be an overlap with extended XLinks (see 
<http://www.w3.org/TR/xlink/#extended-link>). Did you consider re-using 
that vocabulary?

- As Eric pointed out, the "!" notation in fragment identifiers (see 
Section 1.7) isn't really compatible with how URIs work (see RFC3986).

Best regards, Julian