Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01)

[Dave Cridland <dave at cridland.net>]

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.

> > 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.


> > 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.

> > 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.

> > 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.


> 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.

> 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.


> > 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.

> > 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.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
APPS-REVIEW mailing list
APPS-REVIEW at ietf.org
https://www.ietf.org/mailman/listinfo/apps-review