On Thu, Jun 25, 2009 at 8:27 PM, Peter Poeml<[email protected]> wrote: > Hi! > > There is one thing in the Internet Draft that I'd like to bring to our > attention. Section 4.2.18 sets up a a strong requirement: > All IRIs MUST lead to identical files. > > While surely this would be the intention, in practice I know more > examples where this either isn't the case, and albeit attempted it is > hard to assure. > > Content verification is there to help -- one of the purposes of metalinks. > > It might make sense to put this in a different way. > > Without any content verification being done (well, it is optional!), it > is a relatively hard requirement to make. When a content delivery > infrastructure reaches a certain scale, it becomes difficult though, as > we know. In particular this is true for collaborative mirror networks > formed by volunteers, where, in fact, the referenced IRIs might be > outside of the control of the content provider at all. (Security comes > into play here as well.)
the current text is lacking, I'm glad you brought it up! at the least it should be something like: All IRIs under each "metalink:file" container Element SHOULD lead to identical files. because we don't want ALL the IRIs under separate <file> elements to lead to identical files. 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. maybe content verification should be required for future versions (as in this version for the IETF)? even tho it is extremely important, some lazy implementers :) did not want to add support. as of now, I think only TheWorld browser does not support checksums. it's clear that most implementers see the value in it. > I would tend to make this a SHOULD, for practical reasons. Also, the > text could/should expand both on the implications. care to throw in some expansion text? :) > Alternatively, would the following be an idea? > All referenced IRIs SHOULD lead to identical resources, if the > Metalink includes a "metalink:verification" container with at least > one "metalink:hash" element. All referenced IRIs MUST be identical, if > the latter is not the case. If the Metalink Document includes a "metalink:verification" container element with at least one "metalink:hash" element, all referenced IRIs SHOULD lead to identical resources. If the Metalink Document does not include a "metalink:verification" container element with at least one "metalink:hash" element, all referenced IRIs MUST be identical. I don't know, do you think that is necessary or better? -- (( 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 -~----------~----~----~----~------~----~------~--~---
