- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 19 Jan 2011 11:27:17 +0100
- To: Anthony Bryan <anthonybryan@gmail.com>
- CC: ietf-http-wg@w3.org, draft-bryan-metalinkhttp@tools.ietf.org
On 19.01.2011 10:33, Anthony Bryan wrote: > ... >> ... >> >> [[ Discussion of this draft should take place on IETF HTTP WG mailing >> list at ietf-http-wg@w3.org or the Metalink discussion mailing list >> located at metalink-discussion@googlegroups.com. To join the list, >> visit http://groups.google.com/group/metalink-discussion . ]] >> >> This should go on the front page as "Editorial Note". > > in<abstract>? > > I've moved it to there where it says: > > [[ Discussion of this draft should take place on IETF HTTP WG mailing > list at ietf-http-wg@w3.org although this draft is not a WG item. ]] > ... No, add a <note> element after abstract. (Example: <http://tools.ietf.org/id/draft-ietf-httpbis-p2-semantics-12.xml>) >> ... >> >> 1.2. Examples >> >> A brief Metalink server response with ETag, mirrors, .metalink, >> OpenPGP signature, and a cryptographic hash of the whole file: >> >> Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5=" >> Link:<http://www2.example.com/example.ext>; rel="duplicate" >> Link:<ftp://ftp.example.com/example.ext>; rel="duplicate" >> Link:<http://example.com/example.ext.torrent>; rel="describedby"; >> type="application/x-bittorrent" >> Link:<http://example.com/example.ext.metalink>; rel="describedby"; >> type="application/metalink4+xml" >> Link:<http://example.com/example.ext.asc>; rel="describedby"; >> type="application/pgp-signature" >> Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlO >> DYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ== >> >> Note: there's no need quote the relation type here. > > here or throughout? they are quoted in the RFC 5988 examples. Not for single relation names that just use token characters. > Link:<http://example.com/TheBook/chapter2>; rel="previous"; > title="previous chapter" > > or the MIME type in the type parameter doesn't need to be quoted? RFC 5988 allows it to be non-quoted, but I would advise against it as it violates that 2616 grammar for tokens... >> Note: it's unfortunate that there doesn't seem to be a registered media type >> for torrent files. > > true. I'd fix that if I could. :) Go ahead. You can :-) >> ... >> >> Metalink resources include a Link header [RFC5988] to present a list >> of mirrors in the response to a client request for the resource. >> Metalink servers MUST include the cryptographic hash of a resource >> via Instance Digests in HTTP [RFC3230]. Valid algorithms are found >> in the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest >> Algorithm Values" at >> http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml . >> >> Surplus whitespace. Maybe put the URI into angle brackets. > > I've also seen registries cited in the references. is that better? I think in-lining has a better chance to survive the RFC Editor changes (I believe they don't want to have the URIs in the document at all). >... >> As the term "Etag policy" is important, it might make sense to introduce it >> more formally. > > "Metalink servers and their associated mirror servers SHOULD all share > the same ETag policy, meaning ETags are synchronized across servers, > i.e. byte-for-byte identical files will have the same ETag on all > servers. ETags could be based on the file contents (cryptographic > hash) and not server-unique filesystem metadata." > ... Maybe "To have the same ETag policy means..."...? Also, it appears that you require more than what's needed. For instance, why would it be a problem when byte-for-byte identical files have different ETags on the same server? I think what's relevant is the requirement for the mirror files, not any additional requirements for other files^h^h^h^h^hresources on the server. >> ... >> >> There are two types of mirror servers: preferred and normal. >> Preferred mirror servers are HTTP mirror servers that MUST share the >> same ETag policy as the originating Metalink server. Preferred >> mirrors make it possible to detect early on, before data is >> transferred, if the file requested matches the desired file. >> >> Note: that also could be achieved by introducing a new conditional header >> for the digest, or by using the extension points in the WebDAV "If" header. > > I don't know much about WebDAV but I read section 10.4 of RFC 4918. I > still don't understand. > ... The "If" header can use arbitrary state tokens, and you could make the instance digests one of those. Theoretically. > we use If-Match in the examples. is that wrong? No, this was just a suggestion that you *could* define to make the request conditional based on the digest, in which case the dance about ETag policies wouldn't be needed. >> ... >> Wow. This appears to ignore the overhead of Range requests on the *server*. >> Note that sometimes, content is not served directly from the filesystem, and >> implementing Range may not be possible using seeks. Now one could argue that >> servers suffering from the problem should not support this in the first >> place, but still... >> >> Given the file sizes for which parallel downloads make any sense today, is >> it *really* a good idea to recommend 10K segments? > > nope. how about removing the last 3 sentences& adding > "Note that Range requests impose an overhead on servers and clients > need to be aware of that and not abuse them. " +1 > ... > yes :) > > thanks for the thorough review! > ... You're welcome. Best regards, Julian
Received on Wednesday, 19 January 2011 10:28:08 UTC