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.
[...]
-- 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)?
[...]
--- 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"
[...]
-- 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.
-- 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".
[...]
-- 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. "
[...]
-- section 10.2 "In that case, this could deceive unaware downloaders that
they are downloading a malicious or worthless file."
Sentence does not make sense. Does the attacker with to deceive them into
downloading a malicious file, or convince them that they are when they are
not?
"In that case, this could deceive unaware downloaders into downloading
a malicious or worthless file."
WFM