W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 03 Sep 2008 11:17:57 +0200
Message-ID: <48BE5645.70302@gmx.de>
To: Anthony Bryan <anthonybryan@gmail.com>
CC: Dave Cridland <dave@cridland.net>, general discussion of application-layer protocols <discuss@apps.ietf.org>, Applications Review List <apps-review@ietf.org>, xml-dev@lists.xml.org, ietf-http-wg@w3.org

Anthony Bryan wrote:
> On Tue, Sep 2, 2008 at 5:35 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
>> Dave Cridland wrote:
>>> ...
>>> 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.
>>> ...
>> "4.2.17. The "metalink:url" Element
>>   The "metalink:url" element contains the IRI of a file.  All IRIs
>>   should lead to identical files, except in the case of type
>>   "bittorrent" where the IRI should lead to a .torrent file."
>> Actually, don't do that. Don't make the meaning of an element totally
>> dependent on an attribute on it. If torrent files are a special case (can
>> there be more...?), then define a separate element.
> I'm sure there COULD be more, but I don't know of any other right now.
> Do you suggest a torrent specific element, or something generic?

If it could be phrased as something more generic, and then state the 
current use case for torrent files, that probably would be best.

So, in general, this would be for IRIs that do not identify a resource 
to download, but metadata about a resource to download? Strictly 
speaking, isn't metalink not yet another format for that?

BR, Julian
Received on Wednesday, 3 September 2008 09:18:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:37 UTC