mnot
commented
10 years ago - julian.reschke@gmx.de changed component from
non-specifictop6-cache - julian.reschke@gmx.de changed owner to
draft-ietf-httpbis-p6-cache@tools.ietf.org
Closed mnot closed 3 years ago
mnot
commented
10 years ago non-specific to p6-cachedraft-ietf-httpbis-p6-cache@tools.ietf.orgmnot
commented
10 years ago julian.reschke@gmx.de changed description from:
Minor Issues:
In Section 1:
"Any client or server MAY employ a cache, though a cache cannot be used by a server that is acting as a tunnel."
I suggest not using the RFC 2119 "may" in the Introduction section.
In Section 1.2.1:
"If a cache receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent calculations overflows, the cache MUST consider the value to be 2147483648 (2^31). A recipient parsing a delta-seconds value MUST use an arithmetic type of at least 31 bits of range, and a sender MUST NOT generate delta-seconds with a value greater than 2147483648.."
Shouldn't the largest value be 2147483647 (see MAX_INT)?
It seems superfluous to have the second RFC 2119 "must" and the RFC 2119 "must not".
In Section 5.2.2.2:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."
I suggest not having RFC 2119 key words as part of a note.
In Section 5.2.2.3:
'The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.'
There is a RFC 2119 "must not" followed by an explanation of the requirement which includes a RFC 2119 "must not" and a "must". I suggest rewriting the (first) requirement so that it is clear instead of explaining a requirement with another requirement.
In Section 5.2.2.6:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."
I suggest not having the RFC 2119 "should not" as a part of a note. This suggestion also applies to the note in Section 5.2.2.8 and Section 5.2.2.9.
Nits:
In Section 4.2:
"o A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time.
o A cache recipient SHOULD consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration."Section 7.1.1.1 of draft-ietf-httpbis-p2-semantics-24 states that:
"An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC)."
If there is a requirement for the cache to use UTC (re. HTTP-date) internally the above RFC 2119 key words could be collapsed into that.
to:
Minor Issues:
In Section 1:
"Any client or server MAY employ a cache, though a cache cannot be used by a server that is acting as a tunnel."
I suggest not using the RFC 2119 "may" in the Introduction section.- see #515In Section 1.2.1:
"If a cache receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent calculations overflows, the cache MUST consider the value to be 2147483648 (2^31). A recipient parsing a delta-seconds value MUST use an arithmetic type of at least 31 bits of range, and a sender MUST NOT generate delta-seconds with a value greater than 2147483648.."
Shouldn't the largest value be 2147483647 (see MAX_INT)?
It seems superfluous to have the second RFC 2119 "must" and the RFC 2119 "must not".
In Section 5.2.2.2:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."
I suggest not having RFC 2119 key words as part of a note.
In Section 5.2.2.3:
'The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.'
There is a RFC 2119 "must not" followed by an explanation of the requirement which includes a RFC 2119 "must not" and a "must". I suggest rewriting the (first) requirement so that it is clear instead of explaining a requirement with another requirement.
In Section 5.2.2.6:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."
I suggest not having the RFC 2119 "should not" as a part of a note. This suggestion also applies to the note in Section 5.2.2.8 and Section 5.2.2.9.
Nits:
In Section 4.2:
"o A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time.
o A cache recipient SHOULD consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration."Section 7.1.1.1 of draft-ietf-httpbis-p2-semantics-24 states that:
"An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC)."
If there is a requirement for the cache to use UTC (re. HTTP-date) internally the above RFC 2119 key words could be collapsed into that.
mnot
commented
10 years ago julian.reschke@gmx.de changed description from:
Minor Issues:
In Section 1:
"Any client or server MAY employ a cache, though a cache cannot be used by a server that is acting as a tunnel."
I suggest not using the RFC 2119 "may" in the Introduction section.- see #515In Section 1.2.1:
"If a cache receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent calculations overflows, the cache MUST consider the value to be 2147483648 (2^31). A recipient parsing a delta-seconds value MUST use an arithmetic type of at least 31 bits of range, and a sender MUST NOT generate delta-seconds with a value greater than 2147483648.."
Shouldn't the largest value be 2147483647 (see MAX_INT)?
It seems superfluous to have the second RFC 2119 "must" and the RFC 2119 "must not".
In Section 5.2.2.2:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."
I suggest not having RFC 2119 key words as part of a note.
In Section 5.2.2.3:
'The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.'
There is a RFC 2119 "must not" followed by an explanation of the requirement which includes a RFC 2119 "must not" and a "must". I suggest rewriting the (first) requirement so that it is clear instead of explaining a requirement with another requirement.
In Section 5.2.2.6:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."
I suggest not having the RFC 2119 "should not" as a part of a note. This suggestion also applies to the note in Section 5.2.2.8 and Section 5.2.2.9.
Nits:
In Section 4.2:
"o A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time.
o A cache recipient SHOULD consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration."Section 7.1.1.1 of draft-ietf-httpbis-p2-semantics-24 states that:
"An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC)."
If there is a requirement for the cache to use UTC (re. HTTP-date) internally the above RFC 2119 key words could be collapsed into that.
to:
Minor Issues:
In Section 1:
"Any client or server MAY employ a cache, though a cache cannot be used by a server that is acting as a tunnel."
I suggest not using the RFC 2119 "may" in the Introduction section.- see #515
In Section 1.2.1:
"If a cache receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent calculations overflows, the cache MUST consider the value to be 2147483648 (2^31^). A recipient parsing a delta-seconds value MUST use an arithmetic type of at least 31 bits of range, and a sender MUST NOT generate delta-seconds with a value greater than 2147483648.."
Shouldn't the largest value be 2147483647 (see MAX_INT)?
It seems superfluous to have the second RFC 2119 "must" and the RFC 2119 "must not".
In Section 5.2.2.2:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."
I suggest not having RFC 2119 key words as part of a note.
In Section 5.2.2.3:
'The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.'
There is a RFC 2119 "must not" followed by an explanation of the requirement which includes a RFC 2119 "must not" and a "must". I suggest rewriting the (first) requirement so that it is clear instead of explaining a requirement with another requirement.
In Section 5.2.2.6:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."
I suggest not having the RFC 2119 "should not" as a part of a note. This suggestion also applies to the note in Section 5.2.2.8 and Section 5.2.2.9.
Nits:
In Section 4.2:
"o A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time.
o A cache recipient SHOULD consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration."Section 7.1.1.1 of draft-ietf-httpbis-p2-semantics-24 states that:
"An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC)."
If there is a requirement for the cache to use UTC (re. HTTP-date) internally the above RFC 2119 key words could be collapsed into that.
mnot
commented
10 years ago julian.reschke@gmx.de commented:
From 2456:
Remove the "Note:" from requirements on using token/quoted-string for certain cache-control directives (see #512)
mnot
commented
10 years ago julian.reschke@gmx.de changed description from:
Minor Issues:
In Section 1:
"Any client or server MAY employ a cache, though a cache cannot be used by a server that is acting as a tunnel."
I suggest not using the RFC 2119 "may" in the Introduction section.- see #515
In Section 1.2.1:
"If a cache receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent calculations overflows, the cache MUST consider the value to be 2147483648 (2^31^). A recipient parsing a delta-seconds value MUST use an arithmetic type of at least 31 bits of range, and a sender MUST NOT generate delta-seconds with a value greater than 2147483648.."
Shouldn't the largest value be 2147483647 (see MAX_INT)?
It seems superfluous to have the second RFC 2119 "must" and the RFC 2119 "must not".
In Section 5.2.2.2:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."
I suggest not having RFC 2119 key words as part of a note.
In Section 5.2.2.3:
'The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.'
There is a RFC 2119 "must not" followed by an explanation of the requirement which includes a RFC 2119 "must not" and a "must". I suggest rewriting the (first) requirement so that it is clear instead of explaining a requirement with another requirement.
In Section 5.2.2.6:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."
I suggest not having the RFC 2119 "should not" as a part of a note. This suggestion also applies to the note in Section 5.2.2.8 and Section 5.2.2.9.
Nits:
In Section 4.2:
"o A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time.
o A cache recipient SHOULD consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration."Section 7.1.1.1 of draft-ietf-httpbis-p2-semantics-24 states that:
"An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC)."
If there is a requirement for the cache to use UTC (re. HTTP-date) internally the above RFC 2119 key words could be collapsed into that.
to:
Minor Issues:
In Section 1:
"Any client or server MAY employ a cache, though a cache cannot be used by a server that is acting as a tunnel."
I suggest not using the RFC 2119 "may" in the Introduction section.- see #515
In Section 1.2.1:
"If a cache receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent calculations overflows, the cache MUST consider the value to be 2147483648 (2^31^). A recipient parsing a delta-seconds value MUST use an arithmetic type of at least 31 bits of range, and a sender MUST NOT generate delta-seconds with a value greater than 2147483648.."
Shouldn't the largest value be 2147483647 (see MAX_INT)?
It seems superfluous to have the second RFC 2119 "must" and the RFC 2119 "must not".
In Section 5.2.2.2:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."
I suggest not having RFC 2119 key words as part of a note.- see 2456
In Section 5.2.2.3:
'The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.'
There is a RFC 2119 "must not" followed by an explanation of the requirement which includes a RFC 2119 "must not" and a "must". I suggest rewriting the (first) requirement so that it is clear instead of explaining a requirement with another requirement.
In Section 5.2.2.6:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."~~I suggest not having the RFC 2119 "should not" as a part of a note. This suggestion also applies to the note in Section 5.2.2.8 and Section 5.2.2.9.~~ - 2456
Nits:
In Section 4.2:
"o A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time.
o A cache recipient SHOULD consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration."Section 7.1.1.1 of draft-ietf-httpbis-p2-semantics-24 states that:
"An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC)."
If there is a requirement for the cache to use UTC (re. HTTP-date) internally the above RFC 2119 key words could be collapsed into that.
mnot
commented
10 years ago julian.reschke@gmx.de changed severity from In WG Last Call to In IETF LC
mnot
commented
10 years ago @mnot commented:
From 2484:
Note that maximum max-age might cause problems for some platforms. See #512
mnot
commented
10 years ago Leaving the requirements alone.
incorporatednew to closedmnot
commented
10 years ago fielding@gbiv.com commented:
I did some research after the meeting on the maximum delta-seconds value of 2147483648 (2^31^) and found that it was introduced after a discussion of the caching interest group (in response to a critique by Koen Holtman) and introduced as part of the big cache section dump without any further discussion. Hence, it was a mistake -- the intended value for senders is a 32bit INT_MAX. Since this section also makes a 2119 requirement on implementations (not on protocol) that is unwarranted, I have fixed it so that the single remaining requirement makes sense.
Backwards compatibility here would be useless because the reason for the maximum value on senders is to prevent overflow on 32bit max recipients. Continuing to support an overflow value for that purpose would be worse than deleting the requirement entirely.
mnot
commented
10 years ago fielding@gbiv.com commented:
From 2488:
Fix the maximum value for delta-seconds for senders to be 2147483647 instead of 2147483648, since the goal was to prevent 32bit INT_MAX overflow on recipients; reduce other implementation requirements to an ought and to what is necessary to preserve the intended value; see #512
mnot
commented
10 years ago fielding@gbiv.com changed description from:
Minor Issues:
In Section 1:
"Any client or server MAY employ a cache, though a cache cannot be used by a server that is acting as a tunnel."
I suggest not using the RFC 2119 "may" in the Introduction section.- see #515
In Section 1.2.1:
"If a cache receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent calculations overflows, the cache MUST consider the value to be 2147483648 (2^31^). A recipient parsing a delta-seconds value MUST use an arithmetic type of at least 31 bits of range, and a sender MUST NOT generate delta-seconds with a value greater than 2147483648.."
Shouldn't the largest value be 2147483647 (see MAX_INT)?
It seems superfluous to have the second RFC 2119 "must" and the RFC 2119 "must not".
In Section 5.2.2.2:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."
I suggest not having RFC 2119 key words as part of a note.- see 2456
In Section 5.2.2.3:
'The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.'
There is a RFC 2119 "must not" followed by an explanation of the requirement which includes a RFC 2119 "must not" and a "must". I suggest rewriting the (first) requirement so that it is clear instead of explaining a requirement with another requirement.
In Section 5.2.2.6:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."~~I suggest not having the RFC 2119 "should not" as a part of a note. This suggestion also applies to the note in Section 5.2.2.8 and Section 5.2.2.9.~~ - 2456
Nits:
In Section 4.2:
"o A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time.
o A cache recipient SHOULD consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration."Section 7.1.1.1 of draft-ietf-httpbis-p2-semantics-24 states that:
"An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC)."
If there is a requirement for the cache to use UTC (re. HTTP-date) internally the above RFC 2119 key words could be collapsed into that.
to:
Minor Issues:
In Section 1:
"Any client or server MAY employ a cache, though a cache cannot be used by a server that is acting as a tunnel."
I suggest not using the RFC 2119 "may" in the Introduction section.- see #515
In Section 1.2.1:~~ "If a cache receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent calculations overflows, the cache MUST consider the value to be 2147483648 (2^31^). A recipient parsing a delta-seconds value MUST use an arithmetic type of at least 31 bits of range, and a sender MUST NOT generate delta-seconds with a value greater than 2147483648.."~~
Shouldn't the largest value be 2147483647 (see MAX_INT)?~~It seems superfluous to have the second RFC 2119 "must" and the RFC 2119 "must not".~~
In Section 5.2.2.2:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."
I suggest not having RFC 2119 key words as part of a note.- see 2456
In Section 5.2.2.3:
'The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.'
There is a RFC 2119 "must not" followed by an explanation of the requirement which includes a RFC 2119 "must not" and a "must". I suggest rewriting the (first) requirement so that it is clear instead of explaining a requirement with another requirement.
In Section 5.2.2.6:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."~~I suggest not having the RFC 2119 "should not" as a part of a note. This suggestion also applies to the note in Section 5.2.2.8 and Section 5.2.2.9.~~ - 2456
Nits:
In Section 4.2:
"o A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time.
o A cache recipient SHOULD consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration."Section 7.1.1.1 of draft-ietf-httpbis-p2-semantics-24 states that:
"An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC)."
If there is a requirement for the cache to use UTC (re. HTTP-date) internally the above RFC 2119 key words could be collapsed into that.
mnot
commented
10 years ago fielding@gbiv.com changed description from:
Minor Issues:
In Section 1:
"Any client or server MAY employ a cache, though a cache cannot be used by a server that is acting as a tunnel."
I suggest not using the RFC 2119 "may" in the Introduction section.- see #515
In Section 1.2.1:~~ "If a cache receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent calculations overflows, the cache MUST consider the value to be 2147483648 (2^31^). A recipient parsing a delta-seconds value MUST use an arithmetic type of at least 31 bits of range, and a sender MUST NOT generate delta-seconds with a value greater than 2147483648.."~~
Shouldn't the largest value be 2147483647 (see MAX_INT)?~~It seems superfluous to have the second RFC 2119 "must" and the RFC 2119 "must not".~~
In Section 5.2.2.2:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."
I suggest not having RFC 2119 key words as part of a note.- see 2456
In Section 5.2.2.3:
'The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.'
There is a RFC 2119 "must not" followed by an explanation of the requirement which includes a RFC 2119 "must not" and a "must". I suggest rewriting the (first) requirement so that it is clear instead of explaining a requirement with another requirement.
In Section 5.2.2.6:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."~~I suggest not having the RFC 2119 "should not" as a part of a note. This suggestion also applies to the note in Section 5.2.2.8 and Section 5.2.2.9.~~ - 2456
Nits:
In Section 4.2:
"o A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time.
o A cache recipient SHOULD consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration."Section 7.1.1.1 of draft-ietf-httpbis-p2-semantics-24 states that:
"An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC)."
If there is a requirement for the cache to use UTC (re. HTTP-date) internally the above RFC 2119 key words could be collapsed into that.
to:
Minor Issues:
In Section 1:
"Any client or server MAY employ a cache, though a cache cannot be used by a server that is acting as a tunnel."
I suggest not using the RFC 2119 "may" in the Introduction section.- see #515
In Section 1.2.1:
"If a cache receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent calculations overflows, the cache MUST consider the value to be 2147483648 (2^31^). A recipient parsing a delta-seconds value MUST use an arithmetic type of at least 31 bits of range, and a sender MUST NOT generate delta-seconds with a value greater than 2147483648.."
Shouldn't the largest value be 2147483647 (see MAX_INT)?
It seems superfluous to have the second RFC 2119 "must" and the RFC 2119 "must not".
In Section 5.2.2.2:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."
I suggest not having RFC 2119 key words as part of a note.- see 2456
In Section 5.2.2.3:
'The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.'
There is a RFC 2119 "must not" followed by an explanation of the requirement which includes a RFC 2119 "must not" and a "must". I suggest rewriting the (first) requirement so that it is clear instead of explaining a requirement with another requirement.
In Section 5.2.2.6:
"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."~~I suggest not having the RFC 2119 "should not" as a part of a note. This suggestion also applies to the note in Section 5.2.2.8 and Section 5.2.2.9.~~ - 2456
Nits:
In Section 4.2:
"o A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time.
o A cache recipient SHOULD consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration."Section 7.1.1.1 of draft-ietf-httpbis-p2-semantics-24 states that:
"An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC)."
If there is a requirement for the cache to use UTC (re. HTTP-date) internally the above RFC 2119 key words could be collapsed into that.
mnot
commented
10 years ago mnot
commented
10 years ago 512.diffProposed patch
mnot
commented
10 years ago fielding@gbiv.com commented:
From 2494:
Explain the value 2147483648 in delta-seconds, reduce the MUST implement as 31 bits to an ought (not valid use of 2119 terms), and remove unimplemented requirement that sender MUST NOT generate a value greater than 2147483648; see #512
Minor Issues:
In Section 1:"Any client or server MAY employ a cache, though a cache cannot be used by a server that is acting as a tunnel."I suggest not using the RFC 2119 "may" in the Introduction section.- see #515In Section 1.2.1:
"If a cache receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent calculations overflows, the cache MUST consider the value to be 2147483648 (2^31^). A recipient parsing a delta-seconds value MUST use an arithmetic type of at least 31 bits of range, and a sender MUST NOT generate delta-seconds with a value greater than 2147483648.."
Shouldn't the largest value be 2147483647 (see MAX_INT)?
It seems superfluous to have the second RFC 2119 "must" and the RFC 2119 "must not".
In Section 5.2.2.2:"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."I suggest not having RFC 2119 key words as part of a note.- see 2456In Section 5.2.2.3:
'The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.'
There is a RFC 2119 "must not" followed by an explanation of the requirement which includes a RFC 2119 "must not" and a "must". I suggest rewriting the (first) requirement so that it is clear instead of explaining a requirement with another requirement.
In Section 5.2.2.6:"Note: This directive uses the quoted-string form of the argument syntax. A sender SHOULD NOT generate the token form (even if quoting appears not to be needed for single-entry lists)."~~I suggest not having the RFC 2119 "should not" as a part of a note. This suggestion also applies to the note in Section 5.2.2.8 and Section 5.2.2.9.~~ - 2456
Nits:
In Section 4.2:
"o A cache recipient MUST NOT allow local time zones to influence the calculation or comparison of an age or expiration time.
Section 7.1.1.1 of draft-ietf-httpbis-p2-semantics-24 states that:
"An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC)."
If there is a requirement for the cache to use UTC (re. HTTP-date) internally the above RFC 2119 key words could be collapsed into that.
Reported by julian.reschke@gmx.de, migrated from https://trac.ietf.org/trac/httpbis/ticket/512