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@xxxxxxxxxxx> 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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf