Skip to main content

Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters
draft-reschke-rfc2231-in-http-12

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters' to Proposed Standard

The IESG has approved the following document:

- 'Character Set and Language Encoding for Hypertext Transfer Protocol 
   (HTTP) Header Field Parameters '
   <draft-reschke-rfc2231-in-http-12.txt> as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Alexey Melnikov.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-reschke-rfc2231-in-http-12.txt

Ballot Text

Technical Summary

   This specification defines a simplified mechanism for encoding 
   arbitrary (e.g. non-ASCII) characters in HTTP header field parameters.

   By default, message header field parameters in Hypertext Transfer
   Protocol (HTTP) messages can not carry characters outside the ISO-
   8859-1 character set.  RFC 2231 defines an escaping mechanism for use
   in Multipurpose Internet Mail Extensions (MIME) headers.  This
   document specifies a profile of that encoding suitable for use in
   HTTP header fields.

   There are multiple HTTP header fields that already use RFC 2231
   encoding in practice (Content-Disposition) or might use it in the
   future (Link).  The purpose of this document is to provide a single
   place where the generic aspects of RFC 2231 encoding in HTTP header
   fields are defined.

Working Group Summary 

   This document is an individual submission, but has been reviewed
   on the HTTP mailing list.

Document Quality    

   This document is a clarification and simplification of an existing
   protocol specification, and reviewers indicate the simplifications
   are well-judged and match practical use in HTTP.

   Also, the draft claims that, as of January 2010, there were at least
   three independent implementations of the encoding defined in Section
   3.2: Konqueror (trunk), Mozilla Firefox, and Opera.

Personnel

   Graham Klyne is the Document Shepherd for this document.
   Alexey Melnikov is the Responsible Area Director

RFC Editor Note