- From: Ken Murchison <murch@andrew.cmu.edu>
- Date: Thu, 28 Mar 2013 15:36:26 -0400
- To: ietf-http-wg@w3.org
Hi All, Sec 1, para 2: The phrase "obsoleting those parts previously defined in [RFC2616]" seems unnecessary since the document boilerplate already states as such. Also, parts 4 and 6 which similarly describe optional facilities don't bother with such text. Sec 2.1, postscript to suffix-byte-range-spec ABNF: The sentence immediately following the description of how to handle a representation shorter than the suffix-length begins with "For example..." . One would think that the example would demonstrate over-sized suffix-length case, but it doesn't. I don't think such an example is needed, but I think the wording is misleading. I would suggest removing the "For example..." sentence and replacing it with "Examples of byte-ranges-specifier values:" or "Additional examples of byte-ranges-specifier values:" or "Examples of byte-ranges-specifier values using suffix-byte-range-spec:" like is done for the discussion of byte-range-spec. Sec 4.4, Note: suggest changing "... many implementations will simply respond with 200 (OK) ..." -> "... many implementations will simply respond with the entire selected representation in a 200 (OK) response ..." General implementation question that I didn't find answered in the document: Can a server that receives a request for multiple ranges reply with only a single part corresponding to the first satisfiable range? Or can it coalesce all satisfiable ranges into a single part regardless of the overlaps/gaps? -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University
Received on Thursday, 28 March 2013 19:36:55 UTC