Re: Working Group Last Call -- draft-ietf-httpbis-immutable-02

Hi everybody,

Nice work!

Here's my feedback (completely editorial):

> 2.1.  About Intermediaries
>
>    An immutable response has the same semantic meaning when received by
>    proxy clients as it does when received by User-Agent based clients.
>    Therefore proxies SHOULD skip conditionally revalidating fresh
>    responses containing the immutable extension unless there is a signal
>    from the client that a validation is necessary (e.g. a no-cache
>    Cache-Control request directive).

Maybe point to Section 5.2.1.4 of RFC 7234 here...

>    A proxy that uses immutable to bypass a conditional revalidation may
>    choose whether to reply with a 304 or 200 to its requesting client
>    based on the request headers the proxy received.

s/may/MAY/ or s/may/can/

> 2.2.  Example
>
>    Cache-Control: max-age=31536000, immutable

Maybe add a full example, including a request/response pair for the case 
when "immutable" is not present?

> 4.  IANA Considerations
>
>    [RFC7234] sections 7.1 and 7.1.2 require registration of the

s/[RFC7234] sections 7.1 and 7.1.2/Section 7.1 of .../

> ...

Best regards, Julian

Received on Sunday, 14 May 2017 09:05:44 UTC