Conditional Requests editorial suggestions

[mnot@…]

• - section 1, p3, Introduction, first sentence

I can not parse that sentence, should it perhaps be "....on that metadata be checked...." -> "....on that metadata; to be checked...."?

• - 1.1, p3, conformance and error handling, 3d paragraph

I don't get the statement about "SHOULD-level" requirements. Isn't that always the case with SHOULD? I.e. what is different from RFC2119?

• - 1.2, p4, Syntax

I think it would be helpful to state what OWS, obs-text and HTTP-date (informal) stand for, the production rule given here does not provide much clarity

• - 2.2, p6 last-modiefied

This paragraph came a bit out of the blue it is not mentioned that Last-Modified is one of the validators that you just talked about in the previous paragraph

• - 2.2.1, p7, generation, one but last paragraph

Seems that a bad system clock can nevertheless screw things up, if the system clock is set to earlier than the previous "fresh page" the content will never be updated.

• - 2.3 ETag, p9, 2nd paragraph

The "more reliable" and "convenient" don't seem to be related, even though that is suggested in the paragraph. I would argue that an entity-tag can be implemented to be more reliable period (because of the clock problems discussed before)

• - 2.4, p12, Rules.... HTTP/1.1 clients

So if I understand the "MUST use the entity-tag" correctly the heuristic that is being used for servers can not be used here. Like in the server example I could imagine that also the client could decide not to fetch new weather data based on some internal rule (because it is mobile and wants to avoid rapid updates for example)

The MAY use the Last-Modified in the case of an HTTP/1.0 origin server deserves some explanation, not being an HTTP expert it is unclear to me what makes it deifferent for 1.1

3.1, p 13, If-Match

Most HTTP return codes are expanded, highly appreciated! Could you please do that for all, i.e. "304" -> "304 (not modified)" etc., that makjes for a much easier read.

3.3, p16 If-Modified-Since, First Note:

What is the consequence of the Range header field modifying the meaning?

[julian.reschke@…]

From [1733]:

Editorial improvements (see #366)

[julian.reschke@…]

Replying to mnot@…:

• - section 1, p3, Introduction, first sentence

I can not parse that sentence, should it perhaps be "....on that metadata be checked...." -> "....on that metadata; to be checked...."?

Fixed in ​http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1733

• - 1.1, p3, conformance and error handling, 3d paragraph

I don't get the statement about "SHOULD-level" requirements. Isn't that always the case with SHOULD? I.e. what is different from RFC2119?

It may not be different, but we felt it's useful to state. Some people read SHOULD as "optional".

• - 1.2, p4, Syntax

I think it would be helpful to state what OWS, obs-text and HTTP-date (informal) stand for, the production rule given here does not provide much clarity

It's just a reference to Part 1, which you need to follow to understand the rule.

• - 2.2, p6 last-modiefied

This paragraph came a bit out of the blue it is not mentioned that Last-Modified is one of the validators that you just talked about in the previous paragraph

Added forward references in intro to 2.2 (​http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1733)

• - 2.2.1, p7, generation, one but last paragraph

Seems that a bad system clock can nevertheless screw things up, if the system clock is set to earlier than the previous "fresh page" the content will never be updated.

Not sure what to do here. If a system clock is set back into the past, and the system isn't aware of that, there's little that can be done.

• - 2.3 ETag, p9, 2nd paragraph

The "more reliable" and "convenient" don't seem to be related, even though that is suggested in the paragraph. I would argue that an entity-tag can be implemented to be more reliable period (because of the clock problems discussed before)

Not sure what the problem is. Proposed text would help.

• - 2.4, p12, Rules.... HTTP/1.1 clients

So if I understand the "MUST use the entity-tag" correctly the heuristic that is being used for servers can not be used here. Like in the server example I could imagine that also the client could decide not to fetch new weather data based on some internal rule (because it is mobile and wants to avoid rapid updates for example)

My reading is that the requirements apply to the case where the client *does* decide to fetch the resource, and *does* decice to make the request conditional; that is, it just states what validator to use.

The MAY use the Last-Modified in the case of an HTTP/1.0 origin server deserves some explanation, not being an HTTP expert it is unclear to me what makes it deifferent for 1.1

It's to allow use of LM in case the origin server doesn't know about ETags.

3.1, p 13, If-Match

Most HTTP return codes are expanded, highly appreciated! Could you please do that for all, i.e. "304" -> "304 (not modified)" etc., that makjes for a much easier read.

Seems we already did that.

3.3, p16 If-Modified-Since, First Note:

What is the consequence of the Range header field modifying the meaning?

Well, as specified in Part 5 :-). That being said, it's not clear why we say it just for this header field. Will discuss on the mailing list.

[mnot@…]

Editors: can this be closed?