- From: Anthony Bryan <anthonybryan@gmail.com>
- Date: Wed, 3 Sep 2008 12:01:31 -0400
- To: "Julian Reschke" <julian.reschke@gmx.de>
- 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, "Ian Macfarlane" <ian@ianmacfarlane.com>
On Wed, Sep 3, 2008 at 9:22 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > Anthony Bryan wrote: >>> >>> 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? >> >> Yes, it is. >> >> Do you think about a "metadata" element (a sub-element of >> "resources")with a required "type" attribute of MIME type is >> appropriately generic? > > Sounds good. > >> This could then be used to describe Metalinks if needed, and other >> types that may come later. > > Right. > >> I don't think BitTorrent's MIME type is in the is listed in the IANA >> MIME Media Types. Would this be a problem? >> >> <?xml version="1.0" encoding="UTF-8"?> >> <metalink xmlns="http://www.metalinker.org"> >> <files> >> <file name="example.ext"> >> <resources> >> <url>ftp://ftp.example.com/example.ext</url> >> <url>http://example.com/example.ext</url> >> <metadata >> type="application/x-bittorrent">http://example.com/example.ext.torrent >> </metadata> >> </resources> >> </file> >> </files> >> </metalink> > > One of these issues that regularly come up :-) > > One way out of that would by to "grab" special type names like "torrent", > and hardwire them. That should be ok as long as they can't collide with > registered names (thus no "/" allowed). Great, thanks Julian! Thanks to the other people that mentioned this as well, it seems much cleaner & tightened up now. :) Do I need to explicitly state no "/" allowed, or just know any that ones I'm defining can't be "/" ? And would it be better to just allow the unofficial MIME type, instead of essentially creating an unofficial registry with one or a handful of entries? Or is MIME types plus hardwired entries better? Here is the changed text: 4.2.9. The "metalink:metadata" Element The "metalink:metadata" element contains the IRI of metadata about a resource to download. For example, this could be the IRI of a BitTorrent .torrent file or a Metalink Document. metalinkMetadata = element metalink:metadata { metalinkCommonAttributes, attribute preference { xsd:integer }?, attribute type { metalinkTextConstruct }, metalinkUri }+ 4.2.9.1. The "preference" Attribute metalink:metadata elements MAY have a preference attribute, whose value MUST be a number from 1 to 100 for priority, with 100 used first and 1 used last. See the "preference" attribute of the metalink:url element for more information. 4.2.9.2. The "type" Attribute metalink:metadata elements MUST have a "type" attribute that indicates the MIME type of the metadata available at the IRI. In the case of BitTorrent as specified in [BITTORRENT], the value "torrent" is required. Metalink Processors that do not support a specified type of metadata about a resource to download MUST ignore that metadata 4.2.18. The "metalink:url" Element The "metalink:url" element contains the IRI of a file. All IRIs MUST lead to identical files. -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads
Received on Wednesday, 3 September 2008 16:02:07 UTC