Re: obs-text character encoding and error handling; duplicate parameter names in Content-Type

["Peter Occil" <[e-mail]>]

On issue 2, I found the following in RFC6838: “It is an error for a specific parameter to be specified more than once.” So that issue is resolved.  It would be helpful to refer to that in the specification.

From: Peter Occil 
Sent: Saturday, May 25, 2013 3:30 AM
To: HTTP Working Group 
Subject: Re: obs-text character encoding and error handling; duplicate parameter names in Content-Type

On issue 1, I guess I was only reading the 22 version; in the latest version it says “Recipients SHOULD treat other octets in field content (obs-text) as opaque data”. If that’s the case, it should also say that the behavior of converting field values containing obs-text to Unicode strings (particularly parameter values in Content-Type) is undefined.

Issue 2 still stands.

From: Peter Occil 
Sent: Saturday, May 25, 2013 3:14 AM
To: HTTP Working Group 
Subject: obs-text character encoding and error handling; duplicate parameter names in Content-Type

obs-text character encoding and error handling; duplicate parameter names in Content-Type

I have two issues.

1. obs-text character encoding and error handling

What is the character encoding used when a header field value contains obs-text, and particularly
parameter values in Content-Type?  Is it ISO-8859-1, UTF-8, or something else?  Or is the encoding
  undefined?  Error handling rules for obs-text, unlike for obs-fold, are also absent.

2. Duplicate parameter names in Content-Type

Suppose that the following Content-Type is received:

    text/html; charset=iso-8859-1; charset=utf-8
What is the resulting value of the charset parameter?  Is it iso-8859-1, utf-8, an error, or undefined?
(This issue also applies to Content-Disposition, Accept, and other header fields that use parameters.)
--Peter