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

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."""

+1

> 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 ... """

Yes.

> 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 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1096>.

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