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

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 May 2017 12:02:18 +1000

Everyone,

Patrick (as editor) feels that we're ready for WGLC on this draft, and there are no open issues.

Please have a look at:
 https://tools.ietf.org/html/draft-ietf-httpbis-immutable-02

and raise any issues that you see (here or on the issues list). Statements of support or planned implementation would also be helpful in judging consensus, so don't be shy.

WGLC will end in two weeks, on 17 May.

Regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: Mike Bishop <[email-masked]>
Date: Wed, 3 May 2017 15:13:24 +0000

Supported in WinInet as of current builds of Windows 10.

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Tuesday, May 2, 2017 7:02 PM
To: HTTP Working Group <[email-masked]>
Subject: Working Group Last Call -- draft-ietf-httpbis-immutable-02

Everyone,

Please have a look at:
 https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-httpbis-immutable-02&data=02%7C01%7CMichael.Bishop%40microsoft.com%7Cb8a3387fe1e0465fcbc508d491c913da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636293740188402585&sdata=e5Ui21E0whFQXLIrwp7AxevXaTOnBVVNTDWhtu72GaE%3D&reserved=0

Regards,

--
Mark Nottingham   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mnot.net%2F&data=02%7C01%7CMichael.Bishop%40microsoft.com%7Cb8a3387fe1e0465fcbc508d491c913da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636293740188412593&sdata=Hgb4bQ%2FCEOjQXnbwec%2FKbEge87C1BHnB7x1yGuY4zV0%3D&reserved=0

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 4 May 2017 15:16:12 +1200

Supported in Squid from version 4.0.16 beta.

Not much in the way of feedback, so far that has been all good.

Amos

---

From: Julian Reschke <[email-masked]>
Date: Sun, 14 May 2017 11:05:05 +0200

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