[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01)
On Mon Sep 1 06:44:23 2008, Anthony Bryan wrote:
> Here is the Internet Draft for Metalink, available at
> http://tools.ietf.org/html/draft-bryan-metalink-01
> with interim revisions at
> http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/
> .
> We're looking for review and public comments.
1) I'm not mad keen on namespaces pointing to privately owned domain
names. You have a different one in the examples as is specified in
section 1.2, by the way.
2) The type attribute of the hash element ought to have values
selected from the IANA registry of textual hash names;
http://www.iana.org/assignments/hash-function-text-names/ - section
4.1.6.1 & 4.2.4.1.
3) Awesome:
"""
For convenience, this data format may be referred to as "Metalink
3.0". This specification uses "Metalink" internally.
"""
Yeah, so you use a longer, more formal name for *convenience*? And
then in the specification itself, use a short-hand for, what,
inconvenience? :-)
4) Notational convention defines a different convention than is used
in the examples.
5) Section 2, "Metalink Documents MUST be well-formed
XML." - and presumably "namespace well-formed", as specified in
[XML-NAMES]? Or not?
6) Section 2:From apps-review-bounces at ietf.org Thu Sep 4 01:31:05 2008
Return-Path: <apps-review-bounces at ietf.org>
X-Original-To: apps-review-archive at optimus.ietf.org
Delivered-To: ietfarch-apps-review-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 71D773A6D82;
Thu, 4 Sep 2008 01:31:05 -0700 (PDT)
X-Original-To: apps-review at core3.amsl.com
Delivered-To: apps-review at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id E3E5E3A6D84
for <apps-review at core3.amsl.com>; Thu, 4 Sep 2008 01:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.242
X-Spam-Level:
X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5
tests=[AWL=-1.719, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765,
HELO_MISMATCH_NET=0.611, J_CHICKENPOX_34=0.6, RDNS_DYNAMIC=0.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 NP-9NW9ghMaq for <apps-review at core3.amsl.com>;
Thu, 4 Sep 2008 01:31:04 -0700 (PDT)
Received: from turner.dave.cridland.net (dsl-217-155-137-60.zen.co.uk
[217.155.137.60])
by core3.amsl.com (Postfix) with ESMTP id 9C1443A6806
for <apps-review at ietf.org>; Thu, 4 Sep 2008 01:30:57 -0700 (PDT)
Received: from peirce.dave.cridland.net ([217.155.137.61]) by
turner.dave.cridland.net (submission)
via TCP with ESMTPA id <SLz9YgATpxjn at turner.dave.cridland.net>;
Tue, 2 Sep 2008 09:46:27 +0100
References: <bb9e09ee0808312244j4fc067c5qe12e4f914d5c8171 at mail.gmail.com>
In-Reply-To: <bb9e09ee0808312244j4fc067c5qe12e4f914d5c8171 at mail.gmail.com>
MIME-Version: 1.0
Message-Id: <9235.1220345185.781391 at peirce.dave.cridland.net>
Date: Tue, 02 Sep 2008 09:46:25 +0100
From: Dave Cridland <dave at cridland.net>
To: Anthony Bryan <anthonybryan at gmail.com>
Cc: general discussion of application-layer protocols <discuss at apps.ietf.org>,
xml-dev at lists.xml.org, ietf-http-wg at w3.org,
Applications Review List <apps-review at ietf.org>
Subject: Re: [APPS-REVIEW] Metalink XML Download Description Format
(draft-bryan-metalink-01)
X-BeenThere: apps-review at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Applications Review List <apps-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-review>,
<mailto:apps-review-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/apps-review>
List-Post: <mailto:apps-review at ietf.org>
List-Help: <mailto:apps-review-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-review>,
<mailto:apps-review-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: apps-review-bounces at ietf.org
Errors-To: apps-review-bounces at ietf.org
On Mon Sep 1 06:44:23 2008, Anthony Bryan wrote:
> Here is the Internet Draft for Metalink, available at
> http://tools.ietf.org/html/draft-bryan-metalink-01
> with interim revisions at
> http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/
> .
> We're looking for review and public comments.
1) I'm not mad keen on namespaces pointing to privately owned domain
names. You have a different one in the examples as is specified in
section 1.2, by the way.
2) The type attribute of the hash element ought to have values
selected from the IANA registry of textual hash names;
http://www.iana.org/assignments/hash-function-text-names/ - section
4.1.6.1 & 4.2.4.1.
3) Awesome:
"""
For convenience, this data format may be referred to as "Metalink
3.0". This specification uses "Metalink" internally.
"""
Yeah, so you use a longer, more formal name for *convenience*? And
then in the specification itself, use a short-hand for, what,
inconvenience? :-)
4) Notational convention defines a different convention than is used
in the examples.
5) Section 2, "Metalink Documents MUST be well-formed
XML." - and presumably "namespace well-formed", as specified in
[XML-NAMES]? Or not?
6) Section 2: I'd per I'd personally kick out xml:base - I don't see it
solving anything here.
7) Section 4.1.3.1: I'm deeply unconvinced about this "name"
attribute actually containing a path - I don't see this being needed
at all. A filename, sure. But otherwise, someone somewhere will
inadvertantly allow /etc/passwd to be overwritten, or something
equally hideous. Just ban '/'.
8) Section 4.1.4: "MUST contain one [good] and SHOULD contain more
than one" - you mean if my download is only available from one
location then this may provide a cause of poor interoperability? I
don't think this is what you mean. I think you mean: "MUST contain at
least one".
9) Section 4.2.3: I'm personally wary of doing this on two grounds.
Firstly, people invariably use them for advertising, rather than
debugging. Whilst not all marketing is, in fact, evil, I'm never
truly keen on adding a bunch of octets for no good reason. Secondly,
I'd live in perpetual fear that processors will change behaviour
dependent on the agent's foibles.
10) Section 4.2.13: I had to read this twice to figure out it
referred to a digital signature of the file to be downloaded. It
might be as well to define a term for that in section 2, and use it
throughout. I suspect the nice security people might have something
to say about specifying PGP-only detatched signatures.
11) Section 4.2.17: Does that "type" attribute totally suck? Of
course, you have to have it because every man, his dog, and his pet
hampster has decided that only HTTP is allowed, these days, for
absolutely everything, leading to a totally useless URI scheme which
essentially fails to describe the actual resource it's supposedly a
locator for. Okay, rant over, back to the review.
12) Section 4.2.17.1: Perhaps preference and weight? See SRV.
13) Section 4.2.17.2: Hang on, maybe this is a bit too far - I can
see the need for type, sure, but I don't see the need to be able to
specify "Use FTP to retrieve this HTTP URI", because that's just
introducing a silly state.
14) Section 5 - I'd personally just ditch the entire thing, you
effectively say all that's needed in Section 8.4.
15) I'm sure a lot of Section 6.1~6.3 could be summed up as "Ignore
any markup you don't understand, whether from the metalink namespace
or not." Of course, I'm not really an XML expert, so if this language
is really needed, that's all fine and good.
Hope this helps, somewhat. Feel free to ignore the bits you disagree
with.
Dave.
--
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
APPS-REVIEW mailing list
APPS-REVIEW at ietf.org
https://www.ietf.org/mailman/listinfo/apps-review
sonally kick out xml:base - I don't see it
solving anything here.
7) Section 4.1.3.1: I'm deeply unconvinced about this "name"
attribute actually containing a path - I don't see this being needed
at all. A filename, sure. But otherwise, someone somewhere will
inadvertantly allow /etc/passwd to be overwritten, or something
equally hideous. Just ban '/'.
8) Section 4.1.4: "MUST contain one [good] and SHOULD contain more
than one" - you mean if my download is only available from one
location then this may provide a cause of poor interoperability? I
don't think this is what you mean. I think you mean: "MUST contain at
least one".
9) Section 4.2.3: I'm personally wary of doing this on two grounds.
Firstly, people invariably use them for advertising, rather than
debugging. Whilst not all marketing is, in fact, evil, I'm never
truly keen on adding a bunch of octets for no good reason. Secondly,
I'd live in perpetual fear that processors will change behaviour
dependent on the agent's foibles.
10) Section 4.2.13: I had to read this twice to figure out it
referred to a digital signature of the file to be downloaded. It
might be as well to define a term for that in section 2, and use it
throughout. I suspect the nice security people might have something
to say about specifying PGP-only detatched signatures.
11) Section 4.2.17: Does that "type" attribute totally suck? Of
course, you have to have it because every man, his dog, and his pet
hampster has decided that only HTTP is allowed, these days, for
absolutely everything, leading to a totally useless URI scheme which
essentially fails to describe the actual resource it's supposedly a
locator for. Okay, rant over, back to the review.
12) Section 4.2.17.1: Perhaps preference and weight? See SRV.
13) Section 4.2.17.2: Hang on, maybe this is a bit too far - I can
see the need for type, sure, but I don't see the need to be able to
specify "Use FTP to retrieve this HTTP URI", because that's just
introducing a silly state.
14) Section 5 - I'd personally just ditch the entire thing, you
effectively say all that's needed in Section 8.4.
15) I'm sure a lot of Section 6.1~6.3 could be summed up as "Ignore
any markup you don't understand, whether from the metalink namespace
or not." Of course, I'm not really an XML expert, so if this language
is really needed, that's all fine and good.
Hope this helps, somewhat. Feel free to ignore the bits you disagree
with.
Dave.
--
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
APPS-REVIEW mailing list
APPS-REVIEW at ietf.org
https://www.ietf.org/mailman/listinfo/apps-review