W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: Working Group Last Call: draft-ietf-httpbis-content-disp-02

From: Adam Barth <w3c@adambarth.com>
Date: Sat, 2 Oct 2010 17:23:44 -0700
Message-ID: <AANLkTi=+SgTC2QaHD3pWAYQa2f1U4yzz0eL6y0Gbfs03@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
If you'd like some (BSD licensed) examples of that a recent browser
implementation of the Content-Disposition header thinks are important,
you can look at the the test cases here (scroll down to
"content-disposition"):

http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_util_unittest.cc?revision=60555&view=markup

Here are some examples of things that look to be important but don't
seem to be covered in the document:

1) It looks like the disposition-type is actually optional, even
though it's required by the grammar.  It seems entirely possible that
the optimal generative grammar is to require the disposition-type
whereas the optimal consumption grammar is to default to some
particular disposition-type if none is provided.

2) It looks like the user agent is supposed to URL-decode the filename:

Content-Disposition: inline; filename="abc%20de.pdf"
=> abc de.pdf

Appendix C.4 seems to indicate that that this is implemented by IE and
Chrome.  From the comments in the file referenced above, it seems this
is important for the Asian market.  Both according to Appendix C.2 and
the comments in the file referenced above, it looks like the encoding
for the unescaped is supposed to be based on the current code page,
which admitted sucks.

Again, the optimal generative grammar is probably to avoid this mess.
However, it seems entirely likely the optimal consumption grammar is
to do something with percent-encoded inputs, especially if you care
about pleasing customers in the Asian market.

3) Apparently whitespace in the filename are supposed to be converted to spaces:

Content-Disposition: inline; filename="abc  <TAB><NEWLINE>de.pdf"
=> abc    de.pdf

Adam


On Sat, Oct 2, 2010 at 4:56 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 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 Sunday, 3 October 2010 00:24:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:27 GMT