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. (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 (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. (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. (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]. (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. (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). (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> Kind regards Ian Macfarlane _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
