- From: Anthony Bryan <anthonybryan@gmail.com>
- Date: Wed, 19 Jan 2011 14:58:39 -0500
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: ietf-http-wg@w3.org, draft-bryan-metalinkhttp@tools.ietf.org
On Wed, Jan 19, 2011 at 5:27 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > 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>) nifty, didn't know how to do that. thanks! > >>> ... >>> >>> 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. I removed them from all the duplicate and describedby ones. >> 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... ok >>> 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 :-) any pointers? >>> ... >>> >>> 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). I guess you can always search by the registry name but the URI seems useful? >> ... >>> >>> 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..."...? ok > 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. is this better? "To have the same ETag policy means that ETags are synchronized across servers for duplicate resources, i.e. byte-for-byte identical files will have the same ETag on mirrors that they have on the Metalink 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. your other mail clears this up, thanks :) >> 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 done :) I'll upload these changes shortly. -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads
Received on Wednesday, 19 January 2011 20:00:26 UTC