review of p5-latest

Hi, I've been reading from top to bottom the last version of p5, and got
this small bunch of comments.

Cheers, Thomas.


= Misc:
  * I can't find an explicit "MUST not include Content-Range in a response
header when Content-Type is multipart/byteranges"
  * Sect. 3.2/5.2: is "*/*" an acceptable value for Content-Range + 416 ?
  * Sect. 4.1: requirement to serve ranges in the order specified by the
client could be in contrast with the suggestion, a couple of paragraphs
afterwards, of combining overlapping ranges (which could imply reordering)
  * Sect. 4.2, last paragraph: "... then the client MAY store ...", isn't
it an implementation detail ?
  * Sect. 7.1: the actual suggestion for reducing the security risk
associated to overlapping ranges is not detailed (as promised in the first
paragraph of Sect. 7).  Add a back-link to Sect. 4.1 ?  Or move the
"Server MAY combine requested ranges ..." here ?  Further to this point,
it would be nice to mandate some preferred behaviour on both senders
and/or receivers to simplify interoperability (e.g. senders SHOULD not
send overlapping ranges and/or receivers SHOULD always compute the minimum
number of ranges needed to satisfy a given range request).
  * Appendix A: I may be missing something obvious, but I can't find any
good reason (i.e. one that is not listed in -p1 Sect. 3.3.2) to avoid
stating the Content-Length in the examples.

= Editorial:
  * Sect. 5.3: "... send me the part(s) that I'm missing ..." => "... send
me the part(s) I'm requesting ..."
  * Sect. 5.4.2: the preamble to the bulleted list has the attribute
"appropriate" which could be substituted by a less generic wording, like
e.g.: "... are all syntactically correct as defined in Section 5.4.1, and
at least one of the ranges has non empty intersection with the current
resource representation extent, then: ..."
  * Sect. 5.2, last paragraph seems misplaced (does it belong to Sect. 5.4
instead ?)


= Typos:
  * Sect. 4.2: "most header" => "most recent header"
  * Sect. 5.2: "request: A" => "request: a"

Received on Monday, 22 October 2012 14:52:30 UTC