only very small changes: http://tools.ietf.org/html/draft-bryan-metalinkhttp
more descriptive title... MetaLinkHeaders: Mirrors and Checksums in HTTP Headers "duplicate" replaces "alternate" Link: <http://www2.example.com/example.ext>; rel="duplicate"; Link: <ftp://ftp.example.com/example.ext>; rel="duplicate"; Link: <http://example.com/example.ext.torrent>; rel="describedby"; type="torrent"; Link: <http://example.com/example.ext.asc>; rel="describedby"; type="application/pgp-signature"; Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5= On Aug 28, 8:12 pm, Anthony Bryan <[email protected]> wrote: > I was just messing around & needed to put it up because someone posted > what I was writing & I didn't want it to look like I was copying them. > > here are some other shortcomings: > > Appendix B. What's different...?! (to be removed by RFC Editor before > > publication) > > ...or missing, compared to the Metalink XML format > [draft-bryan-metalink] : > > o (+) Reuses existing standards without defining much new stuff. > It's more of a collection/coordinated feature set. > o (+) No XML dependency. > 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 (-?) Could require some coordination of all mirror servers for > all features, which may be difficult or impossible unless you are > in control of all servers on the mirror network. > o (-) Metalink XML could 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 to all download information with no > changes needed to the server. > o (-) Not portable/archivable/emailable. Not as easy for search > engines to index? > o (-) No way to show mirror/p2p priority or geographical location > (yet). > o (---) No chunk checksums/download repair (yet). > o (-) No checksums besides MD5/SHA-1 (yet). > o (-) Not as rich metadata. > o (-) Not able to add multiple files to a download queue or create > directory structure. > > http://tools.ietf.org/html/draft-bryan-metalinkhttp-00#appendix-B > > > > On Fri, Aug 28, 2009 at 6:59 PM, Bram Neijt<[email protected]> wrote: > > > Hi all, > > > Personally, I don't believe in HTTP headers as mirror descriptors. One > > of the main reasons to use mirrors is to keep the load of the primary > > server down. If you want to keep the load down, then you should not > > send the whole file to every user you encounter, but to get the mirror > > list the user will have to hit the link. One way would be to only > > allow a HEAD request, but that seems idiotic to me because there is no > > way to make sure people would only use the head request. > > > I've yet to come up with a problem this additional header complexity > > would solve. > > > Bram > > > On Fri, Aug 28, 2009 at 8:03 PM, Ant Bryan<[email protected]> wrote: > > >> here are my very rough ideas for Metalink in HTTP headers > > >>http://www.ietf.org/id/draft-bryan-metalinkhttp-00.txt > > >> briefly, it's: > > >> Link: <http://www2.example.com/example.ext>; rel="alternate"; > >> Link: <ftp://ftp.example.com/example.ext>; rel="alternate"; > >> Link: <http://example.com/example.ext.torrent>; rel="describedby"; > >> type="torrent"; > >> Link: <http://example.com/example.ext.asc>; rel="describedby"; > >> type="application/pgp-signature"; > >> Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5= > > >> On Jul 28, 5:37 pm, Anthony Bryan <[email protected]> wrote: > >>> this is similar to some of metalink's features, but done in HTTP headers. > > >>> ---------- Forwarded message ---------- > >>> From: Henrik Nordstrom <[email protected]> > >>> Date: Mon, Jul 27, 2009 at 11:03 AM > >>> Subject: Re: HTTP Extensions for Simultaneous Download from Multiple > >>> Mirrors > >>> To: HTTP Working Group <[email protected]> > > >>> This draft made a bit of surprise appearance in the transport area > >>> meeting today: > > >>>http://tools.ietf.org/html/draft-ford-http-multi-server > > >>> My initial reaction is lots of obvious overlap with other work and > >>> misunderstandings of basic HTTP functions like ETag. > > >>> Basic motivation behind the work may be reasonable however. > > >>> I will try to catch the author for a more in-depth discussion shortly. > > >>> Other opinions? > > >>> Regards > >>> Henrik > > >>> -- > >>> (( Anthony Bryan ... Metalink [http://www.metalinker.org] > >>> )) Easier, More Reliable, Self Healing Downloads > > -- > (( Anthony Bryan ... Metalink [http://www.metalinker.org] > )) Easier, More Reliable, Self Healing Downloads --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Metalink Discussion" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/metalink-discussion?hl=en -~----------~----~----~----~------~----~------~--~---
