p4 editorial nits

[julian.reschke@…]

Kenneth Murchinson reports:

Looking over the latest diffs I found a couple of typos:

• Sec 3.4, 1st sent" "earlier or equal to" -> "earlier than or equal to"

• Sec 3.4, para 5, 1st sent: "resource that resource" -> "resource that"

• Sec 3.5, 1st para, 1st sent: "similar the If-Match and If-Unmodified-Since fields" -> "similar to the If-Match and If-Unmodified-Since header fields"

(above fixed in [2379])

Now on to my nits. Sections 3.1 - 3.4 aren't entirely uniform after the current rewrite, especially Section 3.3:

• Sec 3.2, 1st para, 1st sent, 2nd clause (to match Sec 3.1): "current representation" -> "current representation of the target resource"

• Sec 3.4, para 6, 2nd sent (to explicitly state when condition is false like in Sec 3.1 and 3.2): "the selected representation has been modified since the time specified in this field" -> "the selected representation's last modification date is more recent than the date provided in the field-value"

• Sec 3.3, last para, 1st sent: "during a past run" isn't very descriptive for 1st time readers ("run" of what?). Suggest changing this to something like "in a prior response"

• Sec 3.3, 1st para not uniform with Sec 3.1, 3.2, 3.4. Suggest changing it to something like the following:

The "If-Modified-Since" header field makes the GET or HEAD request method conditional on the selected representation's modification date being more recent than the date provided in the field-value. This accomplishes the same purpose as If-None-Match for cases where the user agent does not have an entity-tag for the representation.

(above fixed in [2387])

Sec 3.3 is missing paragraphs like the last 2 in Sec 3.1, 3.2, 3.4. Suggest appending the following to Sec 3.3:

An origin server that receives an If-Modified-Since header field MUST evaluate the condition prior to performing the method (Section 5). The condition is false if the selected representation's last modification date is earlier than or equal to the date provided in the field-value.

An origin server MUST NOT perform the requested method if the condition evaluates to false: instead, the origin server MUST respond with the 304 (Not Modified) status code.

• Sec 3.3, para 4, 2nd sent: Should this sentence regarding use of Last-Modified/Date? also be included of para 4 in Sec 3.4?

• Sec 3.3, last 2 para: Should Sec 3.4 have a similar discussion of how to generate the field-value?

• Should the 1st sentences of Sec 3.3 and 3.4 use "recipient cache or origin server" like Sec 3.1 and 3.2?

(above addressed in [2389])

And finally, one question for my own understanding:

• Why STRONG comparison for If-Match and WEAK for If-None-Match? Is this due to selection vs validation?

(above addressed in [2390])

[julian.reschke@…]

From [2379]:

fix typos (see #495)

[julian.reschke@…]

From [2387]:

enhance consistency in header field descriptions (see #495)

[julian.reschke@…]

From [2388]:

typo fixed (see #495)

[fielding@…]

Sec 3.3 is missing paragraphs like the last 2 in Sec 3.1, 3.2, 3.4. Suggest appending the following to Sec 3.3:

An origin server that receives an If-Modified-Since header field MUST evaluate the condition prior to performing the method (Section 5). The condition is false if the selected representation's last modification date is earlier than or equal to the date provided in the field-value.

An origin server MUST NOT perform the requested method if the condition evaluates to false: instead, the origin server MUST respond with the 304 (Not Modified) status code.

I have added similar paragraphs. Unlike the other fields, implementation of IMS checks is only a SHOULD, since a 200 response only results in less efficiency rather than an interop failure.

Sec 3.3, para 4, 2nd sent: Should this sentence regarding use of Last-Modified/Date?? also be included of para 4 in Sec 3.4?

No, in fact it should have been removed when the cache requirements were moved to p6. Done.

Sec 3.3, last 2 para: Should Sec 3.4 have a similar discussion of how to generate the field-value?

No, If-Unmodified-Since has different use cases -- it is similar to If-Match.

Should the 1st sentences of Sec 3.3 and 3.4 use "recipient cache or origin server" like Sec 3.1 and 3.2?

No, conditionals based on modification date behave differently than those based on having, or not having, a matching entity tag.

[fielding@…]

From [2389]:

more consistency in conditional header field definitions; addresses #495

[fielding@…]

From [2390]:

remind folks why weak or strong comparison is used; addresses #495

[fielding@…]

And finally, one question for my own understanding:

• Why STRONG comparison for If-Match and WEAK for If-None-Match? Is this due to selection vs validation?

Yes, this is somewhat covered by prior sections, but reminders next to the requirements are useful. [2390]

Finished.

[fielding@…]

unstrike the description now that it is closed

[julian.reschke@…]

From [2394]:

Note changes for [2389] and [2390] (see #495)

[mnot@…]

"usable for use cases"? [2390]

[fielding@…]

From [2403]:

okay, usable for use cases is kind of lame, but so is defining what use means; addresses #495