ID: minor nits

[Anthony Bryan]

(a) <metadata> name
no one has a better name for URIs to torrents/metalinks? :)

(b) <verification> info does not apply to <metadata> files (torrents,
metalinks) but to the files the metadata points to.

(c) need to add a file attribute to <metadata> so you can specify one
file from a multi-file torrent or metalink. (see Matt's discussion,
did we resolve this?)

(d) <type> name

I think <type> could be interesting/useful. but I think we need a more
descriptive name, like <dynamic> or...any ideas?

4.2.16. The "metalink:type" Element

The "metalink:type" element is a Text construct that describes
whether the IRI from "metalink:origin" in a Metalink will contain
dynamic updated Metalinks or static content that is not updated.

metalinkType =
element metalink:type {
"static" | "dynamic"
}

(e) where a metalink is static or dynamic, it will be nice to have
<origin> to know where it came from, if you're finding the metalink
from some other site. so I need to change or removed the following
text:

o If metalink:type is "dynamic", metalink:metalink elements MAY
contain exactly one metalink:origin element.

(f) generator has a name, URI, and version.

this whole section is borrowed from atom, I wonder how much it's used
in atom & if it helps? we currently can include a generator name. is a
URI and version really necessary for figuring out if a generator is
spurting out bad metalinks? isn't <origin> a better way to track down
an offender?

4.2.3. The "metalink:generator" Element

The "metalink:generator" element's content identifies the agent used
to generate a Metalink Document, for debugging and other purposes.

metalinkGenerator = element metalink:generator {
metalinkCommonAttributes,
attribute uri { metalinkUri }?,
attribute version { text }?,
text
}

The content of this element, when present, MUST be a string that is a
human-readable name for the generating agent. Entities such as
"&amp;" and "&lt;" represent their corresponding characters ("&" and
"<" respectively), not markup.

The metalink:generator element MAY have a "uri" attribute whose value
MUST be an IRI reference [RFC3987]. When dereferenced, the resulting
URI (mapped from an IRI, if necessary) SHOULD produce a
representation that is relevant to that agent.

The metalink:generator element MAY have a "version" attribute that
indicates the version of the generating agent.

--
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
)) Easier, More Reliable, Self Healing Downloads

[Peter Poeml]

On Fri, Jul 03, 2009 at 04:27:53PM -0400, Ant Bryan wrote:
>
> (a) <metadata> name
> no one has a better name for URIs to torrents/metalinks? :)

Things I thought of were
"metaurl"
"alternative location"
"other description"
"p2p"

> (b) <verification> info does not apply to <metadata> files (torrents,
> metalinks) but to the files the metadata points to.

It *might* actually be used to verify content downloaded from the
referenced location. And thinking about it, it should have precedence
over verification metadata from the torrent, IMO.

> (c) need to add a file attribute to <metadata> so you can specify one
> file from a multi-file torrent or metalink. (see Matt's discussion,
> did we resolve this?)

I for one don't see particular value in multi-file torrents, but I see
the issue - I haven't a solution at hand though...

> (d) <type> name
>
> I think <type> could be interesting/useful. but I think we need a more
> descriptive name, like <dynamic> or...any ideas?
>
> 4.2.16. The "metalink:type" Element
>
> The "metalink:type" element is a Text construct that describes
> whether the IRI from "metalink:origin" in a Metalink will contain
> dynamic updated Metalinks or static content that is not updated.
>
> metalinkType =
> element metalink:type {
> "static" | "dynamic"
> }

Thinking about this, the practical relevance of the field at all might
be marginal. A validity of a metalink could as well be specified by
using existing HTTP semantics (Expires, Last-Modified, ETag,
Cache-control headers, and such) which would also allow finder control.

> (e) where a metalink is static or dynamic, it will be nice to have
> <origin> to know where it came from, if you're finding the metalink
> from some other site. so I need to change or removed the following
> text:
>
> o If metalink:type is "dynamic", metalink:metalink elements MAY
> contain exactly one metalink:origin element.

Would it be practical to just always specify the origin?

> (f) generator has a name, URI, and version.
>
> this whole section is borrowed from atom, I wonder how much it's used
> in atom & if it helps? we currently can include a generator name. is a
> URI and version really necessary for figuring out if a generator is
> spurting out bad metalinks? isn't <origin> a better way to track down
> an offender?

I think that origin and generator are orthogonal - the origin is
valuable to know in itself (and probably more so), but the used
generator is also useful. Mainly for informational and debugging
purposes. An URI wouldn't be necessary, I think that recommending
something like HTTP User-agent (should give name of generator and
version) would be sufficient, in a single field.

(I always liked the HTTP spec for the User-agent - it recommends to put
more significant things in the front of the string, and the less
significant things at the end, which makes kind of sense)
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43

