Subject: [httpwg/http-extensions] Advice for new parameters / headers (#227)

From: HTTP issue updates <[email-masked]>
Date: Thu, 18 Aug 2016 00:47:12 -0700

As per recent discussion, this draft should advise readers about whether or not it should be used for new headers, or new parameters on existing headers.

Straw-man:

1. Change the Abstract to:

> RFC5987 defines an encoding for non-ASCII payloads in HTTP header field value parameters, based upon the encoding defined in RFC2231. This document updates that definition and describes how it should (and should not) be used.

2. Change the first paragraph of Introduction to:

> By default, header field values in HTTP messages ([RFC7230]) cannot directly carry characters outside the US-ASCII coded character set ([RFC0020]). RFC 2231 ([RFC2231]) defines an encoding mechanism for use in MIME headers. This specification documents a subset of that encoding that has been used in some HTTP header fields. Its use in new header fields, or new parameters on existing header fields, is NOT RECOMMENDED.

3. Remove section 4 contents (and subsections), replace with:

> The convention defined by this specification allows a parameter fields that have two possible encodings (ASCII without the `*`, UTF-8 with it). This causes considerable complication in the use and implementation of those parameters, since they now have to handle both, and all of the possible permutations and edge conditions implied by this (e.g., how a header field value with both ought to be handled).
> Furthermore, this encoding can only be used in parameter values, not in other parts of header field values.
> As a result, use of this encoding is only RECOMMENDED where already defined; new header fields, as well as new parameters on existing header fields, SHOULD NOT use it when non-ASCII content is anticipated. Instead, they SHOULD mandate a character encoding of UTF-8, combined with escaping of non-ASCII characters using a well-defined convention (e.g., percent encoding, as per [RFC3986).

4. Optionally, move the existing contents of section 4 into an appendix, but clarify that they're there merely for the benefit of existing uses.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/227