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

Re: Comments on draft-ietf-httpbis-content-disp

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Mon, 1 Nov 2010 06:34:13 -0600
To: Adam Barth <ietf@adambarth.com>
Cc: httpbis <ietf-http-wg@w3.org>
Message-Id: <20101101063413.bf1d8102.eric@bisonsystems.net>
Adam Barth wrote:
> 
> 1) I'm aware that there are more implementors of user agents than
> browsers.  I'm not interested in being reminded of that fact.  Browser
> user agents, however, are one important group of user agents.
> 

I'm not interested in having this discussion while ignoring this fact.
Your objection seems to be that the document isn't specifically
tailored to the needs of one and only one class of user-agent.

>
> 2) I'm aware that this working group does not share my perspective on
> what constitutes a useful specification for user agent implementors.
> I'm not interested in discussing whether the level of precision I'm
> requesting is valuable.
> 

But it's perfectly reasonable to discuss whether or not the level of
precision you're after is appropriate to the scope of the document, or
should be included as part of some other document specifying browser
conformance to HTTP.

>
> 3) I'm aware that this document reflects business-as-usual in the
> IETF.  My position is that business-as-usual does not meet the needs
> of browser user agent implementors, largely because browser user agent
> implements have been effectively absent from the IETF process for the
> better part of a decade.
> 

Personally, I'm not interested in speculation as to why browser
concerns haven't been considered paramount, the fact is that they
aren't, and I cannot support any changes to the spec which turn HTTP
into a document dictating how components should behave, rather than a
docuemnt which defines messaging semantics between connectors.

> 
> This section defines a grammar for the Content-Disposition header
> field.  However, the document does not define how a user agent should
> interpret Content-Disposition header fields that do not conform to
> this grammar.  To foster interoperability between user agent
> implementations, the document should define how user agents are to
> process every sequence of bytes they could receive in a
> Content-Disposition header field.
> 

No, this would make the document noncompliant with MIME parsing rules,
for the sake of an edge case.  The document needs do no more than it
does, which is define what's standardized, not provide instructions for
handling nonstandardized syntax.  If parsing nonstandardized syntax in
a certain way is a requirement for browser interoperability, then it's
perfectly reasonable to draft some other document for that purpose.

>
> => Parameter names MUST NOT be repeated.
> 
> The document should not phrase normative requirements in the passive
> voice.  Instead, the document should make clear which protocol
> partipants are bound by each requirement.  For example, this
> requirement probably should read "servers MUST NOT generate
> Content-Disposition header field values with multiple instances of the
> same parameter name."
> 

C-D headers are generated by *senders* for consumption by *recipients*,
therefore it would be incorrect and confusing to limit the document to
stating "user-agent" or "server" because either may be sender or
recipient.  The existing wording is clear as can be, and does not need
to be made more confusing for the sake of edge-case browser concerns.

>
> => a header field value with multiple instances of the same parameter
> SHOULD be treated as invalid.
> 
> Similarly, this requirement probably should read "user agents SHOULD
> treat a header field value with multiple instances of the same
> paramater as invalid."
>

But that makes no sense, if the user-agent is the sender and the server
the recipient.

>
> Furthermore, the document should define what treating a header field
> value as invalid means.  Presumably the author intends that user
> agents ought to ignore such header field values. I'm skeptical that
> is the optimum behavior for user agents.  I would have expected user
> agents to either use the first or the last instance of each paramater.
> 

Once again, this is completely out-of-scope to what HTTP defines.  What
the document says is that the messaging semantics of multiple instances
of the same parameter is undefined between connectors.  What a
component chooses to do with that undefined header, is up to the
component and is not bound by HTTP.  Perhaps a document that's
specifically targeted at user-agent concerns in this regard, is called
for.  Changing how HTTP is drafted, to be that document, is not called
for.

> 
> http://tools.ietf.org/html/draft-ietf-httpbis-content-disp-03#appendix-C.2
> 
> As far as I can tell, this is actually the biggest interoperability
> problem with the Content-Disposition header field.  Unfortunately,
> this document does nothing to resolve this issue.  I recommend that
> this document take a position with respect to how to handle
> percent-encoded values in the filename parameter.  Specifically, I
> recommend that the document instruct user agents to decode percent
> encoded values using the user's preferred encoding.  Yes, that's ugly,
> but it's the way Content-Disposition works in the real world and the
> most likely requirement to actually be implemented by user agents.
> 

No, that's how certain browsers handle an extreme edge-case which was
never within the bounds of any spec, breaks from MIME header syntax,
and enforces multiple parsing models for HTTP headers -- which would
result in a horrific spec if such wording changes were to be adopted.
Again I point out, that the concern here is how components behave and
has nothing to do with the semantics of messaging between connectors,
therefore some other specification tailored to the needs of browsers is
far preferable than making incomprehensible changes to the protocol in
order to dictate user-agent behavior based on the Asian market concerns
of browsers.

>
> At a higher level, this document does not define the
> Content-Disposition header field in sufficient detail for user agent
> implements to implement the header field in a manner that
> interoperates with each other or with existing servers.  Specifically,
> the document does not define an algorithm for parsing the
> Content-Disposition header field value, nor does it define an
> algorithm for computing the requested file name from a parsed header
> field value.  The document does not tackle the biggest
> interoperability issue with current user agents.
> 

-1

This has already been discussed, you're simply re-stating your prior
objections without addressing any of the concerns previously stated
regarding your objections.  The only thing it doesn't do is give a
detailed parsing model which magically accounts for all possible
borking of a clearly-readable spec.  But what you suggest, is what I
consider to be going down the path of incomprehensibly-written specs
(like browser vendors have accomplished with HTML) which may only be
understood in the context of what vendors have implemented -- the
results would be *useless* for anyone else's purpose, and wouldn't
likely be followed due to the uncalled-for, incomprehensible complexity.

>
> In short, this document does not address the needs of browser user
> agent implementors.  This objection can be resolved in two ways:
> 
> 1) The document can be modified to precisely define the behavior of
> user agents.
> 
> 2) The document can be modified to clearly state that it defines a
> profile of the Content-Disposition header field for use by servers
> (with the definition of the user agent behavior to follow in some
> future document).
> 

3) browser vendors can create a document for HTTP interoperability
which addresses all these concerns about component behavior, leaving
the HTTP spec to do only what it's always done, which is define
standardized semantics for messaging between connectors *without*
dictating user-agent behavior.

I vote for 3).

-Eric
Received on Monday, 1 November 2010 12:34:49 GMT

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