Content-Location: conformance and error handling

Proposal:

Add a new section 3 after the current Notational Conventions:

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

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. 

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



--
Mark Nottingham   http://www.mnot.net/

Received on Thursday, 10 February 2011 00:32:59 UTC