Re: review of p5-latest

Thanks, Thomas; now <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/405>.


On 23/10/2012, at 1:51 AM, Thomas Fossati <TFossati@velocix.com> wrote:

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

--
Mark Nottingham   http://www.mnot.net/

Received on Thursday, 15 November 2012 06:00:46 UTC