- From: Mark Nottingham <mnot@mnot.net>
- Date: Sun, 3 Oct 2010 10:56:23 +1100
- To: Adam Barth <w3c@adambarth.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Adam, You raise one issue; are there others that justify adding this kind of statement to the specification? Could you give more examples? Regards, On 03/10/2010, at 3:16 AM, Adam Barth wrote: > This document appears to be insufficiently precise for user agents to > implement Content-Disposition. In particular, it does not > disambiguate what filename a user agent should use if multiple > filename attributes are present. The grammar will fail to parse a > large number of Content-Disposition headers user agents receive on the > public Internet, etc. The document says: > > [[ > Based on interoperability > testing with existing User Agents, it fully defines a profile of the > features defined in the Multipurpose Internet Mail Extensions (MIME) > variant ([RFC2183]) of the header field > ]] > > We should either add enough detail to the document to allow for user > agent implementations or clarify that this document is intended to > apply only to servers. For example, we could change the above > paragraph to the following: > > [[ > Based on interoperability testing with existing User Agents, it > defines a profile > for use by HTTP servers of the > features defined in the Multipurpose Internet Mail Extensions (MIME) > variant ([RFC2183]) of the header field > ]] > > Adam > > > On Sat, Oct 2, 2010 at 2:45 AM, Mark Nottingham <mnot@mnot.net> wrote: >> With my Chair hat on -- >> >> Julian has indicated to me that (with his editor hat on), he believes that this document is ready for Working Group Last Call: >> >> http://tools.ietf.org/html/draft-ietf-httpbis-content-disp-02 >> >> This is a three-week Last Call; it will end on Sat 23 Oct 2010 10:00:00 UTC. >> >> Please read the document carefully and raise any issues you find -- design or editorial -- on this mailing list. If you review it and don't find any issues, please tell us that too, as it's useful information. >> >> If you don't wish to make your feedback public, please send it to me directly. >> >> >> [I've copied part of Jeff Hodges' excellent WGLC announcement from Jeff Hodges for HTTP-STATE below, as I couldn't say it better myself...] >> >> WHAT IS A LAST CALL FOR? >> >> The purpose of the Working Group Last Call (WGLC) is to ensure that the working group has reached consensus on the document, believes that all the known outstanding issues have been addressed, and is ready to put the document forward for consideration as an RFC at Proposed Standard maturity level. >> >> During the last call, any comments on the documents are collected and discussed on the ietf-http-wg@w3.org mailing list. >> >> >> WHAT'S THE NEXT STEP? >> >> After the last call completes, there are three possible outcomes: >> >> 1) No changes are required and we request our ADs to put forward the document to the IESG for proposed standard status. >> >> 2) Minor changes agreed to on the list are required, and the document is revised. We then ask our ADs to put forward the revised document to the IESG for proposed standard status. >> >> 3) Major issues are raised and no consensus is reached on the list. In this case, we slink back and discuss things until consensus is reached, at which time another working group last call will be issued. >> >> Assuming we achieve outcome 1) or 2), and that the ADs agree with our assessment, the next stop for the document is with the IESG. The IESG reads it and may approve the documents (with or without changes), or send the document back to the working group to have major issues addressed. >> >> If the first outcome happens, the document is put forward for a two-week IETF-wide Last Call, and after successful completion the document is published as an RFC at proposed standard maturity level. >> >> If the second outcome happens, we go back and address the issues, putting the document forward again when we believe we're ready. >> >> Cheers, >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> >> > -- Mark Nottingham http://www.mnot.net/
Received on Saturday, 2 October 2010 23:56:55 UTC