Update: I looked at the diffs for version 20, and I think the discussion below accurately reflect the changes--so please consider this a followup review of version 20. Thanks! Ben. On Feb 16, 2011, at 5:15 PM, Ben Campbell 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@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