[要約] RFC 5987は、HTTPヘッダーフィールドパラメータの文字セットと言語エンコーディングに関する規格です。その目的は、HTTPヘッダーフィールドのパラメータ値を正確に表現するための方法を提供することです。
Internet Engineering Task Force (IETF) J. Reschke
Request for Comments: 5987 greenbytes
Category: Standards Track August 2010
ISSN: 2070-1721
Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters
ハイパーテキスト転送プロトコル（HTTP）ヘッダーフィールドパラメーターの文字セットと言語エンコード
Abstract
概要
By default, message header field parameters in Hypertext Transfer Protocol (HTTP) messages cannot carry characters outside the ISO-8859-1 character set. RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC 2231.
デフォルトでは、HyperText Transfer Protocol（HTTP）メッセージのメッセージヘッダーフィールドパラメーターは、ISO-8859-1文字セットの外側に文字を運ぶことができません。RFC 2231は、多目的インターネットメールエクステンション（MIME）ヘッダーで使用するエンコードメカニズムを定義します。このドキュメントは、RFC 2231で定義されたエンコードのプロファイルと互換性のあるHTTPヘッダーフィールドでの使用に適したエンコーディングを指定します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5987.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5987で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Notational Conventions ..........................................2
3. Comparison to RFC 2231 and Definition of the Encoding ...........3
3.1. Parameter Continuations ....................................3
3.2. Parameter Value Character Set and Language Information .....3
3.2.1. Definition ..........................................3
3.2.2. Examples ............................................6
3.3. Language Specification in Encoded Words ....................6
4. Guidelines for Usage in HTTP Header Field Definitions ...........7
4.1. When to Use the Extension ..................................7
4.2. Error Handling .............................................7
5. Security Considerations .........................................8
6. Acknowledgements ................................................8
7. References ......................................................8
7.1. Normative References .......................................8
7.2. Informative References .....................................9
By default, message header field parameters in HTTP ([RFC2616]) messages cannot carry characters outside the ISO-8859-1 character set ([ISO-8859-1]). RFC 2231 ([RFC2231]) defines an encoding mechanism for use in MIME headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC 2231.
デフォルトでは、HTTP（[RFC2616]）メッセージのメッセージヘッダーフィールドパラメーターは、ISO-8859-1文字セット（[ISO-8859-1]）の外側に文字を運ぶことができません。RFC 2231（[RFC2231]）は、MIMEヘッダーで使用するエンコーディングメカニズムを定義します。このドキュメントは、RFC 2231で定義されたエンコードのプロファイルと互換性のあるHTTPヘッダーフィールドでの使用に適したエンコーディングを指定します。
Note: in the remainder of this document, RFC 2231 is only referenced for the purpose of explaining the choice of features that were adopted; they are therefore purely informative.
注：このドキュメントの残りの部分では、RFC 2231は、採用された機能の選択を説明する目的でのみ参照されます。したがって、それらは純粋に有益です。
Note: this encoding does not apply to message payloads transmitted over HTTP, such as when using the media type "multipart/form-data" ([RFC2388]).
注：このエンコードは、メディアタイプ「MultiPart/Form-Data」（[RFC2388]）を使用する場合など、HTTPを介して送信されるメッセージペイロードには適用されません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This specification uses the ABNF (Augmented Backus-Naur Form) notation defined in [RFC5234]. The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), DIGIT (decimal 0-9), HEXDIG (hexadecimal 0-9/A-F/a-f), and LWSP (linear whitespace).
この仕様では、[RFC5234]で定義されているABNF（拡張バックスノーフォーム）表記を使用します。[RFC5234]、付録B.1：アルファ（文字）、桁（10進0-9）、ヘクスディグ（ヘキサデシマ0-9/A-F/A-F）、およびLWSP（線形）で定義されているように、次のコアルールが参照によって含まれています。Whitespace）。
Note that this specification uses the term "character set" for consistency with other IETF specifications such as RFC 2277 (see [RFC2277], Section 3). A more accurate term would be "character encoding" (a mapping of code points to octet sequences).
この仕様では、「文字セット」という用語を使用して、RFC 2277（[RFC2277]、セクション3を参照）などの他のIETF仕様との一貫性を使用していることに注意してください。より正確な用語は、「文字エンコード」（オクテットシーケンスへのコードポイントのマッピング）です。
RFC 2231 defines several extensions to MIME. The sections below discuss if and how they apply to HTTP header fields.
RFC 2231は、MIMEのいくつかの拡張機能を定義しています。以下のセクションでは、HTTPヘッダーフィールドに適用するかどうか、どのように適用するかについて説明します。
In short:
要するに：
o Parameter Continuations aren't needed (Section 3.1),
o パラメーターの継続は必要ありません（セクション3.1）、
o Character Set and Language Information are useful, therefore a simple subset is specified (Section 3.2), and
o 文字セットと言語情報は有用であるため、単純なサブセットが指定されています（セクション3.2）、そして
o Language Specifications in Encoded Words aren't needed (Section 3.3).
o エンコードされた単語の言語仕様は必要ありません（セクション3.3）。
Section 3 of [RFC2231] defines a mechanism that deals with the length limitations that apply to MIME headers. These limitations do not apply to HTTP ([RFC2616], Section 19.4.7).
[RFC2231]のセクション3は、MIMEヘッダーに適用される長さの制限を扱うメカニズムを定義しています。これらの制限は、HTTP（[RFC2616]、セクション19.4.7）には適用されません。
Thus, parameter continuations are not part of the encoding defined by this specification.
したがって、パラメーターの継続は、この仕様で定義されたエンコードの一部ではありません。
Section 4 of [RFC2231] specifies how to embed language information into parameter values, and also how to encode non-ASCII characters, dealing with restrictions both in MIME and HTTP header parameters.
[RFC2231]のセクション4は、言語情報をパラメーター値に埋め込む方法と、MIMEとHTTPヘッダーパラメーターの両方で制限を扱う非ASCII文字をエンコードする方法を指定します。
However, RFC 2231 does not specify a mandatory-to-implement character set, making it hard for senders to decide which character set to use. Thus, recipients implementing this specification MUST support the character sets "ISO-8859-1" [ISO-8859-1] and "UTF-8" [RFC3629].
ただし、RFC 2231では、必須のキャラクターセットを指定していないため、送信者が使用する文字セットを決定するのが難しくなります。したがって、この仕様を実装する受信者は、文字セット「ISO-8859-1」[ISO-8859-1]および「UTF-8」[RFC3629]をサポートする必要があります。
Furthermore, RFC 2231 allows the character set information to be left out. The encoding defined by this specification does not allow that.
さらに、RFC 2231を使用すると、文字セット情報を除外できます。この仕様で定義されたエンコードはそれを許可しません。
The syntax for parameters is defined in Section 3.6 of [RFC2616] (with RFC 2616 implied LWS translated to RFC 5234 LWSP):
パラメーターの構文は、[RFC2616]のセクション3.6で定義されています（RFC 2616では、RFC 5234 LWSPに翻訳されたLWSを暗示しています）：
parameter = attribute LWSP "=" LWSP value
パラメーター=属性lwsp "=" lwsp値
attribute = token value = token / quoted-string
属性=トークン値= token / quoted-string
quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
token = <token, defined in [RFC2616], Section 2.2>
In order to include character set and language information, this specification modifies the RFC 2616 grammar to be:
文字セットと言語情報を含めるために、この仕様により、RFC 2616文法が次のように変更されます。
parameter = reg-parameter / ext-parameter
reg-parameter = parmname LWSP "=" LWSP value
reg-parameter = parmname lwsp "=" lwsp値
ext-parameter = parmname "*" LWSP "=" LWSP ext-value
parmname = 1*attr-char
ext-value = charset "'" [ language ] "'" value-chars
; like RFC 2231's <extended-initial-value>
; (see [RFC2231], Section 7)
charset = "UTF-8" / "ISO-8859-1" / mime-charset
mime-charset = 1*mime-charsetc
mime-charsetc = ALPHA / DIGIT
/ "!" / "#" / "$" / "%" / "&"
/ "+" / "-" / "^" / "_" / "`"
/ "{" / "}" / "~"
; as <mime-charset> in Section 2.3 of [RFC2978]
; except that the single quote is not included
; SHOULD be registered in the IANA charset registry
language = <Language-Tag, defined in [RFC5646], Section 2.1>
value-chars = *( pct-encoded / attr-char )
pct-encoded = "%" HEXDIG HEXDIG ; see [RFC3986], Section 2.1
pct-encoded = "％" hexdig hexdig;[RFC3986]、セクション2.1を参照してください
attr-char = ALPHA / DIGIT
/ "!" / "#" / "$" / "&" / "+" / "-" / "."
/ "^" / "_" / "`" / "|" / "~"
; token except ( "*" / "'" / "%" )
Thus, a parameter is either a regular parameter (reg-parameter), as previously defined in Section 3.6 of [RFC2616], or an extended parameter (ext-parameter).
したがって、パラメーターは、[RFC2616]のセクション3.6で以前に定義されたように、通常のパラメーター（reg-parameter）または拡張パラメーター（ext-parameter）のいずれかです。
Extended parameters are those where the left-hand side of the assignment ends with an asterisk character.
拡張されたパラメーターは、割り当ての左側がアスタリスク文字で終了するパラメーターです。
The value part of an extended parameter (ext-value) is a token that consists of three parts: the REQUIRED character set name (charset), the OPTIONAL language information (language), and a character sequence representing the actual value (value-chars), separated by single quote characters. Note that both character set names and language tags are restricted to the US-ASCII character set, and are matched case-insensitively (see [RFC2978], Section 2.3 and [RFC5646], Section 2.1.1).
拡張パラメーターの値部分（ext-value）は、必要な文字セット名（charset）、オプションの言語情報（言語）、および実際の値を表す文字シーケンスの3つの部分で構成されるトークンです。）、単一の引用文字で区切られています。文字セット名と言語タグの両方がUS-ASCII文字セットに制限されており、ケースインスセンシテーブに一致していることに注意してください（[RFC2978]、セクション2.3および[RFC5646]、セクション2.1.1を参照）。
Inside the value part, characters not contained in attr-char are encoded into an octet sequence using the specified character set. That octet sequence is then percent-encoded as specified in Section 2.1 of [RFC3986].
値部分の内部では、attr-charに含まれていない文字は、指定された文字セットを使用してオクテットシーケンスにエンコードされます。そのオクテットシーケンスは、[RFC3986]のセクション2.1で指定されているようにパーセントエンコードされます。
Producers MUST use either the "UTF-8" ([RFC3629]) or the "ISO-8859-1" ([ISO-8859-1]) character set. Extension character sets (mime-charset) are reserved for future use.
生産者は、「UTF-8」（[RFC3629]）または「ISO-8859-1」（[ISO-8859-1]）文字セットのいずれかを使用する必要があります。拡張文字セット（MIME-CHARSET）は、将来の使用のために予約されています。
Note: recipients should be prepared to handle encoding errors, such as malformed or incomplete percent escape sequences, or non-decodable octet sequences, in a robust manner. This specification does not mandate any specific behavior, for instance, the following strategies are all acceptable:
注：レシピエントは、不正行為または不完全なパーセントエスケープシーケンス、または非デコード不可能なオクテットシーケンスなどのエンコードエラーを堅牢な方法で処理するために準備する必要があります。この仕様では、特定の動作を義務付けるものではありません。たとえば、次の戦略はすべて許容されます。
* ignoring the parameter,
* パラメーターを無視する、
* stripping a non-decodable octet sequence,
* 制限不可能なオクテットシーケンスを剥ぎ取り、
* substituting a non-decodable octet sequence by a replacement character, such as the Unicode character U+FFFD (Replacement Character).
* Unicode文字u FFFD（置換文字）などの代替キャラクターに置き換えられないオクテットシーケンスを置き換えます。
Note: the RFC 2616 token production ([RFC2616], Section 2.2) differs from the production used in RFC 2231 (imported from Section 5.1 of [RFC2045]) in that curly braces ("{" and "}") are excluded. Thus, these two characters are excluded from the attr-char production as well.
注：RFC 2616トークン生産（[RFC2616]、セクション2.2）は、その巻き装置（ "{{" and "}"）で使用されるRFC 2231（[RFC2045]のセクション5.1からインポート）で使用される生産とは異なります。したがって、これらの2つのキャラクターは、アトラットチャーの生産からも除外されています。
Note: the <mime-charset> ABNF defined here differs from the one in Section 2.3 of [RFC2978] in that it does not allow the single quote character (see also RFC Errata ID 1912 [Err1912]). In practice, no character set names using that character have been registered at the time of this writing.
注：ここで定義されている<mime-charset> abnfは、単一の引用文字を許可しないという点で[RFC2978]のセクション2.3のものとは異なります（RFC Errata ID 1912 [ERR1912]も参照）。実際には、この文章の時点でそのキャラクターを使用した文字セット名は登録されていません。
Non-extended notation, using "token":
「トークン」を使用する非拡張表記：
foo: bar; title=Economy
Non-extended notation, using "quoted-string":
「引用されたストリング」を使用した非拡張表記：
foo: bar; title="US-$ rates"
Extended notation, using the Unicode character U+00A3 (POUND SIGN):
Unicode文字U 00A3（ポンドサイン）を使用して、拡張表記：
foo: bar; title*=iso-8859-1'en'%A3%20rates
Note: the Unicode pound sign character U+00A3 was encoded into the single octet A3 using the ISO-8859-1 character encoding, then percent-encoded. Also, note that the space character was encoded as %20, as it is not contained in attr-char.
注：Unicode Pound Sign Character U 00A3は、ISO-8859-1文字エンコードを使用して、単一のOctet A3にエンコードされ、その後エンコードされました。また、ATTR-CHARに含まれていないため、スペース文字は％20としてエンコードされたことに注意してください。
Extended notation, using the Unicode characters U+00A3 (POUND SIGN) and U+20AC (EURO SIGN):
Unicode文字U 00A3（ポンドサイン）およびU 20AC（ユーロ記号）を使用して、拡張表記：
foo: bar; title*=UTF-8''%c2%a3%20and%20%e2%82%ac%20rates
Note: the Unicode pound sign character U+00A3 was encoded into the octet sequence C2 A3 using the UTF-8 character encoding, then percent-encoded. Likewise, the Unicode euro sign character U+20AC was encoded into the octet sequence E2 82 AC, then percent-encoded. Also note that HEXDIG allows both lowercase and uppercase characters, so recipients must understand both, and that the language information is optional, while the character set is not.
注：Unicode Pound Sign Character U 00A3は、UTF-8文字エンコードを使用してOctetシーケンスC2 A3にエンコードされ、その後エンコードされました。同様に、Unicode Euro Sign Character U 20ACは、OctetシーケンスE2 82 ACにエンコードされ、その後エンコードされました。また、HexDigは小文字と大文字の両方の文字を許可するため、受信者は両方を理解する必要があり、言語情報はオプションであり、文字セットはそうではないことに注意してください。
Section 5 of [RFC2231] extends the encoding defined in [RFC2047] to also support language specification in encoded words. Although the HTTP/1.1 specification does refer to RFC 2047 ([RFC2616], Section 2.2), it's not clear to which header field exactly it applies, and whether it is implemented in practice (see <http://tools.ietf.org/wg/httpbis/trac/ticket/111> for details).
[RFC2231]のセクション5では、[RFC2047]で定義されたエンコードを拡張して、エンコードされた単語の言語仕様もサポートします。HTTP/1.1仕様はRFC 2047（[RFC2616]、セクション2.2）を参照していますが、どのヘッダーフィールドが正確に適用されるか、実際に実装されているかどうかは明確ではありません（<http://tools.ietf.orgを参照/wg/httpbis/trac/ticket/111>詳細については）。
Thus, this specification does not include this feature.
したがって、この仕様にはこの機能は含まれていません。
Specifications of HTTP header fields that use the extensions defined in Section 3.2 ought to clearly state that. A simple way to achieve this is to normatively reference this specification, and to include the ext-value production into the ABNF for that header field.
セクション3.2で定義されている拡張機能を使用するHTTPヘッダーフィールドの仕様は、それを明確に述べる必要があります。これを達成する簡単な方法は、この仕様を規範的に参照し、そのヘッダーフィールドのABNFにext-value生産を含めることです。
For instance:
例えば：
foo-header = "foo" LWSP ":" LWSP token ";" LWSP title-param
title-param = "title" LWSP "=" LWSP value
/ "title*" LWSP "=" LWSP ext-value
ext-value = <see RFC 5987, Section 3.2>
Note: The Parameter Value Continuation feature defined in Section 3 of [RFC2231] makes it impossible to have multiple instances of extended parameters with identical parmname components, as the processing of continuations would become ambiguous. Thus, specifications using this extension are advised to disallow this case for compatibility with RFC 2231.
注：[RFC2231]のセクション3で定義されているパラメーター値の継続機能は、継続の処理が曖昧になるため、同一のParmNameコンポーネントを持つ拡張パラメーターの複数のインスタンスを持つことを不可能にします。したがって、この拡張機能を使用した仕様は、RFC 2231との互換性についてこのケースを禁止することをお勧めします。
Section 4.2 of [RFC2277] requires that protocol elements containing human-readable text are able to carry language information. Thus, the ext-value production ought to be always used when the parameter value is of textual nature and its language is known.
[RFC2277]のセクション4.2では、人間が読めるテキストを含むプロトコル要素が言語情報を伝達できることが必要です。したがって、パラメーター値がテキストの性質であり、その言語が知られている場合、ext-Valueの生成は常に使用されるべきです。
Furthermore, the extension ought to also be used whenever the parameter value needs to carry characters not present in the US-ASCII ([USASCII]) character set (note that it would be unacceptable to define a new parameter that would be restricted to a subset of the Unicode character set).
さらに、パラメーター値がUS-ASCII（[USASCII]）文字セットに存在しない文字を運ぶ必要がある場合は、拡張機能を使用する必要があります（サブセットに制限される新しいパラメーターを定義することは受け入れられないことに注意してください。Unicode文字セットの）。
Header field specifications need to define whether multiple instances of parameters with identical parmname components are allowed, and how they should be processed. This specification suggests that a parameter using the extended syntax takes precedence. This would allow producers to use both formats without breaking recipients that do not understand the extended syntax yet.
ヘッダーフィールド仕様は、同一のParmNameコンポーネントを持つパラメーターの複数のインスタンスが許可されているかどうか、およびそれらの処理方法を定義する必要があります。この仕様は、拡張構文を使用するパラメーターが優先されることを示唆しています。これにより、プロデューサーは、まだ拡張構文を理解していない受信者を壊すことなく、両方の形式を使用できます。
Example:
例：
foo: bar; title="EURO exchange rates";
title*=utf-8''%e2%82%ac%20exchange%20rates
In this case, the sender provides an ASCII version of the title for legacy recipients, but also includes an internationalized version for recipients understanding this specification -- the latter obviously ought to prefer the new syntax over the old one.
この場合、送信者はレガシー受信者にASCIIバージョンのタイトルを提供しますが、この仕様を理解する受信者向けの国際化バージョンも含まれています。後者は明らかに古い構文よりも新しい構文を好むはずです。
Note: at the time of this writing, many implementations failed to ignore the form they do not understand, or prioritize the ASCII form although the extended syntax was present.
注：この執筆時点では、多くの実装は、拡張構文が存在しているものの、理解できないフォームを無視したり、ASCIIフォームを優先したりすることができませんでした。
The format described in this document makes it possible to transport non-ASCII characters, and thus enables character "spoofing" scenarios, in which a displayed value appears to be something other than it is.
このドキュメントで説明されている形式により、ASSASCII以外の文字を輸送できるため、表示された値が表示されるように見える文字「スプーフィング」シナリオが可能になります。
Furthermore, there are known attack scenarios relating to decoding UTF-8.
さらに、UTF-8のデコードに関する既知の攻撃シナリオがあります。
See Section 10 of [RFC3629] for more information on both topics.
両方のトピックの詳細については、[RFC3629]のセクション10を参照してください。
In addition, the extension specified in this document makes it possible to transport multiple language variants for a single parameter, and such use might allow spoofing attacks, where different language versions of the same parameter are not equivalent. Whether this attack is useful as an attack depends on the parameter specified.
さらに、このドキュメントで指定された拡張機能により、単一のパラメーターの複数の言語バリエーションを輸送できるようになり、そのような使用により、同じパラメーターの異なる言語バージョンが同等ではないスプーフィング攻撃が可能になる場合があります。この攻撃が攻撃として役立つかどうかは、指定されたパラメーターによって異なります。
Thanks to Martin Duerst and Frank Ellermann for help figuring out ABNF details, to Graham Klyne and Alexey Melnikov for general review, to Chris Newman for pointing out an RFC 2231 incompatibility, and to Benjamin Carlyle and Roar Lauritzsen for implementer's feedback.
ABNFの詳細を把握してくれたMartin DuerstとFrank Ellermannに感謝します。GrahamKlyneとAlexey Melnikovの一般的なレビュー、RFC 2231の非互換性を指摘してくれたChris Newman、およびBenjamin CarlyleとRoar Lauritzsenが実装者のフィードバックを求めています。
[ISO-8859-1] International Organization for Standardization, "Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 8859-1:1998, 1998.
[ISO-8859-1]国際標準化機関、「情報技術 - 8ビットシングルバイトコード化されたグラフィック文字セット - パート1：ラテンアルファベットNo. 1」、ISO/IEC 8859-1：1998、1998。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[RFC2978] Freed、N。およびJ. Postel、「Iana Charset登録手順」、BCP 19、RFC 2978、2000年10月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, STD 63, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、RFC 3629、STD 63、2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、RFC 3986、STD 66、2005年1月。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]フィリップス、A。、編およびM.デイビス編、「言語を識別するためのタグ」、BCP 47、RFC 5646、2009年9月。
[USASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[USASCII] American National Standards Institute、「コード化された文字セット - 情報交換のための7ビットアメリカ標準コード」、ANSI X3.4、1986。
[Err1912] RFC Errata, Errata ID 1912, RFC 2978, <http://www.rfc-editor.org>.
[ERR1912] RFC Errata、Errata ID 1912、RFC 2978、<http://www.rfc-editor.org>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K。、「MIME（多目的インターネットメールエクステンション）パート3：ASCII以外のテキスト用のメッセージヘッダー拡張機能」、RFC 2047、1996年11月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[RFC2231] Freed、N。およびK. Moore、「MIMEパラメーター値とエンコードされた単語拡張機能：文字セット、言語、継続」、RFC 2231、1997年11月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/ form-data", RFC 2388, August 1998.
[RFC2388] Masinter、L。、「フォームから値を返す：MultiPart/ Form-Data」、RFC 2388、1998年8月。
Author's Address
著者の連絡先
Julian F. Reschke greenbytes GmbH Hafenweg 16 Muenster, NW 48155 Germany
Julian F. Reschke Greenbytes GmbH Hafenweg 16 Muenster、NW 48155ドイツ
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/