[apps-review] apps-team review of draft-bryan-metalinkhttp-19
Yves Lafon <ylafon@w3.org> Fri, 28 January 2011 15:36 UTC
Return-Path: <ylafon@w3.org>
X-Original-To: apps-review@core3.amsl.com
Delivered-To: apps-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0B93A67D1 for <apps-review@core3.amsl.com>; Fri, 28 Jan 2011 07:36:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.349
X-Spam-Level:
X-Spam-Status: No, score=-8.349 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdE3KX0KeIVU for <apps-review@core3.amsl.com>; Fri, 28 Jan 2011 07:36:57 -0800 (PST)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id AB5543A67D0 for <apps-review@ietf.org>; Fri, 28 Jan 2011 07:36:57 -0800 (PST)
Received: from ylafon by jay.w3.org with local (Exim 4.69) (envelope-from <ylafon@w3.org>) id 1PiqQZ-0000lj-L4; Fri, 28 Jan 2011 10:39:59 -0500
Date: Fri, 28 Jan 2011 10:39:59 -0500
From: Yves Lafon <ylafon@w3.org>
To: apps-review@ietf.org
Message-ID: <alpine.DEB.1.10.1101281025280.28883@wnl.j3.bet>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 28 Jan 2011 08:09:44 -0800
Cc: neil@nabber.org, anthonybryan@gmail.com, henrik@henriknordstrom.net, alan.ford@roke.co.uk, peter@poeml.de, tatsuhiro.t@gmail.com
Subject: [apps-review] apps-team review of draft-bryan-metalinkhttp-19
X-BeenThere: apps-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Apps Area Review List <apps-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-review>
List-Post: <mailto:apps-review@ietf.org>
List-Help: <mailto:apps-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2011 15:36:58 -0000
Dear authors, I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Document: draft-bryan-metalinkhttp-19 Title: Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP Header Fields Reviewer: Yves Lafon Review Date: 2011-01-28 IETF Last Call Date: 2011-02-18 Summary: This draft is almost ready for publication, but has a few small editorial fixes, and possibly needs some minor clarifications. Major Issues: None Minor Issues: In section 3, Remove [[Some organizations have many mirrors. Only send a few mirrors, or only use the Link header fields if Want-Digest is used?]] and add something along the lines of "As some organizations can have many mirrors, ..." in front of the next paragraph. Also "network proximity" might be a decision choice for the set of mirrors that might be returned. In section 3.2 Did you consider exposing the ASN of the mirror network prefix would be a good option on top of Geographical Location? It is not uncommon to have better bandwidth between two countries than between two ISPs in the same country. In section 6. << If Instance Digests are not provided by the Metalink servers, the Link header fields MUST be ignored. >> Clarification about what needs ot be ignored: "the Link header fields pertaining to this specification MUST be ignored" to avoid any zealous reading of the text. In section 7. It might be good that if any Ranged requests generated after the first request ends up with a complete response and not a partial one (as servers might not support HTTP ranges) then all but the fastest connection must be closed. The other option would be to add a requirement in 2. that Metalink servers and mirrors MUST support HTTP Ranges (which would be a better way of solving the issue). Also I noted a dependency on 'draft-ietf-ftpext2-hash' in the Normative References section. Nits: In section 3. last paragraph and 7.1.1 6th paragraph, "fieldss" -> "fields" In section 6. "Cryptographic Hashes of Whole Files", "Files" might be replaced by "Documents" Thanks ! -- Baroula que barouleras, au tiéu toujou t'entourneras. ~~Yves