W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

review of p5-latest

From: Thomas Fossati <TFossati@velocix.com>
Date: Mon, 22 Oct 2012 14:51:58 +0000
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <DA86AAEF6E448540808AFA696EA47E5A40069EAF@EXB01-MLT.corp.velocix.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 October 2012 14:52:34 GMT