Re: repeated filename parameters, Re: Working Group Last Call: draft-ietf-httpbis-content-disp-02

[Adam Barth <[e-mail]>]

On Sat, Oct 2, 2010 at 11:24 AM, Julian Reschke <[e-mail]> wrote:
> On 02.10.2010 18:16, 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....
>
> Repeating a parameter makes the header instance invalid, this should be
> pointed out; I opened
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/244> to track this (and
> also added a test case at
> <http://greenbytes.de/tech/tc2231/#attwith2filenames>).

There seems to be a lot of things generated by the grammar that are
nonsensical.  Perhaps it would useful to explain which of those things
servers ought to actually generate.

>> ... The grammar will fail to parse a
>> large number of Content-Disposition headers user agents receive on the
>> public Internet, etc....
>
> That's not a problem. There are no specific requirements on handling
> malformed headers, just like with any other HTTP header field, unless it
> affects security.

We disagree about whether that's a problem.  We do agree that those
requirements are not contained in this document.

>> ...  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
>> ]]
>> ...
>
> I don't understand the distinction between user agent and server here.

This document describes a profile for generating the
Content-Disposition header.  The server is the one who generates the
header.  Therefore, this document defines a profile for use by
servers.

> We are defining a response header field. The producer sets it, expressing
> additional instructions on how to handle the payload. The recipient can
> follow it or ignore it. For instance, a UA on a mobile phone without
> filesystem will likely ignore the "attachment" disposition.

Indeed.  However, this document does not contain the rules for
consuming the header in sufficient detail for me to implement a user
agent.  I need to look at another document for that information.
Sadly, that document doesn't yet exist.

> For invalid header field instances, there aren't any specific requirements.
> Do you have any evidence these are required?

Such information is required to achieve interoperable implementations
of the Content-Disposition header.  It's fine if you don't want to
include that information in this document.  The document should just
be clear about its scope.

Adam