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: Anthony Bryan <anthonybryan@gmail.com>
Date: Wed, 3 Sep 2008 12:01:31 -0400
Message-ID: <bb9e09ee0809030901r391b364cofef6da55c6071e16@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:54 GMT