Subject: Fwd: RFC 5861 on HTTP Cache-Control Extensions for Stale Content

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 May 2010 16:25:41 +1000

FYI. Thanks again to all that helped.

Begin forwarded message:

> From: [email-masked]
> Date: 6 May 2010 10:52:22 AM AEST
> To: [email-masked], [email-masked]
> Cc: [email-masked]
> Subject: RFC 5861 on HTTP Cache-Control Extensions for Stale Content
> 
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
>        RFC 5861
> 
>        Title:      HTTP Cache-Control Extensions for Stale 
>                    Content 
>        Author:     M. Nottingham
>        Status:     Informational
>        Stream:     Independent
>        Date:       May 2010
>        Mailbox:    [email-masked]
>        Pages:      6
>        Characters: 10359
>        Updates/Obsoletes/SeeAlso:   None
> 
>        I-D Tag:    draft-nottingham-http-stale-controls-00.txt
> 
>        URL:        http://www.rfc-editor.org/rfc/rfc5861.txt
> 
> This document defines two independent HTTP Cache-Control extensions
> that allow control over the use of stale responses by caches.  This 
> document is not an Internet Standards Track specification; it is
> published for informational purposes.
> 
> 
> INFORMATIONAL: This memo provides information for the Internet community.
> It does not specify an Internet standard of any kind. Distribution of
> this memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>  http://www.ietf.org/mailman/listinfo/ietf-announce
>  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
> For downloading RFCs, see http://www.rfc-editor.org/rfc.html.
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [email-masked].  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 06 May 2010 15:11:00 +0200

(FYI)

...this reminded me that we haven't got an IANA registry for cache 
control directives -- so I just opened 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/208>.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 07 May 2010 16:24:47 +0200

On 06.05.2010 15:11, Julian Reschke wrote:
> ...

OK, I have added (1) registry requirements, and (2) IANA considerations:

(1), added to 3.2.3:

3.2.3.  Cache Control Extensions

    ...

    The HTTP Cache Directive Registry defines the name space for the
    cache directives.

    Registrations MUST include the following fields:

    o  Cache Directive Name

    o  Pointer to specification text

    Values to be added to this name space are subject to IETF review
    ([RFC5226], Section 4.1).

    The registry itself is maintained at
    <http://www.iana.org/assignments/http-cache-directives>.

(2)

5.1.  Cache Directive Registry

    The registration procedure for HTTP Cache Directives is defined by
    Section 3.2.3 of this document.

    The HTTP Cache Directive Registry should be created at
    <http://www.iana.org/assignments/http-cache-directives> and be
    populated with the registrations below:

    +------------------+------------------------------+
    | Cache Directive  | Reference                    |
    +------------------+------------------------------+
    | max-age          | Section 3.2.1, Section 3.2.2 |
    | max-stale        | Section 3.2.1                |
    | min-fresh        | Section 3.2.1                |
    | must-revalidate  | Section 3.2.2                |
    | no-cache         | Section 3.2.1, Section 3.2.2 |
    | no-store         | Section 3.2.1, Section 3.2.2 |
    | no-transform     | Section 3.2.1, Section 3.2.2 |
    | only-if-cached   | Section 3.2.1                |
    | private          | Section 3.2.2                |
    | proxy-revalidate | Section 3.2.2                |
    | public           | Section 3.2.2                |
    | s-maxage         | Section 3.2.2                |
    +------------------+------------------------------+

See: <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/817>

(We still need to figure out how to get RFC 5861's extensions into the 
registry.)

Feedback appreciated, Julian

---

From: Henrik Nordström <[email-masked]>
Date: Sun, 09 May 2010 15:03:11 +0200

> (We still need to figure out how to get RFC 5861's extensions into the 

What about running the IANA registry requests as separate RFCs just for
establishing the registries? This is at large a separate activity from
HTTPbis in general and should not be blocked waiting on HTTPbis to
complete. And in addition it's for normative reasons undesired to have
HTTPbis standard document declare references to all prior documents
which should have their values included in the registry.

Or how have the process been for other registries being established late
after the field have been in use and extended?

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Sun, 09 May 2010 15:36:29 +0200

> which should have their values included in the registry.

Good point. So far we kept the registries inline.

The only *new* registry that we added before is for method names, and 
indeed we have the registrations for all non-HTTP/1.1 methods in a 
separate document 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-method-registrations-latest.html>).

In this particular case, we only have one document (RFC 5861) defining 
the extension, so the easiest way to address this would be for Mark to 
send an IANA registration request once the registry is in place.

Best regards, Julian

---

From: Henrik Nordström <[email-masked]>
Date: Sun, 09 May 2010 16:20:36 +0200

> (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-method-registrations-latest.html>).

And HTTPbis do not define any new or even change any existing methods
not already defined in earlier HTTP RFCs.

Regards
Henrik

---

From: Bil Corry <[email-masked]>
Date: Sat, 15 May 2010 08:19:28 -0700

> (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-method-registrations-latest.html>).

Shouldn't it also include the HTTP methods as well?  Or am I misunderstanding its purpose?

Small typo, MKAKTIVITY should be MKACTIVITY.

- Bil

---

From: Henrik Nordström <[email-masked]>
Date: Sat, 15 May 2010 19:49:46 +0200

> Shouldn't it also include the HTTP methods as well?  Or am I misunderstanding its purpose?

Those are currently added by the HTTPbis specifications.

But I share your view. The methods defined by 2616 should be in the
initial registry registration referencing RFC2616 so the registry can be
established without needing to wait for the bulk of the HTTPbis
specifications.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Sun, 16 May 2010 10:10:13 +0200

> Shouldn't it also include the HTTP methods as well?  Or am I misunderstanding its purpose?

Those registrations are in the base spec.

> Small typo, MKAKTIVITY should be MKACTIVITY.

Oops. Good catch.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 16 May 2010 10:12:51 +0200

> established without needing to wait for the bulk of the HTTPbis

That's also possible, but our preference was to have the registry 
procedure in the base spec.

Best regards, Julian