[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01)
- From: "Anthony Bryan" <anthonybryan@gmail.com>
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Date: Wed, 3 Sep 2008 12:01:31 -0400
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]