Subject: I-D Action: draft-ietf-httpbis-early-hints-00.txt

From: [email-masked]
Date: Wed, 08 Feb 2017 05:26:52 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Hypertext Transfer Protocol of the IETF.

        Title           : An HTTP Status Code for Indicating Hints
        Author          : Kazuho Oku
	Filename        : draft-ietf-httpbis-early-hints-00.txt
	Pages           : 5
	Date            : 2017-02-07

Abstract:
   This memo introduces an informational status code for HTTP that can
   be used for indicating hints to help a client start making
   preparations for processing the final response.

Note to Readers

   Discussion of this draft takes place on the HTTP working group
   mailing list ([email-masked]), which is archived at
   https://lists.w3.org/Archives/Public/ietf-http-wg/ .

   Working Group information can be found at https://httpwg.github.io/ ;
   source code and issues list for this draft can be found at
   https://github.com/httpwg/http-extensions/labels/early-hints .

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-early-hints/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-httpbis-early-hints-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 9 Feb 2017 09:15:03 +0900

Hi,

I've submitted the first version of the WG draft.

The only textual change from the individual draft is the Security
Considerations.

The section now discusses what may happen when the informational
response is sent to a client that does not handle it correctly, so
that the readers can consider the effect before starting to use the
status code. OTOH the draft does not make recommendations against the
idea of using informational responses in fear of broken clients, since
it is basically the responsibility of the broken clients to fix the
issue.

My understanding is that this stance is in accordance to the
discussion we have had on this mailing list.

Please let me know what you think about the text.

-- 
Kazuho Oku