Subject: Revised Maastricht Agenda

From: Mark Nottingham <[email-masked]>
Date: Tue, 20 Jul 2010 09:58:03 +1000

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).

<http://www.ietf.org/proceedings/78/agenda/httpbis.txt>

HTTPbis Working Group Agenda
MONDAY, July 26, 2010
1520-1720 Afternoon Session II (0.1 London)

=================================================================

*  1 min - Scribe selection
*  4 min - Agenda bashing
* 10 min - WG status [Mark Nottingham]
* 15 min - HTTP -10 changes overview [Julian Reschke]
* 10 min - Relationship to RFC2817 [Mark Nottingham]
* 10 min - Relationship to RFC2617 [Mark Nottingham]
* 10 min - Registration policies overview [Mark Nottingham]
* 70 min - Active issues discussion
         [ list forthcoming; suggestions / requests welcome ]

=================================================================

Recommended Reading:
http://www.ietf.org/internet-drafts/
      draft-ietf-httpbis-p1-messaging-10
      draft-ietf-httpbis-p2-semantics-10
      draft-ietf-httpbis-p3-payload-10
      draft-ietf-httpbis-p4-conditional-10
      draft-ietf-httpbis-p5-range-10
      draft-ietf-httpbis-p6-cache-10
      draft-ietf-httpbis-p7-auth-10
      draft-ietf-httpbis-method-registrations-04
      draft-ietf-httpbis-security-properties-05
      draft-reschke-rfc2231-in-http-12 (approved, in RFC Editor queue)

Other background material:
      http://www.ietf.org/html.charters/httpbis-charter.html

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 21 Jul 2010 14:05:52 +0200

On 20.07.2010 01:58, Mark Nottingham wrote:
> ...

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

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 23 Jul 2010 12:03:12 +0200

On 21/07/2010, at 2:05 PM, Julian Reschke wrote:

> 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>

I've added an agenda item for this.

> 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"? :-)

I think we can cover this in the discussion of registration policies already scheduled.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 26 Jul 2010 09:30:44 +0200

Updated agenda:

*  1 min - Scribe selection
*  4 min - Agenda bashing
* 10 min - WG status [Mark Nottingham]
* 15 min - HTTP -10 changes overview [Julian Reschke]
* 10 min - Relationship to RFC2817 [Mark Nottingham]
* 10 min - Relationship to RFC2617 [Mark Nottingham]
* 10 min - Registration policies overview [Mark Nottingham]
* 10 min - Content-Disposition header [Julian Reschke]
* 50 min - Active issues discussion
         [ list forthcoming; suggestions / requests welcome ]
* 10 min - Memento [Herbert van de Sompel]

Recommended Reading:

      http://mementoweb.org/