Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-

["Anthony Bryan" <anthonybryan@gmail.com>]

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@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