The getContentStream (REST) service description includes query params for offset and length (to indicate a sub-range of the return stream). And will "return the current content stream using HTTP mechanisms, including respecting the HTTP Content-Range parameters". I assume that this means that Content-Range should be part of the return header (with a status of 206) when offset/length params are supplied. However, the choice of the verb "respecting" leads to to assume that possibly the spec intends to also support the Range request header field? If so, it should be called out. Also, if this is the case, why have the query parameters when there is already a standard HTTP mechanism for supporting this feature?

   1. If we supported the Range request header, would we also have to therefore support multiple ranges (in a multi-part reply)?
   2. Would it be feasible to allow Range/Content-Range support be optional?

The v0.6 Part 1 now says each protocol binding SHALL support ranging in a protocol-appropriate manner. This implies that it is recommended/encouraged/expected but not strictly manditory. It also (hopefully) means that the query parameters are gone and the v0.6 REST will rely on Range headers (but this is not clear).

I think this should be truely optional (MAY), as it is unlikely to really be necessary. Else provide a compelling use-case for its need.

In v0.6 part I it says SHALL, but we propose it say MAY. Also, part II doesn't even specify any request params for GET, so not sure if they were left out accidentally, of it was deferring to part I (which is what we'd prefer). Part II REST section should also state that if you do implement range, you should use the standard HTTP headers (Range/ContentRange).