- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 03 Sep 2008 11:17:57 +0200
- 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