apps-review for metalink ID.
---------- Forwarded message ---------- From: Anthony Bryan <[email protected]> Date: Fri, Oct 30, 2009 at 11:56 AM Subject: Re: Review of metalink I-D To: Mark Baker <[email protected]> Cc: [email protected], Tatsuhiro Tsujikawa <[email protected]>, "Neil M." <[email protected]>, Peter Pöml <[email protected]> Mark, thanks so much for your time and comments! On Thu, Oct 29, 2009 at 8:46 PM, Mark Baker <[email protected]> wrote: > This is my review of draft-bryan-metalink-21. > > - sec 3, last paragraph, it is mentioned that some kinds of white > space can produce an "invalid" document, yet no where is it defined > what that means This text was borrowed from RFC 4287 yet I don't see more text to borrow to define invalid. :) How about adding this to sec 2, "Metalink Documents". "Metalink Documents that do not follow this specification are invalid, and partially or wholly unusable to Metalink Processors." > - sec 4.1.2.1. not sure why "name" is a MUST. I'm sure metalink > agents can pick a reasonable one, or ask the user, but if it was > required then they might not include this logic. This ends up being the being the filename that the downloaded file is written to most of the time. Agents are free to pick one, or ask the user. (Some use "filename(2).ext" if "filename.ext" is already taken, etc). The agent could use the filename at the end of a URI, but the filename from each URI can be different, the contents just have to match. We are also trying to define the document format in this draft, with as little client behavior as possible. So this seems like the simplest thing to require. > - sec 4.2.3. If metalink:dynamic is intended to be a cue to agents to > redownload the file periodically, you probably also want to give them > an indication of how often to do so. HTTP caching could be used to do > that. Yes, that is planned. We are trying to define the document format in this draft, with as little client behavior as possible. > - sec 4.2.6, the Openoffice example confused me briefly. You need to > make sure it's seen to be an example, and also that "OpenOffice.org" > isn't the only possible value. Perhaps change to; > > The "metalink:identity" element is a Text construct that conveys a > human-readable name for a file. For example, the identity of OpenOffice.org > 3.0 might be "OpenOffice.org", "Openoffice", or "OpenOffice 3.0". Let's change this because it's confusing. I believe "OpenOffice.org" is specifically named that because "OpenOffice" is a different product. "3.0" would go in the version element (sec 4.2.19) - should I mention that in the draft if it's unclear? Is this sufficient? The "metalink:identity (The "metalink:identity" Element)" element is a Text construct that conveys a human-readable identity for a file. For example, the identity of Firefox 3.5 would be "Firefox". > - sec 4.2.10.2. do we really need to use a special "torrent" type > when "application/x-bittorrent" could be used? I'd prefer to stick > just to media type syntax and get rid of the reserved syntax. You > should also call them "media types" instead of (or as well as if you > prefer) MIME types, and include a reference to BCP 13. This has come up a few times in the past. :) http://www.ietf.org/mail-archive/web/apps-review/current/msg00162.html I prefer your approach, but I'd like others to weigh in. An alternative would be to drop any mention of torrents, but this is how people use metalink so I'd like it to be clear what they can do. I've made it "MIME media type", as used in RFC 4287, and referenced BCP 13/RFC 4288/ > - in sec 6.3, it's not within the authority of a protocol > specification to tell agents that they "MUST NOT stop processing" or > "MUST NOT change their behaviour". They might have their own > perfectly good reasons for, say, halting if some XHTML with Javascript > were included. I agree with what you're trying to accomplish, but > that should be specified by saying, for example, that extensions can > be ignored. That section is stolen outright from RFC 4287 sec 6.3 http://tools.ietf.org/html/rfc4287#section-6.3 You see the intent of what we want. Can you suggest replacement text? > Overall, a decent spec. It's nice to see extensibility given > considerable attention for a change. Thanks, Mark! There are already a handful of metalink extensions and we want to ensure that continues. As you can see, we're relying on the text from Atom. Without it as a starting point, I think this draft would've been impossible. We keep interim revisions at http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads -- (( 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 -~----------~----~----~----~------~----~------~--~---
