Re: #462, was: p5: editorial suggestions

[Julian Reschke <[e-mail]>]

On 2013-06-20 17:58, Mark Nottingham wrote:
>
> On 20/06/2013, at 8:35 AM, Julian Reschke <[e-mail]> wrote:
>
>> On 2013-04-23 05:47, Mark Nottingham wrote:
>>>
>>> * 2.1 "A byte range operation MAY specify..."   This is the only place "operation" is used in the document; it should either be defined, or replaced by another term.
>>
>> Done in <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2296>.
>>
>>> * 3.1 "...and only if the result of their evaluation is leading toward a 200 (OK) response."  This is a bit informal...
>>
>> Any suggestions?
>
> "would result in"?

I wasn't sure whether the current text is supposed to leave some wiggle 
room, but maybe that's not needed.

So maybe change

"The Range header field is evaluated after evaluating the preconditions 
of [Part4] and only if the result of their evaluation is leading toward 
a 200 (OK) response. In other words, Range is ignored when a conditional 
GET would result in a 304 (Not Modified) response."

to

"The Range header field is evaluated after evaluating the preconditions 
of [Part4] and only if the result in absence of the Range header field 
would be a 200 (OK) response. In other words, Range is ignored when a 
conditional GET would result in a 304 (Not Modified) response."

?

>>> * 3.1 "If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified range(s) are invalid or unsatisfiable, the server SHOULD send a 416 (Range Not Satisfiable) response."
>>>
>>> Yet 4.4 says: "because servers are free to ignore Range, many implementations will simply respond with 200 (OK) if the requested ranges
>>> are invalid or not satisfiable."
>>
>> Actually, they'd return 200 even *if* the range is both valid and satisfiable, right? Should we clarify that?
>
> Yes; I think just drop the "if the requested…" clause.

Yes (<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2297>)

>>> I think sometimes responding with 200 is the right thing to do here sometimes, and so we shouldn't put a requirement against it. We could either remove the SHOULD, or qualify it with something that allows the server to make a judgement call.
>>
>> 4.4 mentions as a possible reason to prevent clients from resubmitting invalid requests; is this what we should mention here?
>
> Perhaps. Looking at this again, I'm less concerned than I was, but adding that text might be helpful.

Ok.

>>> * 4.3 first paragraph re-defines what validator strength is; this should just be a reference to p4.
>>
>> But then it doesn't seem to say exactly the same thing.
>
> Well, that's not good, is it?

It wouldn't be good, but it probably also wouldn't be something we can 
change right now.

>>> * 4.3 last paragraph places a requirement on clients to "record" sets of ranges; how exactly do they meet this requirement? Terminology seems strange.
>>
>> Maybe "process"?
>
>
> WFM.

<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2297>

Best regards, Julian