Re: Revised Maastricht Agenda

[Julian Reschke <[e-mail]>]

On 20.07.2010 01:58, Mark Nottingham wrote:
> Suggestions still welcome; in addition to discussing HTTPbis issues, we also have historically given time at the end of the meeting to HTTP extension proposals (which aren't in-scope for the WG, but appropriate for the audience).
> ...

Two things came to mind recently:


#1 http://trac.tools.ietf.org/wg/httpbis/trac/ticket/123

Two years ago we discussed Content-Disposition, and agreed to factor it 
out. In the meantime I'm done with draft-reschke-rfc2231-in-http (which 
defines an encoding for non-ASCII characters in HTTP header field 
parameters), but there's only a skeleton of 
draft-reschke-rfc2183-in-http (*) yet. I'm trying to make progress on 
this soonish, but of course additional review (or even editors) would help.

(*) 
<http://greenbytes.de/tech/webdav/draft-reschke-rfc2183-in-http-latest.html>


#2 http://stackoverflow.com/questions/3290182/rest-http-status-codes

This question comes up from time to time. I think a good answer is to 
use "422 Unprocessable Entity" 
(<http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.11.2>). 
Frequently, people claim that this isn't "an HTTP status code" as it 
does not appear in RFC 2616, and thus, for some reason, can't be used.

Do we need to enhance the prose about status codes not defined in the 
base spec?

Alternatively, if we *wanted* to pull 422 into the base spec, what would 
be the strategy for that? RFC 4918 is a PS, RFC 2616 is a DS, so will 
(likely) HTTPbis. To include a new status code would require showing 
it's maturity - so, how do you test that? Was it ever tested for those 
codes in 2616; such as 402 "Payment Required"? :-)


Best regards, Julian