Anthony Bryan wrote:
> 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."
Hmmmm, I thought I fixed this in the latest revision. Basically I'd
just change that last sentence to read: It MAY include additional IANA
hash algorithms.
>
>>>> 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.
>
Agreed, that is what I was thinking too.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
