Hi Ian, Great comments, thank you so much for taking the time to examine this! These are issues that needed to be addressed.
Do you mind if I forward this to the metalink-discussion list? I'll put the changes here, let me know if they are an improvement, or suggest a change. On Wed, Aug 27, 2008 at 7:33 AM, Ian Macfarlane <[EMAIL PROTECTED]> wrote: > A few comments regarding the draft at > http://tools.ietf.org/html/draft-bryan-metalink-00 > > (1) With regards to the "type "attribute of the metalink:url element > in 4.2.17.2, I think it should be made clear that this overrides any > file extension sniffing specified in 4.2.17. 4.2.17.2. The "type" Attribute metalink:url elements MAY have a "type" attribute that indicates the IRI type. The "type" attribute overrides any file extension sniffing specified above. > (2) With regards to the metalink:url element in 4.2.17, it is not > clear if the IRI must end with ".torrent", or if the path should, e.g. > does http://example.com/file.torrent?id=1 count? What about > http://example.com/generate.php?file.torrent 6. The value "bittorrent" signifies that the IRI leads to a BitTorrent .torrent file as specified in [BITTORRENT]. Metalink Processors that do not support BitTorrent should ignore this type and also ignore metalink:url elements which retrieve files that end with the extension ".torrent". > (3) Also with regards to the "type "attribute of the metalink:url > element in 4.2.17.2, it's slightly inconsistent to allow both > http/https/ftp/etc as well as "bittorrent" as types, as a .torrent > file itself can be sent over any of these protocols. There is explicit > information about the protocol from the scheme in these URLs. I would > suggest "direct" (or omit altogether) for this type of file, and the > Metalink Processor should infer the protocol from the scheme used. What about requiring that "bittorrent" is used as a "type" attribute since .torrent files can be acquired from multiple methods, & just examining the IRI as you mentioned can be misleading? > (4) With regards to the metalink:url element "preference" attribute in > 4.2.17.1, it is not entirely clear if a Metalink Processor which can > download simultaneously should download from two locations where one > has a lower priority. A comment such as "A Metalink Processor SHOULD > do xxx" would be helpful. I'm not sure what to put here :) This sentence would accurately describe what they do now. In our pre-ID version, we have a "maxconnections" attribute where you can limit the amount of segments for a download. "A Metalink Processor MAY download different segments of a file from more than one IRI simultaneously, and when doing so SHOULD first use the highest priority IRIs and then use lower ones." > (5) With regards to the "name" attribute in 4.1.3.1, instead of "Only > relative paths are allowed" I think using the formal restrictive > language of the standards process is a good idea here, e.g."The path > MUST be relative". It might also be a good idea to add that the path > MUST NOT begin with a "/" or contain "../" (and possibly ./") > [technically this should be starting with ../ or ./ or containing /.. > or /. I think]. In this example, a subdirectory debian-amd64/sarge/ will be created and a file named Contents-amd64.gz will be created inside it. The path MUST be relative. The path MUST NOT begin with a "/" or contain "../" or "./" Metalink Processors MUST NOT allow directory traversal. > (6) Under 4.1.4 where it says "This specification assigns no > significance to the order of metalink:url elements" it might be useful > to include a reference to the "preference" attribute. This specification assigns no significance to the order of metalink: url elements. Significance is determines by the value of the "preference" attribute of the metalink:url elements. > (7) With regards to verification (4.1.6.1 and 4.2.4.1) there is no > information as to how a Metalink Processor should deal with one (can > it ignore it) or deal with multiple hash types (e.g. if there is MD5 > and SHA1, MUST / MAY / MUST NOT it check more than one?). Also, it > might be useful to extend metalink documents with new verification > methods before they arrive in the standard. Perhaps unknown types > could be allowed here? The same comments mostly apply to digital > signatures too (4.2.13). I agree that unknown hash types or digital signatures should be allowed. This document defines nine initial values for hash types. It may be useful to extend Metalink documents with new verification methods, so unknown types are allowed. and metalink:signature elements MUST have a "type" attribute. The inital value of "type" is the string that is non-empty and matches "pgp". It may be useful to extend Metalink documents with new types of digital signatures, so unknown types are allowed. What do you suggest about dealing with multiple hash types? An issue could be if someone malicious makes a metalink where the MD5 matches that of something published by a legit group, but also includes a SHA-256 checksum, and if clients prefer & only verify SHA-256, then the file could appear to be good even if the downloader looked inside the metalink & compared the MD5 (if the legit group didn't also use & publish SHA-256 checksums too). - Show quoted text - > (8) Formatting nit last - the use of spacing in the nesting of XML > elements is pretty inconsistent - so instead of this on page 4: > > <?xml version="1.0" encoding="UTF-8" ?> > <metalink version="3.0" xmlns="http://metalinker.org";> > <published>2008-05-15T12:23:23Z</published> > <files> > <file name="example.ext"> > <description>A description of the example file for download. > </description> > <verification> > <hash type="md5">83b1a04f18d6782cfe0407edadac377f</hash> > <hash type="sha1">80bc95fd391772fa61c91ed68567f0980bb45fd9 > </hash> > </verification> > <resources> > <url>ftp://ftp.example.com/example.ext</url> > <url>http://example.com/example.ext</url> > <url>http://example.com/example.ext.torrent</url> > </resources> > </file> > </files> > </metalink> > > It would be much nicer if it were nested something like this: > > <?xml version="1.0" encoding="UTF-8" ?> > <metalink version="3.0" xmlns="http://metalinker.org";> > <published>2008-05-15T12:23:23Z</published> > <files> > <file name="example.ext"> > <description>A description of the example file for > download.</description> > <verification> > <hash type="md5">83b1a04f18d6782cfe0407edadac377f</hash> > <hash type="sha1">80bc95fd391772fa61c91ed68567f0980bb45fd9 > </hash> > </verification> > <resources> > <url>ftp://ftp.example.com/example.ext</url> > <url>http://example.com/example.ext</url> > <url>http://example.com/example.ext.torrent</url> > </resources> > </file> > </files> > </metalink> Done, if: <description>A description of the example file for download.</description> is the only thing changed? The updated ID is draft-bryan-metalink-01pre.txt http://groups.google.com/group/metalink-discussion/files http://www.metalinker.org/ID/draft-bryan-metalink-01pre.txt -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
