Subject: Content-Location: conformance and error handling

From: Mark Nottingham <[email-masked]>
Date: Thu, 10 Feb 2011 11:32:26 +1100

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/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Feb 2011 20:06:52 +0100

> Add a new section 3 after the current Notational Conventions:

Sounds good.

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

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

> """Header field values with multiple instances of the same parameter name are invalid."""

+1

> """ ... SHOULD be handled by recipients the same way as ... """

Yes.

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

---

From: Karl Dubost <[email-masked]>
Date: Fri, 11 Feb 2011 10:52:47 -0500

Proposal:

---8<---
Consuming implementations MAY fix an invalid header field into a usable field-value. Consuming implementations SHOULD NOT reject the message.

Note: For some specific class of products, implementations might need to behave differently. (e.g., the implementation is a validator). As such, the default handling of invalid fields is to ignore them. 
---8<---

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations & Tools, Opera Software

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Feb 2011 15:27:17 +0100

> Note: For some specific class of products, implementations might need to behave differently. (e.g., the implementation is a validator). As such, the default handling of invalid fields is to ignore…

Note I went with Mark's proposal. Karl's sounds good as well; does 
anybody have a strong preference?

Best regards, Julian