W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2011

Content-Disposition: conformance and error handling, was: Content-Location: conformance and error handling

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 10 Feb 2011 20:06:52 +0100
Message-ID: <4D54374C.1020802@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: httpbis Group <ietf-http-wg@w3.org>, Adam Barth <ietf@adambarth.com>
On 10.02.2011 01:32, Mark Nottingham wrote:
> Proposal:
> Add a new section 3 after the current Notational Conventions:

Sounds good.

> ---8<---
> 3. Conformance and Error Handling
> This specification defines conformance criteria for both senders (usually, HTTP origin servers) and recipients (usually, HTTP user agents) of the Content-Location header. An implementation is considered conformant if it complies with all of the requirements associated with its role.
> This specification also defines certain forms of the header field-value to be invalid, using both ABNF and prose requirements, but it does not define special handling these invalid field-values.
> Sending implementations MUST NOT generate Content-Location header fields that are invalid.

I'm not 100% sure why this is a "MUST NOT".

> Consuming implementations MAY take steps to recover a usable field-value from an invalid header field, but SHOULD NOT reject the message outright, unless this is explicitly desirable behaviour (e.g., the implementation is a validator). As such, the default handling of invalid fields is to ignore them.

It would probably good to note that an attempt to "recover" a usable 
field value risks misinterpreting the sender's intent.

> --->8---
> In section 3.1 Grammar, change:
> """Senders MUST NOT generate header field values with multiple instances of the same parameter name. Recipients SHOULD treat these values as invalid."""
> to
> """Header field values with multiple instances of the same parameter name are invalid."""


> In section 3.2, Disposition Type, change:
> """Unknown or unhandled disposition types SHOULD be handled the same way as "attachment" (see also [RFC2183], section 2.8)."""
> to
> """ ... SHOULD be handled by recipients the same way as ... """


> In section 3.3. Disposition Parameter: 'Filename', change:
> "...all but the last segment SHOULD be ignored" -->  "... SHOULD be ignored by recipients"
> In section 3.4 Disposition Parameter: Extensions
> "...unknown parameters SHOULD be ignored..." -->  "... SHOULD be ignored by recipients"

These two had been rephrased already, see 

Other than that, I have applied these changes in 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1115> because I'm 
pretty sure they aren't controversial.

Best regards, Julian
Received on Thursday, 10 February 2011 19:07:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:56 UTC