Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01)
Anthony Bryan <anthonybryan <at> gmail.com>
2008-09-02 23:36:29 GMT
Dave, thank you for these comments! You caught some issues that needed
to be addressed & that has improved this draft IMO. Changes are in
SVN.
On Tue, Sep 2, 2008 at 4:46 AM, Dave Cridland <dave <at> cridland.net> wrote:
> 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.
I understand & feel the same thing. The draft didn't seem like the
right place to put this, but I want the IETF to change the namespace
to whatever is appropriate. I don't know if this is something that
should be changed late or early in the process, that I change, or the
RFC editor changes?
The Atom namespace is "http://www.w3.org/2005/Atom". I don't know the
history behind it, but it doesn't seem my place to suggest something
like "http://www.w3.org/2008/Metalink" for Metalink. If that or
something similar is correct, perfect!
I do not want the namespace pointing to a domain name I own. More
responsibility than I need. :)
That was an error in the example, thanks for catching that!
> 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.
Wow, thank you so much! I didn't know about that. Should I list the
same hash types, or just have this:
The IANA registry named "Hash Function Textual Names" defines values
for hash types.
> 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? 
HAH! Glad you enjoyed that, an inside semi-joke :) Pretty ridiculous.
I've changed it to:
For convenience, this data format may be referred to as "Metalink",
which this specification uses internally.
> 4) Notational convention defines a different convention than is used in the
> examples.
The RELAX NG Compact schema doesn't match the rest of the spec? Or
something else? I'm still working on that, & if anyone wants to help
out please do because I don't have much experience.
> 5) Section 2, "Metalink Documents MUST be well-formed
> XML." - and presumably "namespace well-formed", as specified in
> [XML-NAMES]? Or not?
Yes.
Is this something I need to add to the draft, or are you mentioning it
because of internal inconsistencies in the examples?
> 6) Section 2: I'd personally kick out xml:base - I don't see it solving
> anything here.
To be honest, most of the XML boilerplate, "Securing Metalink
Documents", and "Extending Metalink" sections are stolen directly from
the Atom RFC.
xml:base hasn't been used in Metalink. Could it be useful? I found
this blog about it
http://feedblog.org/2005/12/05/xmlbase-was-a-bad-addition-to-atom/
> 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 '/'.
I think it's potentially useful to be able to create a sub-directory
structure. For instance, this is done with jigdo or torrents.
Clients have security holes, I agree, but they should be warned about
the possibilities so they can be fixed.
> 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".
Exactly, that was an error.
metalink:resources element MUST contain at least one metalink:url
element and SHOULD contain more than one metalink:url elements.
> 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.
This is the same as the Atom RFC. Has this been a problem in the real
world? (I don't know, just asking).
> 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.
Can you suggest wording that is more clear? I've changed it to:
The "metalink:signature" element is a Text construct that conveys a
digital signature for a file described in a Metalink Document.
I hope some security people will have criticism (& additions) for this
section. It describes how Metalink functions now, but we don't want to
be PGP specific. I am not familiar enough with other options to write
about it :)
> 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.
Do you suggest removing the "type" attribute & having a new separate
element as Julian suggested?
> 12) Section 4.2.17.1: Perhaps preference and weight? See SRV.
I'm not against that if others think that it is necessary/useful, but
I haven't added it.
> 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.
This is taken from the Atom RFC. If it needed to be there, does it
need to be in this draft as well?
> 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.
Same as above. I'm not an XML expert either, so I'll defer to others. :)
> Hope this helps, somewhat. Feel free to ignore the bits you disagree with.
It helps a lot! Very nice of you to take the time to offer a helpful critique!
--
--
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
)) Easier, More Reliable, Self Healing Downloads
RSS Feed