On Wed, Sep 30, 2009 at 9:41 PM, Neil M. <[email protected]> wrote: > > > > Anthony Bryan wrote: >> On Mon, Sep 28, 2009 at 3:05 AM, Neil M. <[email protected]> wrote: >>> Comments on draft 16 if its not too late in the process. None of these >>> are a big deal, but here it goes. >>> >>> 4.2.9. The "metalink:logo" Element >>> >>> Add an option to base64 encode the logo file. This allows for embedding >>> the logo in the metalink file itself. Reference RFC 2397. This is >>> already well established as it is part of HTML 4.01. >> >> that could be cool. I think it may be simpler to leave it as it is tho. >> >> I wonder how many download managers natively support base64? they can >> all definitely grab an image file, which seems simpler. >> > > Base64 is relatively common as this is used in HTTP elsewhere, such as > for authentication. The above suggestion is handy for when the URL > might not be available anymore. Ironically this problem might also be > solved by using the "file" tag with URLs for completeness. Actually it > appears that this doesn't require a change to our spec, since RFC 2397 > defines it as an URL which is a valid IRI? So the spec as is allows for > this.
cool :) >>> 4.2.12. The "metalink:os" Element >>> >>> Is there a use case for this? I'd say if no one plans to use this just >>> take it out. This is where the extensibleness of XML can be used if >>> something better comes along later. Is the current list of >>> OSes/versions sufficient? The IANA list seems lacking, especially when >>> it comes to specific versions. A good example is if I want to download >>> a Linux package that has multiple formats in the metalink file, there is >>> no way for your metalink client to differentiate between a .deb for >>> Ubuntu/Debian and a .rpm for Fedora/RHEL/CentOS. >>> >>> http://www.iana.org/assignments/operating-system-names >> >> the list is very lacking. that can be updated separately. I have a >> feeling people will just freestyle if they use it. > > Yeah do we need to make a note that other values besides the IANA list > MAY be used, like with the hashes? hmm, my intent for that was that "It MAY also include other hashes from the registry." not "make up values and use whatever you want" I guess that needs to be clarified? "If a Metalink Document contains hashes, it SHOULD include "sha-1" which is SHA-1, as specified in [RFC3174] (Eastlake, D. and P. Jones, “US Secure Hash Algorithm 1 (SHA1),” September 2001.), or stronger. It MAY also include other hashes." >> >>> At the very least a <file> should be able to include multiple OS values >>> instead of the current single value. An example for this is a single >>> Windows .exe that will run on multiple Windows versions. >> >> sounds good. can you make the changes? > > OK thanks! >> >>> How do ed2k/magnet links fit in? Are they a metaurl or url? If they >>> are a metaurl what are the mime types? And I'm assuming that for the >>> metalinkhttp implementation these will directly map, >>> metaurl=>describedby, url=>duplicate. >> >> good question! I doubt they have mime types. I kinda don't want to >> touch this, since people already complained about bittorrent not >> having a proper mime type, but also about reserving "torrent" in the >> spec. >> >> maybe we can word it so that they require a mime type, unless the URI >> scheme name makes it clear? >> > > Yes, sounds good. You are right this is difficult to get right. on second thought, ed2k/magnet would be <url>. they're URI schemes that point to the actual files (not metainfo files with file types). <metaurl> is to a "metainfo" file like a torrent or metalink. -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Metalink Discussion" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/metalink-discussion?hl=en -~----------~----~----~----~------~----~------~--~---
