Hello again!  As I have mentioned before the Bootstrapper has an awesome feature called HomeSite to download packages.  I would like to explain how we at Microsoft setup our HomeSite links. 

The main difficulty with adding HomeSite links to Bootstrapper packages is that they must remain static.  If you tell people that your custom package can be downloaded from http:// foo/bar then you are pretty much signing up to host those packages there forever. Because if you ever move or change that link then every existing Bootstrapper created which deploys that custom package via HomeSite will fail. 

A way the Office team learned to combat this was the use of FWLinks (forwarding links).  Essentially you specify a GUID or ID in your URL and the web server then looks it up from a database and redirects you to the current, correct link.  This way you can move the final package as many times as you want without breaking anything, because you are referring to the static GUID/ID link which in turn forwards you to the dynamic download link.

An example, this link points to the Beta2 redist of the 2.0 .NET FX:
http://go.microsoft.com/fwlink/?LinkId=37283
which in turn maps to:
http://www.microsoft.com/downloads/details.aspx?FamilyId=7ABD8C8F-287E-4C7E-9A4A-A4ECFF40FC8E&displaylang=en

Also worth noting is that we overload some of those links to download localized version of the same package files, indicated by adding a clcid ID.  So for example the download for SQL Sever Express Beta2 is at:
http://go.microsoft.com/fwlink/?LinkId=37280&clcid=0x409 
"409" refers to the English package, whereas that number can be changed to refer to the Russian, Chinese, Spanish, etc.

So in short the Bootstrapper's HomeSite feature does a great job in allowing you to take the burden of hosting redist files (rather than developers using your prereqs) but you must be careful when choosing a HomeSite link because changing the HomeSite link after developers have taken a dependecy on it breaks existing Bootstrappers.