Re: [apps-discuss] apps-team review of draft-bryan-metalinkhttp-19 (fwd)
Anthony Bryan <anthonybryan@gmail.com> Sat, 29 January 2011 23:43 UTC
Return-Path: <anthonybryan@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A41FA3A68EA; Sat, 29 Jan 2011 15:43:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.335
X-Spam-Level:
X-Spam-Status: No, score=-3.335 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_LOW=-1]
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 1Jp3SOAlSZW8; Sat, 29 Jan 2011 15:43:38 -0800 (PST)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 3B2F03A68DC; Sat, 29 Jan 2011 15:43:36 -0800 (PST)
Received: by ewy8 with SMTP id 8so2205109ewy.31 for <multiple recipients>; Sat, 29 Jan 2011 15:46:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OfhZqqIL9KBM0Sv5CLQ7lGKwD58pdVaKaghVxgett6M=; b=aQBlGatGtfcX0lKYgyVJ4jHYutUBoptKEFH6oZcAHlmzIdNdusPKiL1YfCclcIh8Nm 9skZ9sK62/5GAN4ts+3MdCQU0HDHd05eZiBRARJrmknLijIdh7uFLvLGW8oZyxG+VvnF bl5plyJP1Eqx7AjkeSR09kK5wI/E2AMqYMqms=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OlNzvWYos2+l0afg2RT3f2MQqSns5t03WCUwFGozwkrHC2ZvTg7EZP8T/qwx7oKwiR j1//PnVHlFl9bzTU+JIQ3TfSc5L8PHsQL+pHrGU1cbDuDKUTtki29QRuuoGk3YsxDJEU loWQWKR7l1qCW4gYdi3UytD2l7r9bgWjKReT4=
MIME-Version: 1.0
Received: by 10.213.29.77 with SMTP id p13mr6769708ebc.2.1296344806412; Sat, 29 Jan 2011 15:46:46 -0800 (PST)
Received: by 10.213.98.69 with HTTP; Sat, 29 Jan 2011 15:46:46 -0800 (PST)
In-Reply-To: <alpine.DEB.1.10.1101281158200.25983@wnl.j3.bet>
References: <alpine.DEB.1.10.1101281158200.25983@wnl.j3.bet>
Date: Sat, 29 Jan 2011 18:46:46 -0500
Message-ID: <AANLkTikmGG_O3Z7B0XvKCYiDdioJOc=LDD0+uMPGP3Gf@mail.gmail.com>
From: Anthony Bryan <anthonybryan@gmail.com>
To: Yves Lafon <ylafon@w3.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sun, 30 Jan 2011 08:12:03 -0800
Cc: apps-discuss@ietf.org, apps-review@ietf.org, neil@nabber.org, henrik@henriknordstrom.net, "Ford, Alan" <alan.ford@roke.co.uk>, iesg@ietf.org
Subject: Re: [apps-discuss] apps-team review of draft-bryan-metalinkhttp-19 (fwd)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Jan 2011 23:43:39 -0000
thank you for the review. On Fri, Jan 28, 2011 at 11:59 AM, Yves Lafon <ylafon@w3.org> wrote: > (Forwarding to apps-discuss & IESG per request) > > -- > Baroula que barouleras, au tiéu toujou t'entourneras. > > ~~Yves > > ---------- Forwarded message ---------- > Date: Fri, 28 Jan 2011 10:39:59 -0500 (EST) > From: Yves Lafon <ylafon@w3.org> > To: apps-review@ietf.org > Cc: Alexey Melnikov <alexey.melnikov@isode.com>, anthonybryan@gmail.com, > neil@nabber.org, henrik@henriknordstrom.net, tatsuhiro.t@gmail.com, > peter@poeml.de, alan.ford@roke.co.uk > Subject: apps-team review of draft-bryan-metalinkhttp-19 > > 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. removed. > Also "network proximity" might be a decision choice for the set of mirrors > that might be returned. added. > 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. no, this can be done internally on the server side though for mirror priority (currently via MirrorBrain w/ mod_asn). Should we mention this in the Mirror Priority section and add a reference to RFC 1930? http://www.mirrorbrain.org/ http://www.mirrorbrain.org/mod_asn/ > 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. fixed. > 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). I added "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 can be closed. " an earlier draft mentioned that mirrors MUST support HTTP Ranges, but feedback was that this might exclude mirrors. currently it says "Mirror servers SHOULD support serving partial content." we have walked a fine line with not requiring too much on a mirror network so it's less restrictive and more mirrors can join in the mirror pool versus having all the features we want. > Also I noted a dependency on 'draft-ietf-ftpext2-hash' in the Normative > References section. yes, we will remove this unless we want draft-ietf-ftpext2-hash to hold up this document. most likely we will remove it. > 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" changed to "Documents". or would "Resources" be better? thanks! -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads
- [apps-discuss] apps-team review of draft-bryan-me… Yves Lafon
- Re: [apps-discuss] apps-team review of draft-brya… Anthony Bryan