Peter
--
"WARNING: This bug is visible to non-employees. Please be respectful!"

SUSE LINUX Products GmbH
Research & Development

[Anthony Bryan]

On Fri, Jul 3, 2009 at 4:52 PM, Peter Poeml<po...@suse.de> wrote:
> On Fri, Jul 03, 2009 at 04:27:53PM -0400, Ant Bryan wrote:
>>
>> (a) <metadata> name
>> no one has a better name for URIs to torrents/metalinks? :)
>
> Things I thought of were
> "metaurl"
> "alternative location"
> "other description"
> "p2p"

I like "metaurl". anyone else have a preference?

>> (b) <verification> info does not apply to <metadata> files (torrents,
>> metalinks) but to the files the metadata points to.
>
> It *might* actually be used to verify content downloaded from the
> referenced location. And thinking about it, it should have precedence
> over verification metadata from the torrent, IMO.

that's what I think too. if you're downloading from a torrent, it's
own verification info is authoritative. if you've got a metalink with
verification info that also lists a torrent, I think the metalink's
verification info has to be authoritative and the torrent has to be
discarded if they don't match.

>> (c) need to add a file attribute to <metadata> so you can specify one
>> file from a multi-file torrent or metalink. (see Matt's discussion,
>> did we resolve this?)
>
> I for one don't see particular value in multi-file torrents, but I see
> the issue - I haven't a solution at hand though...

multi-file torrents are in use. if metalink clients want to be able to
take advantage of them, we need to figure something out :)

>> (d) <type> name
>>
>> I think <type> could be interesting/useful. but I think we need a more
>> descriptive name, like <dynamic> or...any ideas?
>>
>>  4.2.16. The "metalink:type" Element
>>
>>    The "metalink:type" element is a Text construct that describes
>>    whether the IRI from "metalink:origin" in a Metalink will contain
>>    dynamic updated Metalinks or static content that is not updated.
>>
>>    metalinkType =
>>       element metalink:type {
>>       "static" | "dynamic"
>>       }
>
> Thinking about this, the practical relevance of the field at all might
> be marginal. A validity of a metalink could as well be specified by
> using existing HTTP semantics (Expires, Last-Modified, ETag,
> Cache-control headers, and such) which would also allow finder control.

I'm thinking about cases when you're getting the metalink from a
secondary source (not the origin) or not over HTTP, like being emailed
a metalink from a friend, from a FTP site, from a metalink search
engine/indexing site, or finding it on your hard drive. :)

say you find a metalink for an openSUSE ISO 3 years after it came out,
and you still want this old version for historical reasons or to use
on an old computer. you want that exact file, but maybe most mirrors
don't carry it anymore, or maybe the URLs used a naming like "latest"
instead of something unique that wouldn't change, or maybe the mirror
directories have all been renamed, etc. a metalink client could
request an updated metalink from the <origin>. I guess this is pretty
marginal but...

>> (e) where a metalink is static or dynamic, it will be nice to have
>> <origin> to know where it came from, if you're finding the metalink
>> from some other site. so I need to change or removed the following
>> text:
>>
>>    o  If metalink:type is "dynamic", metalink:metalink elements MAY
>>       contain exactly one metalink:origin element.
>
> Would it be practical to just always specify the origin?

(typo, I meant "whether a metalink is static or dynamic...")

I think so.

If Metalink Documents are published, they SHOULD include an origin element.

?

>> (f) generator has a name, URI, and version.
>>
>> this whole section is borrowed from atom, I wonder how much it's used
>> in atom & if it helps? we currently can include a generator name. is a
>> URI and version really necessary for figuring out if a generator is
>> spurting out bad metalinks? isn't <origin> a better way to track down
>> an offender?
>
> I think that origin and generator are orthogonal - the origin is
> valuable to know in itself (and probably more so), but the used
> generator is also useful. Mainly for informational and debugging
> purposes. An URI wouldn't be necessary, I think that recommending
> something like HTTP User-agent (should give name of generator and
> version) would be sufficient, in a single field.
>
> (I always liked the HTTP spec for the User-agent - it recommends to put
> more significant things in the front of the string, and the less
> significant things at the end, which makes kind of sense)
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43

that's what I'm thinking, something like:

<generator>MirrorBrain/2.8.1</generator>
?

[Hampus Wessman]

Anthony Bryan skrev:

On Fri, Jul 3, 2009 at 4:52 PM, Peter Poeml<po...@suse.de> wrote:
  

On Fri, Jul 03, 2009 at 04:27:53PM -0400, Ant Bryan wrote:
    

(a) <metadata> name
no one has a better name for URIs to torrents/metalinks? :)
      

Things I thought of were
"metaurl"
"alternative location"
"other description"
"p2p"
    

I like "metaurl". anyone else have a preference?
  

I like that too.

