Network Working Group A. Bryan, Ed. Internet-Draft N. McNab Intended status: Standards Track Metalinker Project Expires: April 2, 2010 H. Nordstrom September 29, 2009 MetaLinkHeader: Mirrors and Checksums in HTTP Headers draft-bryan-metalinkhttp-07 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 2, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document specifies MetaLinkHeader: Mirrors and Checksums in HTTP Headers, an alternative to the Metalink XML-based download Bryan, et al. Expires April 2, 2010 [Page 1] Internet-Draft MetaLinkHeader: Mirrors and Checksums September 2009 description format. MetaLinkHeader describes multiple download locations (mirrors), Peer-to-Peer, checksums, digital signatures, and other information using existing standards. Clients can transparently use this information to make file transfers more robust and reliable. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Mirrors / Multiple Download Locations . . . . . . . . . . . . 5 4. Peer-to-Peer Descriptions / Metainfo . . . . . . . . . . . . . 5 5. OpenPGP Signatures . . . . . . . . . . . . . . . . . . . . . . 6 6. Checksums of Whole Files . . . . . . . . . . . . . . . . . . . 6 7. Client / Server Multi-source Download Interaction . . . . . . 6 7.1. Early File Mismatch Detection with Strong ETag or Instance Digest from Mirrors . . . . . . . . . . . . . . . 8 7.2. Error Recovery . . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8.1. Link Relation Type Registration: "duplicate" . . . . . . . 10 8.2. Hypertext Transfer Protocol (HTTP) Digest Algorithm Values Registration . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 11 9.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.3. Cryptographic Hashes . . . . . . . . . . . . . . . . . . . 11 9.4. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgements and Contributors . . . . . . . . . . 12 Appendix B. Comparisons to Similar Options (to be removed by RFC Editor before publication) . . . . . . . . . . . 13 Appendix C. Document History (to be removed by RFC Editor before publication) . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Bryan, et al. Expires April 2, 2010 [Page 2] Internet-Draft MetaLinkHeader: Mirrors and Checksums September 2009 1. Introduction MetaLinkHeader is an alternative to Metalink, usually an XML-based document format [draft-bryan-metalink]. MetaLinkHeader attempts to provide as much functionality as the Metalink/XML format by using existing standards such as Web Linking [draft-nottingham-http-link-header], Instance Digests in HTTP [RFC3230], and ETags. MetaLinkHeader is used to list information about a file to be downloaded. This includes lists of multiple URIs (mirrors), Peer-to-Peer information, checksums, and digital signatures. 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 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 of the number of problems that can occur during a download lead to frustration on the part of users. All the information about a download, including mirrors, checksums, digital signatures, and more can be transferred in coordinated HTTP Headers. This Metalink transfers the knowledge of the download server (and mirror database) to the client. Clients can fallback to other 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 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 portions of a file are downloaded from multiple mirrors (and optionally, Peer-to-Peer) simultaneously, which frequently results in a faster download. [[ Discussion of this draft should take place on IETF HTTP WG mailing list at ietf-http-wg@w3.org or the Metalink discussion mailing list located at metalink-discussion@googlegroups.com. To join the list, visit http://groups.google.com/group/metalink-discussion . ]] Bryan, et al. Expires April 2, 2010 [Page 3] Internet-Draft MetaLinkHeader: Mirrors and Checksums September 2009 1.1. Examples A brief Metalink server response with checksum, mirrors, .metalink, and OpenPGP signature: Link: ; rel="duplicate" Link: ; rel="duplicate" Link: ; rel="describedby"; type="application/x-bittorrent" Link: ; rel="describedby"; type="application/metalink4+xml" Link: ; rel="describedby"; type="application/pgp-signature" Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5= 1.2. Notational Conventions This specification describes conformance of MetaLinkHeader. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119], as scoped to those conformance targets. 2. Requirements In this context, "MetaLink" refers to a MetaLinkHeader which consists of mirrors and checksums in HTTP Headers as described in this document. "Metalink/XML" refers to the XML format described in [draft-bryan-metalink]. Metalink servers are HTTP servers that MUST have lists of mirrors and use the Link header [draft-nottingham-http-link-header] to indicate them. They also MUST provide checksums of files via Instance Digests in HTTP [RFC3230], whether requested or not. Mirror and checksum information provided by the originating Metalink server MUST be considered authoritative. Metalink servers and their associated mirror servers SHOULD all share the same ETag policy (ETag Synchronization), i.e. based on the file contents (checksum) and not server-unique filesystem metadata. The emitted ETag may be implemented the same as the Instance Digest for simplicity. Mirror servers are typically FTP or HTTP servers that "mirror" another server. That is, they provide identical copies of (at least some) files that are also on the mirrored server. Mirror servers MAY be Metalink servers. Mirror servers MUST support serving partial content. Mirror servers SHOULD support Instance Digests in HTTP Bryan, et al. Expires April 2, 2010 [Page 4] Internet-Draft MetaLinkHeader: Mirrors and Checksums September 2009 [RFC3230]. Optimally, HTTP mirror servers will share the same ETag policy as the Metalink server and provide Instance Digests. Metalink clients use the mirrors provided by a Metalink server with Link header [draft-nottingham-http-link-header]. Metalink clients MUST support HTTP and MAY support FTP, BitTorrent, or other download methods. Metalink clients MUST switch downloads from one mirror to another if the one mirror becomes unreachable. Metalink clients are RECOMMENDED to support multi-source, or parallel, downloads, where portions of a file are downloaded from multiple mirrors simultaneously (and optionally, from Peer-to-Peer sources). Metalink clients MUST support Instance Digests in HTTP [RFC3230] by requesting and verifying checksums. Metalink clients MAY make use of digital signatures if they are offered. 3. Mirrors / Multiple Download Locations Mirrors are specified with the Link header [draft-nottingham-http-link-header] and a relation type of "duplicate" as defined in Section 8.1. A brief Metalink server response with two mirrors only: Link: ; rel="duplicate"; pri=1; pref=1 Link: ; rel="duplicate"; pri=2 Mirror servers are listed in order of priority or have a "pri" value, where mirrors with lower values are used first. There are two types of mirror servers: preferred and normal. Optimally, HTTP mirror servers will share the same ETag policy as the Metalink server, provide Instance Digests, or both. These mirrors are preferred, and make it possible to detect early on, before data is transferred, if the file requested matches the desired file. Preferred HTTP mirror servers have a "pref" value of 1. [[Some organizations have many mirrors. Only send a few mirrors, or only use the Link header if Want-Digest is used?]] 4. Peer-to-Peer Descriptions / Metainfo Ways to download a file over Peer-to-Peer networks are specified with the Link header [draft-nottingham-http-link-header] and a relation type of "describedby" and a type parameter hat indicates the MIME type of the metadata available at the IRI. Bryan, et al. Expires April 2, 2010 [Page 5] Internet-Draft MetaLinkHeader: Mirrors and Checksums September 2009 A brief Metalink server response with .torrent and .metalink: Link: ; rel="describedby"; type="application/x-bittorrent" Link: ; rel="describedby"; type="application/metalink4+xml" 5. OpenPGP Signatures OpenPGP signatures are specified with the Link header [draft-nottingham-http-link-header] and a relation type of "describedby" and a type parameter of "application/pgp-signature". A brief Metalink server response with OpenPGP signature only: Link: ; rel="describedby"; type="application/pgp-signature" 6. Checksums of Whole Files Metalink servers MUST provide Instance Digests in HTTP [RFC3230] for files they describe with mirrors. Mirror servers SHOULD as well. A brief Metalink server response with checksum: Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5= 7. Client / Server Multi-source Download Interaction Metalink clients begin a download with a standard HTTP [RFC2616] GET request to the Metalink server. A Range limit is optional, not required. GET /distribution/example.ext HTTP/1.1 Host: www.example.com Alternatively, Metalink clients can use a HEAD request to discover mirrors via Link headers. After that, the client follows with a GET request as usual. The Metalink server responds with the data and these headers: Bryan, et al. Expires April 2, 2010 [Page 6] Internet-Draft MetaLinkHeader: Mirrors and Checksums September 2009 HTTP/1.1 200 OK Accept-Ranges: bytes Content-Length: 14867603 Content-Type: application/x-cd-image Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5=" Link: ; rel="duplicate" Link: ; rel="duplicate" Link: ; rel="describedby"; type="application/x-bittorrent" Link: ; rel="describedby"; type="application/metalink4+xml" Link: ; rel="describedby"; type="application/pgp-signature" Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5= From the Metalink server response the client learns the following metadata about the requested object, in addition to also starting to receive the object: o Mirror profile link. o Instance Digest. o Object size. o ETag. o Peer-to-peer information. o Digital signature. o Metalink/XML, which can include partial file checksums to repair a file. If the object is large and gets delivered slower than expected then the Metalink client starts a number of parallel ranged downloads (one per selected mirror server other than the first) using mirrors provided by the Link header with "duplicate" relation type, using the location of the original GET request in the "Referer" header field. If no Range limit was given in the original request then work from the tail of the object (the first request is still running and will eventually catch up), otherwise continue after the range requested in the first request. If ETags are coordinated between mirrors, If-Match conditions based on the ETag SHOULD be used to quickly detect out-of-date mirrors by using the ETag from the Metalink server response. If no indication of ETag syncronisation/knowledge is given then If-Match should not be used, and optimally there will be an Instance Digest in the mirror response which we can use to detect a mismatch early, and if not then a mismatch won't be detected until the completed object is verified. One of the client requests to a mirror server: Bryan, et al. Expires April 2, 2010 [Page 7] Internet-Draft MetaLinkHeader: Mirrors and Checksums September 2009 GET /example.ext HTTP/1.1 Host: www2.example.com Range: bytes=7433802- If-Match: "thvDyvhfIqlvFe+A9MYgxAfm1q5=" Referer: http://www.example.com/distribution/example.ext The mirror servers respond with a 206 Partial Content HTTP status code and appropriate "Content-Length" and "Content Range" header fields. The mirror server response, with data, to the above request: HTTP/1.1 206 Partial Content Accept-Ranges: bytes Content-Length: 7433801 Content-Range: bytes 7433802-14867602/14867603 Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5=" Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5= If the first request was not Range limited then abort it by closing the connection when it catches up with the other parallel downloads of the same object. Downloads from mirrors that do not have the same file size as the Metalink server MUST be aborted. Once the download has completed, the Metalink client MUST verify the checksum of the file. 7.1. Early File Mismatch Detection with Strong ETag or Instance Digest from Mirrors In HTTP terms, the requirement is that merging of ranges from multiple responses must be verified with a strong validator, which in this context is the same as either Instance Digest or a strong ETag. In most cases it is sufficient that the Metalink server provides mirrors and Instance Digest information, but operation will be more robust and efficient if the mirror servers do implement a synchronized ETag as well. In fact, the emitted ETag may be implemented the same as the Instance Digest for simplicity, but there is no need to specify how the ETag is generated, just that it needs to be shared among the mirror servers. If the mirror server provides neither synchronized ETag or Instance Digest, then early detection of mismatches is not possible unless file length also differs. Finally, the error is still detectable, after the download has completed, when the merged response is verified. ETag can not be used for verifying the integrity of the received content. But it is a guarantee issued by the Metalink server that the content is correct for that ETag. And if the ETag given by the Bryan, et al. Expires April 2, 2010 [Page 8] Internet-Draft MetaLinkHeader: Mirrors and Checksums September 2009 mirror server matches the ETag given by the master server, then we have a chain of trust where the master server authorizes these responses as valid for that object. This guarantees that a mismatch will be detected by using only the synchronized ETag from a master server and mirror server, even alerted by the mirror servers themselves by responding with an error, preventing accidental merges of ranges from different versions of files with the same name. This even includes many malicious attacks where the data on the mirror has been replaced by some other file, but not all. Synchronized ETag can not strictly protect against malicious attacks or server or network errors replacing content, but neither can Instance Digest on the mirror servers as the attacker most certainly can make the server seemingly respond with the expected Instance Digest even if the file contents have been modified, just as he can with ETag, and the same for various system failures also causing bad data to be returned. The Metalink client has to rely on the Instance Digest returned by the Metalink master server in the first response for the verification of the downloaded object as a whole. If the mirror servers do return an Instance Digest, then that is a bonus, just as having them return the right set of Link headers is. The set of trusted mirrors doing that can be substituted as master servers accepting the initial request if one likes. The benefit of having slave mirror servers (those not trusted as masters) return Instance Digest is that the client then can detect mismatches early even if ETag is not used. Both ETag and slave mirror Instance Digest do provide value, but just one is sufficient for early detection of mismatches. If none is provided then early detection of mismatches is not possible unless the file length also differs, but the error is still detected when the merged response is verified. 7.2. Error Recovery If the object checksum does not match the Instance Digest then fetch the Metalink/XML or other recovery profile link, where partial file checksums can be found, allowing detection of which server returned bad information. If the Instance Digest computation does not match then the client needs to fetch the partial file checksums and from there figure out what of the downloaded data can be recovered and what needs to be fetched again. If no partial checksums are available, then the client MUST fetch the complete object from a trusted Metalink server. Bryan, et al. Expires April 2, 2010 [Page 9] Internet-Draft MetaLinkHeader: Mirrors and Checksums September 2009 Partial file checksums can be used to detect errors during the download. 8. IANA Considerations Accordingly, IANA has made the following registrations. 8.1. Link Relation Type Registration: "duplicate" o Relation Name: duplicate o Description: Refers to a resource whose available representations are byte-for-byte identical with the corresponding representations of the context IRI. o Reference: This specification. o Notes: This relation is for static resources. That is, an HTTP GET request on any duplicate will return the same representation. It does not make sense for dynamic or POSTable resources and should not be used for them. 8.2. Hypertext Transfer Protocol (HTTP) Digest Algorithm Values Registration This document makes use of the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" specified in [RFC3230]. Digest Algorithm: SHA-224 Description: The SHA-224 algorithm [SHS]. The output of this algorithm is encoded using the base64 encoding [RFC2045]. Reference: [SHS] [RFC2045] Digest Algorithm: SHA-256 Description: The SHA-256 algorithm [SHS]. The output of this algorithm is encoded using the base64 encoding [RFC2045]. Reference: [SHS] [RFC2045] Digest Algorithm: SHA-384 Description: The SHA-384 algorithm [SHS]. The output of this algorithm is encoded using the base64 encoding [RFC2045]. Reference: [SHS] [RFC2045] Digest Algorithm: SHA-512 Bryan, et al. Expires April 2, 2010 [Page 10] Internet-Draft MetaLinkHeader: Mirrors and Checksums September 2009 Description: The SHA-512 algorithm [SHS]. The output of this algorithm is encoded using the base64 encoding [RFC2045]. Reference: [SHS] [RFC2045] 9. Security Considerations 9.1. URIs and IRIs Metalink clients handle URIs and IRIs. See Section 7 of [RFC3986] and Section 8 of [RFC3987] for security considerations related to their handling and use. 9.2. Spoofing There is potential for spoofing attacks where the attacker publishes Metalinks with false information. In that case, this could deceive unaware downloaders that they are downloading a malicious or worthless file. Also, malicious publishers could attempt a distributed denial of service attack by inserting unrelated IRIs into Metalinks. 9.3. Cryptographic Hashes Currently, some of the digest values defined in Instance Digests in HTTP [RFC3230] are considered insecure. These include the whole Message Digest family of algorithms which are not suitable for cryptographically strong verification. Malicious people could provide files that appear to be identical to another file because of a collision, i.e. the weak cryptographic hashes of the intended file and a substituted malicious file could match. If a Metalink contains whole file hashes as described in Section 6, it SHOULD include "sha" which is SHA-1, as specified in [RFC3174], or stronger. It MAY also include other hashes. 9.4. Signing Metalinks should include digital signatures, as described in Section 5. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. 10. References Bryan, et al. Expires April 2, 2010 [Page 11] Internet-Draft MetaLinkHeader: Mirrors and Checksums September 2009 10.1. Normative References [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", RFC 3230, January 2002. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [SHS] National Institute of Standards and Technology (NIST), "Secure Hash Standard", FIPS PUB 180-3, October 2008, . [draft-nottingham-http-link-header] Nottingham, M., "Web Linking", draft-nottingham-http-link-header-06 (work in progress), July 2009. 10.2. Informative References [draft-bryan-metalink] Bryan, A., Ed., Tsujikawa, T., McNab, N., and P. Poeml, "The Metalink Download Description Format", draft-bryan-metalink-16 (work in progress), August 2009. Appendix A. Acknowledgements and Contributors Thanks to the Metalink community, Mark Nottingham, Daniel Stenberg, Tatsuhiro Tsujikawa, Peter Poeml, Matt Domsch, and Alan Ford. Bryan, et al. Expires April 2, 2010 [Page 12] Internet-Draft MetaLinkHeader: Mirrors and Checksums September 2009 Appendix B. Comparisons to Similar Options (to be removed by RFC Editor before publication) This draft, compared to the Metalink/XML format [draft-bryan-metalink] : o (+) Reuses existing HTTP standards without defining anything new besides a Link Relation Type. It's more of a collection/ coordinated feature set. o (?) The existing standards don't seem to be widely implemented. o (+) No XML dependency. o (?) Existing Metalink/XML clients can be easily converted to support this as well. o (-?) Tied to HTTP, not as generic. FTP/P2P clients won't be using it unless they also support HTTP, unlike Metalink/XML. o (---) Requires changes to server software. o (+) Coordination of mirror servers is preferred, but not required. Coordination may be difficult or impossible unless you are in control of all servers on the mirror network. o (-) Requires server-side support. Metalink/XML can be created by user (or server, but server component/changes not required). o (-) Also, Metalink/XML files are easily mirrored on all servers. Even if usage in that case is not as transparent, it still gives access to users at all mirrors (FTP included) to all download information with no changes needed to the server. o (-) Not portable/archivable/emailable. Metalink/XML is used to import/export transfer queues. Not as easy for search engines to index? o (-) No way to show mirror geographical location (yet). o (-) Not as rich metadata. o (-) Not able to add multiple files to a download queue or create directory structure. draft-ford-http-multi-server compared to this draft : o (+) Plans to define mirrors for whole directories. o (-?) Defines new headers. Doesn't reuse existing standards. o (---) Requires changes to server software. o (---) Requires coordination of all mirror servers, which may be difficult or impossible unless you are in control of all servers on the mirror network. o (---) Doesn't tie in p2p. o (-) No way to show mirror/p2p priority or geographical location (yet). Bryan, et al. Expires April 2, 2010 [Page 13] Internet-Draft MetaLinkHeader: Mirrors and Checksums September 2009 Appendix C. Document History (to be removed by RFC Editor before publication) [[ to be removed by the RFC editor before publication as an RFC. ]] Known issues concerning this draft: o Use of Link header to describe Mirrors. Only send a few mirrors with Link header, or only send them if Want-Digest is used? Some organizations have many mirrors. o A way to differentiate between mirrors that have synchronized ETags and those that don't. o Do we want a way to show that whole directories are mirrored, instead of individual files? o Need an official MIME type for .torrent files or allow "application/x-bittorrent"? -07 : September , 2009. o Preferred mirror servers. -06 : September 24, 2009. o Add Mismatch Detection, Error Recovery, and Digest Algorithm values. o Remove Content-MD5 and Want-Digest. -05 : September 19, 2009. o ETags, preferably matching the Instance Digests. -04 : September 17, 2009. o Temporarily remove .torrent. -03 : September 16, 2009. o Mention HEAD request, negotiate mirrors if Want-Digest is used. -02 : September 6, 2009. o Content-MD5 for partial file checksums. -01 : September 1, 2009. o Link Relation Type Registration: "duplicate" -00 : August 24, 2009. o Initial draft. Bryan, et al. Expires April 2, 2010 [Page 14] Internet-Draft MetaLinkHeader: Mirrors and Checksums September 2009 Authors' Addresses Anthony Bryan (editor) Metalinker Project Email: anthonybryan@gmail.com URI: http://www.metalinker.org Neil McNab Metalinker Project Email: neil@nabber.org URI: http://www.nabber.org Henrik Nordstrom Email: henrik@henriknordstrom.net URI: http://www.henriknordstrom.net/ Bryan, et al. Expires April 2, 2010 [Page 15]