On Jul 1, 12:14 pm, Peter Poeml <[email protected]> wrote: > > > yes, MUST is too strong. the point is that the by design, IRIs that > > are included in a metalink SHOULD lead to identical files. > > will metalinks contain IRIs that aren't identical files? yes. do we > > want it to no longer be a valid metalink if a mirror network is out of > > sync & a file isn't identical? no > > I'm just trying to document the design purpose, that each IRI is a > > valid way to get the same exact file, under perfect conditions. > > > clients should weed out files that have different sizes, & reject > > chunks that don't have the correct checksum, etc. a metalink > > generators will attempt to include IRIs that point to identical files > > to be most helpful, but we want to protect against accidents or > > malicious people that would possibly want to lead to incorrect > > downloads.
how about this for <resources> All elements contained in each metalink:resources element SHOULD lead to identical files. That is, each metalink:url element should be an alternative location for the same file and each metalink:metaurl element should provide metadata to retrieve the same file in another way, such as a peer to peer network. and this for <url> The "metalink:url" element contains the IRI of a file. Most Metalink Documents will contain multiple metalink:url elements, and each one SHOULD be a valid alternative to download the same file. ? -- (( 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 -~----------~----~----~----~------~----~------~--~---
