Re: agenda/charter brainstorming

Hi Julian,

On 23 Jun 2014, at 6:43 pm, Julian Reschke <julian.reschke@gmx.de> wrote:

> Hi there,
> 
> here are some ideas for what the WG could/should work on in the post-HTTP2-LC time:
> 
> 
> 1) Revise RFC 7230..5
> 
> - collect errata
> 
> - collect suggested improvements, such as those which would make the interface to the HTTP/2 spec clearer
> 
> - continue the process of checking the spec against reality, and in case of disagreements, see whether we need either to fix the spec, or fix implementations (no-transform comes to mind from recent discussions)

Yes. 

> 
> - with the current charter, we couldn't adopt new stuff - I think the revision should be allowed to pull in minor extension specs (which would need to be proposed standards as well)

Our current charter explicitly allows us to do this.

> - progress from "proposed" to "standard"

Yes. 

I have 10 minutes on my current plan for discussing HTTP/1.1 status.

> 
> 
> 2) Maintenance
> 
> - RFC 7238 ("The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)") from "experimental" to "proposed" (this wasn't a WG item)

Do you want to give an update?


> - RFC 5987 ("Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters") from "proposed" to "standard" (this wasn't a WG item) - see <http://greenbytes.de/tech/webdav/draft-reschke-rfc5987bis-latest.html>

Ditto.


> - RFC 6266 ("Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)") from "proposed" to "standard"

Can be folded into HTTP/1.1 discussion.


> 3) New stuff
> 
> - "Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding" (<http://greenbytes.de/tech/webdav/draft-reschke-http-cice-latest.html>)

15 minutes enough?


> - Analyzing the issue of range requests vs compression (we should at least write down what the problem is, so we don't have to have the whole discussion again)

Draft?

> - Another thing that comes up again and again is GET vs POST, and why there isn't a generic safe retrieval operation that takes a request body (describe the problem, document pros and cons, define an experimental new method?)

That seems like an item for 1.1 full standard. However, if we didn't explain it well enough in bis, I wonder what makes us think we can satisfy everyone now...

> - Header field syntax is something people continue to struggle with; maybe define how to use JSON in header fields to make things easier for new header field definitions

Draft?

> 
> 
> 4) Session handling (or "avoiding cookies")
> 
> ...in case we find people, energy, and implementer interest.

That sounds very speculative. Draft?


> 5) WebDAV related (if people are interested)

No. :)

> 
> - internet media types for WebDAV payloads (and maybe link relations)
> 
> - splitting out COPY/MOVE so they become more generic
> 
> - maybe even a JSON mapping
> 
> - notifications (HTTP/2 push?)

We've talked about things like this before. I'm still interested to some degree, but I wonder about the reward we'll see for the effort expended... What do others think?


> and finally...:
> 
> 6) Proxies
> 
> - describe the current situation (adopt draft-nottingham-http-proxy-problem as a WG item for publication as informational document)
> 
> - while working on the above, make decisions about which of the problems described in the document we want to work on in this WG (or alternatively find alternative venues, such as TLS or a httpproxy WG)

See separate thread.

Cheers,


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

Received on Tuesday, 24 June 2014 05:42:49 UTC