On Wed, Feb 16, 2011 at 6:15 PM, Ben Campbell <ben(_at_)nostrum(_dot_)com>
wrote:
Thanks for the quick response. I haven't had a chance to look at the new
version yet, but here are my responses to your email comments. I removed
sections where I had no further (non-trivial) comment. Please consider any
removed parts to be the same as an "Okay" response.
Thanks!
Ben.
On Feb 14, 2011, at 4:43 PM, Anthony Bryan wrote:
[...]
was there supposed to be a comment along with
-- section 2, 4th paragraph: "HTTP mirror servers SHOULD share the
same ETag policy as the originating Metalink server."
?
I responded to this one below.
On Fri, Feb 11, 2011 at 6:46 PM, Ben Campbell <ben(_at_)nostrum(_dot_)com>
wrote:
[...]
-- Section 1, paragraph 1, first sentence:
Is this really intended as an alternative to Metalink/XML? It seems like
more of a complementary approach than an alternative one.
well...you could use either, or both :)
"Metalink/HTTP is an alternative and complementary representation of
Metalink information,"...
?
WFM
-- section 2, third paragraph:
If they must have the same eTag policy, should this document not specify at
least one mandatory-to-implement policy?
SHOULD share the same ETag policy.
I added:
"It is up to the administrator of the Metalink server to communicate
the details of the shared ETag policy to the administrators of the
mirror servers so that the mirror servers can be configured with the
same ETag policy."
My comment was about policy implementation, not policy configuration.
Do you expect the method to generate ETags to be configurable in most
implementations? Is that the case among common HTTP servers today? (That's
not rhetorical--I don't know the answer.) And even if it is, is there a risk
that there won't be a common selection between implementations? It doesn't
help to tell an administrator to select a certain policy unless his software
can actually do it. If there was a mandatory-to-implement policy, then that
shouldn't happen.
Apache has an option that fits. I don't know about other server
software. obviously, this would need to be added for them to be able
to be Metalink servers if they don't have it. but, at least initially,
I don't expect every web server to easily be able to also be a
Metalink server without changes.
[...]
-- section 10.2:
What can an implementor do to mitigate spoofing?
nothing, I'm aware of?
added:
As with all downloads, users should only download from trusted sources.
Hmm. What does "trusted" mean in context? Does that have implications on
authentication of the source and integrity protection of the download
session? (i.e. TLS)?
I'm not sure how to word this. a non-TLS source like download.com
could be more trusted than a TLS one from denialofserviceRus.com
[...]
--- Nits/editorial comments:
-- section 2, 4th paragraph: "HTTP mirror servers SHOULD share the same
ETag policy as the originating Metalink server."
what's wrong here?
Oops, sorry, cut-and-paste error. My comment was "This seems redundant with a
similar statement in the previous paragraph"
there is a paragraph on the Metalink server, mirror server, and
client. I think it's ok to reiterate.
paragraph 3 on Metalink servers:
Metalink servers and their associated mirror servers SHOULD all share
the same ETag policy.
paragraph 4 on Mirror servers:
HTTP mirror servers SHOULD share the same ETag policy as the
originating Metalink server.
[...]
-- section 7.1.1, general:
This whole section switches to an almost stream-of-consciousness style. It
has very long sentences with many comma separated clauses that are hard to
follow. It really needs to be rewritten to be more readable and precise.
hahaha :)
this is my fault as a bad editor & a non-native English speaker co-author.
On reflection, I think my comment was a little harsh. But another pass with
some attention to style in the section would help.
no, it needed work.
here's our next pass
http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-bryan-metalinkhttp-20.txt&url2=http://www.metalinker.org/test/mh/draft-bryan-metalinkhttp-21.txt
-- section 7.1.1, paragraph 3:
Paragraph seems self contradictory. How is guaranteeing correct content
different than verifying integrity?
the server sends the correct content but there can be errors during
transfer.
maybe this is not explicit enough. might need to condense some of this down.
earlier we state:
Error detection requires Instance Digests to detect errors in transfer
after the transfers have completed.
I think a rewording would help, as I took "guaranteeing correct content" to
mean "guaranteeing the client receives correct content" rather than
"guaranteeing the server sends correct content".
"ETags can not be used for verifying the integrity of the received
content. If the ETag given by the mirror server matches the ETag given
by the Metalink server, then the Metalink client assumes the responses
are valid for that object. "
-- section 7.1.2, 2nd paragraph: "If the object cryptographic hash does not
match the Instance Digest then fetch the Metalink/XML if available, where
partial file cryptographic hashes can be found, allowing detection of which
server returned incorrect data."
I can't parse this sentence.
If the cryptographic hash of the object does not match the Instance
Digest from the Metalink server, then the client SHOULD fetch the
Metalink/XML (if available) that could contain partial file
cryptographic hashes which will allow detection of which mirror
server returned incorrect data. Metalink clients SHOULD figure out
what ranges of the downloaded data can be recovered and what needs to
be fetched again.
That's better, but how about breaking it up a bit more, as in the following:
" If the cryptographic hash of the object does not match the Instance Digest
from the Metalink server, then the client SHOULD fetch the Metalink/XML (if
available). This may contain partial file cryptographic hashes which will
allow detection of which mirror server returned incorrect data. Metalink
clients SHOULD use the Metalink/XML data to figure out what ranges of the
downloaded data can be recovered and what needs to be fetched again. "
perfect, thanks!
--
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
)) Easier, More Reliable, Self Healing Downloads
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf