- From: Anthony Bryan <anthonybryan@gmail.com>
- Date: Tue, 2 Sep 2008 22:25:45 -0400
- To: "Dave Cridland" <dave@cridland.net>
- Cc: "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
On Tue, Sep 2, 2008 at 8:05 PM, Dave Cridland <dave@cridland.net> wrote: > On Wed Sep 3 00:36:29 2008, Anthony Bryan wrote: >> >> > 2) The type attribute of the hash element ought to have values selected >> > from >> > the IANA registry of textual hash names; >> > http://www.iana.org/assignments/hash-function-text-names/ - section >> > 4.1.6.1 >> > & 4.2.4.1. >> >> Wow, thank you so much! I didn't know about that. Should I list the >> same hash types, or just have this: >> >> The IANA registry named "Hash Function Textual Names" defines values >> for hash types. >> >> > The latter - just point to the registry. Done. Thanks again, that seems to mesh well. I've changed the schema to just metalinkTextConstruct instead of the individual hash types too. >> > 4) Notational convention defines a different convention than is used in >> > the >> > examples. >> >> The RELAX NG Compact schema doesn't match the rest of the spec? Or >> something else? I'm still working on that, & if anyone wants to help >> out please do because I don't have much experience. >> >> > No, your conventions state you'll use a prefix of "metalink", but your > examples don't. There might have been something else, I forget now. I see, the schema at the end. I've fixed it. >> > 5) Section 2, "Metalink Documents MUST be well-formed >> > XML." - and presumably "namespace well-formed", as specified in >> > [XML-NAMES]? Or not? >> >> Yes. >> Is this something I need to add to the draft, or are you mentioning it >> because of internal inconsistencies in the examples? >> >> > No inconsistency, I simply thought that might be what you meant. I'm just asking if this is something that needs to be added, since it copies the Atom RFC text. Isn't it at least somewhat implied? I don't know enough here, so your (or others) input is appreciated. >> > 8) Section 4.1.4: "MUST contain one [good] and SHOULD contain more than >> > one" >> > - you mean if my download is only available from one location then this >> > may >> > provide a cause of poor interoperability? I don't think this is what you >> > mean. I think you mean: "MUST contain at least one". >> >> Exactly, that was an error. >> >> metalink:resources element MUST contain at least one metalink:url >> element and SHOULD contain more than one metalink:url elements. >> >> > No, not what I meant. That "SHOULD" is wrong - it can be a "MAY", but > "SHOULD" has a particular meaning - it means that if you only list one URL > here, you risk an interop failure. > > RFC 2119 is an addictive drug, but like most strong medicine, best used > sparingly. > > I suspect what you want to write is: > > The metalink:resources element MUST contain at least one metalink:url > element. Typically, such elements contain more than one metalink:url element > to provide multiple download sources. Yes, changed. >> > 10) Section 4.2.13: I had to read this twice to figure out it referred >> > to a >> > digital signature of the file to be downloaded. It might be as well to >> > define a term for that in section 2, and use it throughout. I suspect >> > the >> > nice security people might have something to say about specifying >> > PGP-only >> > detatched signatures. >> >> Can you suggest wording that is more clear? I've changed it to: >> >> The "metalink:signature" element is a Text construct that conveys a >> digital signature for a file described in a Metalink Document. >> >> > Much more obvious. Great. >> I hope some security people will have criticism (& additions) for this >> section. It describes how Metalink functions now, but we don't want to >> be PGP specific. I am not familiar enough with other options to write >> about it :) >> >> > I'm sure the security people will chip in. Looking forward to it. >> Do you suggest removing the "type" attribute & having a new separate >> element as Julian suggested? >> >> > Julian knows a lot more about XML than I do, I'd go along with what he says. Will do. >> > 12) Section 4.2.17.1: Perhaps preference and weight? See SRV. >> >> I'm not against that if others think that it is necessary/useful, but >> I haven't added it. >> >> > Might be worth discussing, at least - I've actually no opinion on the > subject, I just note that SRV, for one, opted for both, presumably based on > experience with MX. Good to have the input. >> > 14) Section 5 - I'd personally just ditch the entire thing, you >> > effectively >> > say all that's needed in Section 8.4. >> >> This is taken from the Atom RFC. If it needed to be there, does it >> need to be in this draft as well? >> >> > I'm not convinced it needs to be there either. I'll be conservative and leave it for now, depending on comments from others. Updated version at http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads
Received on Wednesday, 3 September 2008 02:26:22 UTC