W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2011

Re: draft-bryan-metalinkhttp-18.txt

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 19 Jan 2011 11:27:17 +0100
Message-ID: <4D36BC85.1040704@gmx.de>
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: 

>>    ...
>> 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"
>>    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. "


> ...
> yes :)
> thanks for the thorough review!
> ...

You're welcome.

Best regards, Julian
Received on Wednesday, 19 January 2011 10:28:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:56 UTC