(b) <verification> info does not apply to <metadata> files (torrents,
metalinks) but to the files the metadata points to.
      

It *might* actually be used to verify content downloaded from the
referenced location. And thinking about it, it should have precedence
over verification metadata from the torrent, IMO.
    

that's what I think too. if you're downloading from a torrent, it's
own verification info is authoritative. if you've got a metalink with
verification info that also lists a torrent, I think the metalink's
verification info has to be authoritative and the torrent has to be
discarded if they don't match.

  

I agree. It's the metalink you trust and it's what is described in there (including hashes) that you want...

(c) need to add a file attribute to <metadata> so you can specify one
file from a multi-file torrent or metalink. (see Matt's discussion,
did we resolve this?)
      

I for one don't see particular value in multi-file torrents, but I see
the issue - I haven't a solution at hand though...
    

multi-file torrents are in use. if metalink clients want to be able to
take advantage of them, we need to figure something out :)
  

We do =)

I'm not sure this is very useful. The creator may find more mirrors that could be added if you redownloaded the metalink, but I don't like the idea of auto-updating the metalink in the background. IMHO all metalinks should be static. Then you can inspect it (and its hashes) before starting the download and be sure that is what you get. I realize that it's possible to manually change it to static if you want, but at least I don't think the feature is important. It would be better to simplify the standard and remove this unused feature. One less thing for client developers to care about.

In situations like this I would prefer to instead have a URL to a web page where you can find out more about the metalink and download the latest version of the metalink (possibly for newer versions of the actual file(s) too). This way the user could visit the site about the metalink to check out what it is and download a newer version (if he/she wants to). Most of the time there will be no need to download newer versions, but this could be useful anyway.

Perhaps there's already a field like this? (I might forget about something). In either case I think a field like this could be very useful! The idea would be, of course, that a client shows this url when you open a metalink and lets the user click on it to open a web browser...

That looks good! I think doing it similarly to HTTP user-agent is both good and sufficient. We might be able to borrow a little from that spec then too =)

[Anthony Bryan]

On Sat, Jul 4, 2009 at 5:10 AM, Hampus Wessman<hampus....@gmail.com> wrote:
> Anthony Bryan skrev:

I do think it has potential, but maybe it'll never be realized. after
3+ years of no use, maybe it's time to trim this fat/cruft. anyone
else want to weigh in?

[Anthony Bryan]

ID -08 is out, which addresses some of these issues.

http://tools.ietf.org/html/draft-bryan-metalink-08

please provide feedback, improvements, & corrections. :)

On Fri, Jul 3, 2009 at 4:27 PM, Anthony Bryan<anthon...@gmail.com> wrote:
>
> (b) <verification> info does not apply to <metadata> files (torrents,
> metalinks) but to the files the metadata points to.

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. Note that the
information in the metalink:verification element does not apply to
these files.

> (e) where a metalink is static or dynamic, it will be nice to have
> <origin> to know where it came from, if you're finding the metalink
> from some other site. so I need to change or removed the following
> text:
>
>   o  If metalink:type is "dynamic", metalink:metalink elements MAY
>      contain exactly one metalink:origin element.

o metalink:metalink elements SHOULD contain exactly one metalink:
origin element.

The "metalink:generator" element's content identifies the generating
agent name and version, separated by a "/", used to generate a

Metalink Document, for debugging and other purposes.

metalinkGenerator = element metalink:generator {
metalinkCommonAttributes,

text
}

The content of this element, when present, MUST be a string that is a

human-readable name and version, separated by a "/", for the
generating agent. For example, "MirrorBrain/2.8.1", where
"MirrorBrain" is the name and "2.8.1" is the version. Entities such

as "&amp;" and "&lt;" represent their corresponding characters ("&"
and "<" respectively), not markup.

--

[Nicolas Alvarez]

Anthony Bryan wrote:

> On Fri, Jul 3, 2009 at 4:52 PM, Peter Poeml wrote:
>> (I always liked the HTTP spec for the User-agent - it recommends to put
>> more significant things in the front of the string, and the less
>> significant things at the end, which makes kind of sense)
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43
>
> that's what I'm thinking, something like:
>
> <generator>MirrorBrain/2.8.1</generator>
> ?

I agree, let's reuse this syntax.

It could also be "Program/version library/version", could also have comments
between parentheses, etc. It's important to note that a product name
*cannot have spaces in it*, or it would be interpreted as multiple
products!

"Mirror Brain/2.8.1" is the "Mirror" product of unspecified version, and
the "Brain" product version 2.8.1.

I have seen lots of software not following this. For example, Google Code
SVN web hooks use "Google Code Project Hosting" as User-Agent, which is
four product names...

[Nicolas Alvarez]

Anthony Bryan wrote:
> o metalink:metalink elements SHOULD contain exactly one metalink:
> origin element.

