- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 09 Nov 2010 09:47:00 +0100
- To: Mark Nottingham <mnot@mnot.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>, Adam Barth <ietf@adambarth.com>
On 09.11.2010 02:53, Mark Nottingham wrote: > ... >> - there's disagreement about whether we should require specific handling of invalid messages > > Actually, I think we have agreement that it should *not* be required; the current discussion is whether it's useful to specify optional handling, and where that should be done. Does anyone disagree (i.e., think it should be required as part of HTTP)? I agree it should not be required. (Note that even HTML5 allows recipients to reject non-conforming HTML) > ... >> - for C-D, the *real* problem isn't lacking interop for invalid messages, but lack of interop for *valid* messages > > There doesn't have to be just one problem. Indeed; but there are pressing problems and less pressing problems, IMHO. > ... >> I'd like to get C-D to IETF LC as soon as possible, thus get everything *else* we can resolve done in the next days. > > Given that we currently have at least two vendors (probably more, I'm just going by public information) working on implementing the draft now (at least partly triggered by us going to WGLC), and it's possible we'll get feedback from them, I'm inclined to pause for a *small* number of weeks, to see if we can learn anything else. Not sure. We will have to produce a new draft, request publication and go to AD review before we get to IETF LC anyway. What's wrong with processing additional feedback during IETF LC? > During that time, Adam can come up with a proposal for error handling, which we'll consider at the end of that period. > > Adam, you can do that either openly on the mailing list, or as a design team (i.e., work with other interested parties separately and bring a proposal forward when you think you're ready). I'd encourage you to do it openly on the list, to get constructive feedback from others as you go (thereby increasing your chances of delivering something people will accept). However, if Adam does this, I'd ask people not to question *why* it's being done. > > If it's done in time, and if we gather consensus on it, it can go into C-D as an optional appendix. If it's not ready in time, it can be published (by the WG or separately) on its own. Likewise, if the WG doesn't gain consensus on it, it can be published individually (in the IETF or elsewhere). > > Right now, I'm thinking three weeks -- November 30th (coincidentally, my birthday). This will give us time to re-publish, gain consensus (or not) and go to IETF Last Call by the end of the year. I have my doubts that we will go to IETF LC this year if we do not request publication much earlier. Also, I'm planning to revise RFC 5987 and C-D for publication as Draft Standards as soon as possible (the interop research has been done already, and sufficient implementations *are* there). Maybe it would make sense to address the error handling discussion in that revision. > Adam, is that workable for you? > >> The currently open issues are at<http://trac.tools.ietf.org/wg/httpbis/trac/query?component=content-disp>, and I believe this list contains open tickets that can be closed as duplicates (Mark?). > > I'll go through those on-list separately. Thanks. >> Also, I'm going to say that I consider the work on tests, and documenting the current UA problems in a single place was a success. We got minor problems fixed in Opera and Konqueror, Mozilla is likely to improve soon, and the Chrome nightly builds now have RFC 5987 support. > > Indeed, and I'd like to make sure that people understand -- Julian has put in an exceptional effort here, and should be recognised for driving this to conclusion. Merci. >> I believe we should continue this work with other header fields, and a quite obvious candidate would be "Content-Type", which incidentally has two related HTML WG issues (<http://www.w3.org/html/wg/tracker/issues/125> and<http://www.w3.org/html/wg/tracker/issues/126>). > > Please do file bugs as appropriate. Clarifying: with "this work" I meant doing research and filing bugs against the implementations, not the spec :-) Best regards, Julian
Received on Tuesday, 9 November 2010 08:47:44 UTC