SHOULD contain one always? Not only if dynamic?

What "origin" element would be used if I create a metalink using a graphical
tool, and then send it by email to a friend? (the .metalink itself never
had a URI in the whole process)

> Entities such
> as "&amp;" and "&lt;" represent their corresponding characters ("&"
> and "<" respectively), not markup.

Do we need to say that? Anyone not following this is violating the *XML*
spec.

It's used in Atom and/or RSS specs (don't remember which) because of the
sheer amount of noobs who think they can parse RSS with their own
hand-written parsers instead of using a real XML library...

[Anthony Bryan]

On Mon, Jul 6, 2009 at 5:19 PM, Nicolas
Alvarez<nicolas...@gmail.com> wrote:
>
> Anthony Bryan wrote:
>>    o  metalink:metalink elements SHOULD contain exactly one metalink:
>>       origin element.
>
> SHOULD contain one always? Not only if dynamic?

yes, I think it could be useful info to have, even if not dynamic.

speaking of, what do you think of dynamic? do you think it should be
kept/removed/renamed?

> What "origin" element would be used if I create a metalink using a graphical
> tool, and then send it by email to a friend? (the .metalink itself never
> had a URI in the whole process)

yes, that's what I'm going for. we want it in there if it's published
publicly on the net. but I didn't have a good way to word it.

>> Entities such
>>    as "&amp;" and "&lt;" represent their corresponding characters ("&"
>>    and "<" respectively), not markup.
>
> Do we need to say that? Anyone not following this is violating the *XML*
> spec.
>
> It's used in Atom and/or RSS specs (don't remember which) because of the
> sheer amount of noobs who think they can parse RSS with their own
> hand-written parsers instead of using a real XML library...

it's from Atom at least. I'm feeling conservative, I don't see this
hurting if it's left in there?

[Hampus Wessman]

Nicolas Alvarez skrev:

Anthony Bryan wrote:
  

   o  metalink:metalink elements SHOULD contain exactly one metalink:
      origin element.
    

SHOULD contain one always? Not only if dynamic?

What "origin" element would be used if I create a metalink using a graphical
tool, and then send it by email to a friend? (the .metalink itself never
had a URI in the whole process)

  

Good point. In some cases it doesn't make sense or at least it is hard/impossible to come up with a valid one.

Entities such
   as "&" and "<" represent their corresponding characters ("&"
   and "<" respectively), not markup.
    

Do we need to say that? Anyone not following this is violating the *XML*
spec.

It's used in Atom and/or RSS specs (don't remember which) because of the
sheer amount of noobs who think they can parse RSS with their own
hand-written parsers instead of using a real XML library...
  

I agree here too. Not that it actually hurts, but it isn't necessary...

Here's the corresponding section in the xml spec, by the way: http://www.w3.org/TR/xml/#syntax (section 2.4)

There may be a lot of noobs trying to parse metalinks too, though =)

[Ant Bryan]

On Jul 4, 5:10 am, Hampus Wessman <hampus.wess...@gmail.com> wrote:
> Anthony Bryan skrev:
>
> > On Fri, Jul 3, 2009 at 4:52 PM, Peter Poeml<po...@suse.de> wrote:
>
> >> On Fri, Jul 03, 2009 at 04:27:53PM -0400, Ant Bryan wrote:
>
> >>> (a) <metadata> name
> >>> no one has a better name for URIs to torrents/metalinks? :)
>
> >> Things I thought of were
> >> "metaurl"
> >> "alternative location"
> >> "other description"
> >> "p2p"
>
> > I like "metaurl". anyone else have a preference?
>
> I like that too.

I've changed it to "metaurl" which I think fits nicely with "url" -
please check to make sure there are no more references to a "metadata"
element. :) I keep seeing spots I missed!

in a similar way, "metaurl" element now has a "name" attribute
(mirroring the "file" element) for singling out a single file in a
multi-file torrent/metalink/whatever.

4.2.9.3. The "name" Attribute

metalink:metaurl elements MAY have a "name" attribute that
indicates
a specific file in a BitTorrent .torrent file or a Metalink
Document
that describes multiple files.

Directory information can also be contained in a "path/file" format
only, as in:

<metaurl name="debian-amd64/sarge/Contents-amd64.gz">

In this example, a file named "Contents-amd64.gz" is indicated, in
a
"debian-amd64/sarge/" subdirectory. The path MUST NOT contain any
directory traversal directives or information. The path MUST be
relative. The path MUST NOT begin with a "/", "./" or "../",
contain
"/../", or end with "/..".


in both name attributes, the file and directory names are in quote
now: "Contents-amd64.gz" and "debian-amd64/sarge/"

In this example, a file named "Contents-amd64.gz" is indicated, in
a
"debian-amd64/sarge/" subdirectory.

also, updated REC-xmldsig-core reference to second edition.