RFC3864 日本語訳
3864 Registration Procedures for Message Header Fields. G. Klyne, M.Nottingham, J. Mogul. September 2004. (Format: TXT=36231 bytes) (Also BCP0090) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Klyne
Request for Comments: 3864 Nine by Nine
BCP: 90 M. Nottingham
Category: Best Current Practice BEA
J. Mogul
HP Labs
September 2004
Klyneがコメントのために要求するワーキンググループG.をネットワークでつないでください: 3864 9時9分前BCP: 90M.ノッティンガムカテゴリ: 最も良い現在の練習のBEA J.要人hp研究室2004年9月
Registration Procedures for Message Header Fields
メッセージヘッダーフィールドのための登録手順
Status of this Memo
このMemoの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications.
この仕様はインターネット・メール、HTTP、Netnews、および他のアプリケーションで使用されるメッセージヘッダーフィールドのために登録手順を定義します。
Klyne, et al. Best Current Practice [Page 1] RFC 3864 Header Field Registration September 2004
Klyne、他 最も良い現在の練習[1ページ]RFC3864ヘッダーフィールド登録2004年9月
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Structure of this Document . . . . . . . . . . . . . . . 3
1.2. Document Terminology and Conventions . . . . . . . . . . 4
2. Message Header Fields. . . . . . . . . . . . . . . . . . . . . 4
2.1. Permanent and Provisional Header Fields. . . . . . . . . 4
2.2. Definitions of Message Header Fields . . . . . . . . . . 5
2.2.1. Application-specific Message Header Fields. . . . 5
2.2.2. MIME Header Fields. . . . . . . . . . . . . . . . 6
3. Registry Usage Requirements. . . . . . . . . . . . . . . . . . 6
4. Registration Procedure . . . . . . . . . . . . . . . . . . . . 6
4.1. Header Field Specification . . . . . . . . . . . . . . . 7
4.2. Registration Templates . . . . . . . . . . . . . . . . . 7
4.2.1. Permanent Message Header Field Registration
Template. . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Provisional Message Header Field Submission
Template. . . . . . . . . . . . . . . . . . . . . 8
4.3. Submission of Registration . . . . . . . . . . . . . . . 10
4.4. Objections to Registration . . . . . . . . . . . . . . . 10
4.5. Change Control . . . . . . . . . . . . . . . . . . . . . 11
4.6. Comments on Header Definitions . . . . . . . . . . . . . 12
4.7. Location of Header Field Registry. . . . . . . . . . . . 12
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 このDocument. . . . . . . . . . . . . . . 3 1.2の構造。 用語とコンベンション. . . . . . . . . . 4 2を記録してください。 メッセージヘッダーフィールド。 . . . . . . . . . . . . . . . . . . . . 4 2.1. 永久的で暫定的なヘッダーフィールド。 . . . . . . . . 4 2.2. メッセージヘッダーフィールド. . . . . . . . . . 5 2.2.1の定義。 アプリケーション特有のメッセージヘッダーフィールド。 . . . 5 2.2.2. ヘッダーフィールドをまねてください。 . . . . . . . . . . . . . . . 6 3. 登録用法要件。 . . . . . . . . . . . . . . . . . 6 4. 登録手順. . . . . . . . . . . . . . . . . . . . 6 4.1。 ヘッダーフィールド仕様. . . . . . . . . . . . . . . 7 4.2。 登録テンプレート. . . . . . . . . . . . . . . . . 7 4.2.1。 永久的なメッセージヘッダーフィールド登録テンプレート。 . . . . . . . . . . . . . . . . . . . . 7 4.2.2. 暫定的なメッセージヘッダーフィールド服従テンプレート。 . . . . . . . . . . . . . . . . . . . . 8 4.3. 登録. . . . . . . . . . . . . . . 10 4.4の提案。 登録. . . . . . . . . . . . . . . 10 4.5への反論。 コントロール. . . . . . . . . . . . . . . . . . . . . 11 4.6を変えてください。 ヘッダー定義. . . . . . . . . . . . . 12 4.7のコメント。 ヘッダーフィールド登録の位置。 . . . . . . . . . . . 12 5. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 12 6. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 12 7. 承認. . . . . . . . . . . . . . . . . . . . . . . 13 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1。 引用規格. . . . . . . . . . . . . . . . . . 13 8.2。 有益な参照. . . . . . . . . . . . . . . . . 13 9。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 16 10。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 17
1. Introduction
1. 序論
This specification defines registration procedures for the message header field names used by Internet mail, HTTP, newsgroup feeds and other Internet applications. It is not intended to be a replacement for protocol-specific registries, such as the SIP registry [30].
この仕様はインターネット・メール、HTTP、ニュースグループ給送、および他のインターネットアプリケーションで使用されるメッセージヘッダーフィールド名のために登録手順を定義します。 それはSIP登録[30]などのプロトコル特有の登録との交換であることを意図しません。
Benefits of a central registry for message header field names include:
メッセージヘッダーフィールド名のための中央の登録の利益は:
o providing a single point of reference for standardized and
widely-used header field names;
o 標準化されて広く使用されたヘッダーの1ポイントの参照を提供して、名前をさばいてください。
o providing a central point of discovery for established header
fields, and easy location of their defining documents;
o 発見の主要なポイントを確立したヘッダーフィールドに提供して、それらの定義文書の簡単な位置。
Klyne, et al. Best Current Practice [Page 2] RFC 3864 Header Field Registration September 2004
Klyne、他 最も良い現在の練習[2ページ]RFC3864ヘッダーフィールド登録2004年9月
o discouraging multiple definitions of a header field name for
different purposes;
o ヘッダーの複数の定義に水をさしていて、異なる役割のために名前をさばいてください。
o helping those proposing new header fields discern established
trends and conventions, and avoid names that might be confused
with existing ones;
o それらが提案するのを助けて、新しいヘッダーフィールドは、確立した傾向とコンベンションについて明察して、既存のものに混乱するかもしれない名前を避けます。
o encouraging convergence of header field name usage across multiple
applications and protocols.
o 複数のアプリケーションとプロトコルの向こう側にヘッダーフィールド名前用法の集合を奨励します。
The primary specification for Internet message header fields in email is the Internet mail message format specification, RFC 2822 [4]. HTTP/1.0 [10] and HTTP/1.1 [24] define message header fields (respectively, the HTTP-header and message-header protocol elements) for use with HTTP. RFC 1036 [5] defines message header elements for use with Netnews feeds. These specifications also define a number of header fields, and provide for extension through the use of new field-names.
メールによるインターネットメッセージヘッダーフィールドのための第一の仕様はインターネット・メールメッセージ書式仕様、RFC2822[4]です。 HTTP/1.0[10]とHTTP/1.1[24]はHTTPとの使用のためにメッセージヘッダーフィールドを定義します(それぞれ、HTTPヘッダとメッセージヘッダーは要素について議定書の中で述べます)。 RFC1036[5]は使用のためにNetnews給送でメッセージヘッダー要素を定義します。 これらの仕様は、また、多くのヘッダーフィールドを定義して、新しいフィールド名の使用で拡大に備えます。
There are many other Internet standards track documents that define additional header fields for use within the same namespaces, notably MIME [11] and related specifications. Other Internet applications that use MIME, such as SIP (RFC 3261 [30]) may also use many of the same header fields (but note that IANA maintains a separate registry of header fields used with SIP).
同じ名前空間、著しくMIME[11]、および関連する仕様の中に使用のための追加ヘッダーフィールドを定義する他の多くのインターネット標準化過程ドキュメントがあります。 それはMIMEを使用します、SIPなどのように。他のインターネットアプリケーション、(また、RFC3261[30])は同じヘッダーフィールドの多くを使用するかもしれません(IANAがSIPと共に使用されるヘッダーフィールドの別々の登録を維持することに注意してください)。
Although in principle each application defines its own set of valid header fields, exchange of messages between applications (e.g., mail to Netnews gateways), common use of MIME encapsulation, and the possibility of common processing for various message types (e.g., a common message archive and retrieval facility) makes it desirable to have a common point of reference for standardized and proposed header fields. Listing header fields together reduces the chance of an accidental collision, and helps implementers find relevant information. The message header field registries defined here serve that purpose.
原則として各アプリケーションはそれ自身の有効なヘッダーフィールドのセットを定義しますが、様々なメッセージタイプ(例えば、一般的なメッセージアーカイブと検索施設)のためのアプリケーション(例えば、Netnewsゲートウェイへのメール)と、MIMEカプセル化の一般の使用と、一般的な処理の可能性の間のメッセージの交換で、標準化されて提案されたヘッダーフィールドの参照の一般的なポイントを持っているのは望ましくなります。 ヘッダーフィールドを一緒に記載するのは、偶然の衝突の可能性を小さくして、implementersが関連情報を見つけるのを助けます。 ここで定義されたメッセージヘッダーフィールド登録はその目的に役立ちます。
1.1. Structure of this Document
1.1. このDocumentの構造
Section 2 discusses the purpose of this specification, and indicates some sources of information about defined message header fields.
セクション2は、この仕様の目的について論じて、定義されたメッセージヘッダーフィールドに関して、ある情報筋を示します。
Section 4 defines the message header field name repositories, and sets out requirements and procedures for creating entries in them.
セクション4は、倉庫というメッセージヘッダーフィールド名を定義して、それらでエントリーを作成するための要件と手順を出します。
Klyne, et al. Best Current Practice [Page 3] RFC 3864 Header Field Registration September 2004
Klyne、他 最も良い現在の練習[3ページ]RFC3864ヘッダーフィールド登録2004年9月
1.2. Document Terminology and Conventions
1.2. ドキュメント用語とコンベンション
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 BCP 14, RFC 2119 [2].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[2])で説明されるように本書では解釈されることであるべきです。
2. Message Header Fields
2. メッセージヘッダーフィールド
2.1. Permanent and Provisional Header Fields
2.1. 永久的で暫定的なヘッダーフィールド
Many message header fields are defined in standards-track documents, which means they have been subjected to a process of community review and achieved consensus that they provide a useful and well-founded capability, or represent a widespread use of which developers should be aware. Some are defined for experimental use, typically indicating consensus regarding their purpose but not necessarily concerning their technical details. Many others have been defined and adopted ad-hoc to address a locally occurring requirement; some of these have found widespread use.
多くのメッセージヘッダーフィールドが共同体レビューの過程にそれらをかけてあることを意味して、彼らが役に立ってゆるぎない能力を提供するか、または普及使用を表すというそれの開発者の達成されたコンセンサスが意識しているべきである標準化過程文書で定義されます。 何かが、それらの技術的詳細に関してそれらの目的に関するコンセンサスを通常示して、実験用のために定義されますが、必ず定義されるというわけではありません。 多くの他のものが、局所的に起こっている要件を記述するために臨時に定義されて、採用されました。 これらの或るものは普及使用を見つけました。
The catalogues defined here are intended to cater for all of these header fields, while maintaining a clear distinction and status for those which have community consensus. To this end, two repositories are defined:
共同体コンセンサスを持っているもののために明らかな区別と状態を維持している間、ここで定義されたカタログがこれらのヘッダーフィールドのすべてを満たすことを意図します。 このために、2つの倉庫が定義されます:
o A Permanent Message Header Field Registry, intended for headers
defined in IETF standards-track documents, those that have
achieved a comparable level of community review, or are generally
recognized to be in widespread use. The assignment policy for
such registration is "Specification Required", as defined by RFC
2434 [3], where the specification must be published in an RFC
(standards-track, experimental, informational or historic), or as
an "Open Standard" in the sense of RFC 2026, section 7 [1].
o Permanent Message Header Field Registry、一般に、IETF標準化過程文書で定義されたヘッダーのために意図していて、匹敵するレベルの共同体を達成したものは、論評するか、または普及使用にはあるように認識されます。 そのような登録のための課題方針は「仕様が必要です」です、RFC(実験的であるか、情報的、または、歴史的な標準化過程)か、RFC2026の意味における「オープンスタンダード」として仕様を発表しなければならないRFC2434[3]で定義されるように、セクション7[1]。
o A Provisional Message Header Field Repository, intended for any
header field proposed by any developer, without making any claim
about its usefulness or the quality of its definition. The policy
for recording these is "Private Use", per RFC 2434 [3].
o 有用性に関するどんなクレームか定義の品質も作らないでどんな開発者によっても提案されたどんなヘッダーフィールドのためにも意図するProvisional Message Header Field Repository。 RFC2434[3]あたりこれらを記録するための方針は「私用」です。
Neither repository tracks the syntax, semantics or type of field- values. Only the field-names, applicable protocols and status are registered; all other details are specified in the defining documents referenced by repository entries. Significant updates to such references (e.g., the replacement of a Proposed Standard RFC by a Draft Standard RFC, but not necessarily the revision of an Internet- draft) SHOULD be accompanied by updates to the corresponding repository entries.
どちらの倉庫も分野値の構文、意味論またはタイプを追跡しません。 フィールド名、適切なプロトコル、および状態だけが登録されています。 他のすべての詳細が倉庫エントリーで参照をつけられる定義文書で指定されます。 そのようなものへの重要なアップデートはSHOULDに参照をつけます(例えば、必ずインターネット草稿の改正ではなく、Draft Standard RFCによるProposed Standard RFCの交換)。アップデートで、対応する倉庫エントリーに伴われます。
Klyne, et al. Best Current Practice [Page 4] RFC 3864 Header Field Registration September 2004
Klyne、他 最も良い現在の練習[4ページ]RFC3864ヘッダーフィールド登録2004年9月
2.2. Definitions of Message Header Fields
2.2. メッセージヘッダーフィールドの定義
RFC 2822 [4] defines a general syntax for message headers, and also defines a number of fields for use with Internet mail. HTTP/1.0 [10] and HTTP/1.1 [24] do likewise for HTTP. Additional field names are defined in a variety of standards-track RFC documents, including: RFC 1036 [5], RFC 1496 [6], RFC 1505 [7], RFC 1864 [9], RFC 2156 [14], RFC 2183 [15], RFC 2045 [11], RFC 2046 [12], RFC 2557 [23], RFC 2227 [16], RFC 2231 [17], RFC 2298 [18], RFC 2369 [19], RFC 2421 [21], RFC 2518 [22], RFC 2617 [25], RFC 2821 [26], RFC 2912 [27], RFC 2919 [28], RFC 2965 [29], and RFC 3282 [31].
RFC2822[4]はメッセージヘッダーのために一般的な構文を定義して、また、インターネット・メールとの使用のために多くの分野を定義します。 HTTP/1.0[10]とHTTP/1.1[24]は同様にHTTPのためにします。 追加フィールド名はさまざまな標準化過程RFCドキュメント、包含で定義されます: RFC1036[5]、RFC1496[6]、RFC1505[7]、RFC1864[9]、RFC2156[14]、RFC2183[15]、RFC2045[11]、RFC2046[12]、RFC2557[23]、RFC2227[16]、RFC2231[17]、RFC2298[18]、RFC2369[19]、RFC2421[21]、RFC2518[22]、RFC2617[25]、RFC2821[26]、RFC2912[27]、RFC2919[28]、RFC2965[29]、およびRFC3282[31]。
2.2.1. Application-specific Message Header Fields
2.2.1. アプリケーション特有のメッセージヘッダーフィールド
Internet applications that use similar message headers include Internet mail [26] [4], NNTP newsgroup feeds [5], HTTP web access [24] and any other that uses MIME [11] encapsulation of message content.
同様のメッセージヘッダーを使用するインターネットアプリケーションがインターネット・メール[26][4]、NNTPニュースグループ給送[5]、HTTPウェブアクセス[24]、およびメッセージ内容のMIME[11]カプセル化を使用するいかなる他のも含んでいます。
In some cases (notably HTTP [24]), the header syntax and usage is redefined for the specific application. This registration is concerned only with the allocation and specification of field names, and not with the details of header implementation in specific protocols.
いくつかの場合、(著しくHTTP[24])、ヘッダー構文、および用法は特定のアプリケーションのために再定義されます。 この登録は特定のプロトコルのヘッダー実現の詳細ではなく、フィールド名の配分と仕様だけに関係があります。
In some cases, the same field name may be specified differently (by different documents) for use with different application protocols; e.g., The Date: header field used with HTTP has a different syntax than the Date: used with Internet mail. In other cases, a field name may have a common specification across multiple protocols (ignoring protocol-specific lexical and character set conventions); e.g., this is generally the case for MIME header fields with names of the form 'Content-*'.
いくつかの場合、同じフィールド名は異なったアプリケーション・プロトコルで使用に異なっ(異なったドキュメントで)て指定されるかもしれません。 例えば、日付: HTTPと共に使用されるヘッダーフィールドは日付:と異なった構文を持っています。 インターネット・メールで、使用されています。 他の場合では、フィールド名は複数のプロトコルの向こう側に一般的な仕様を持っているかもしれません(語彙と文字の組のプロトコル特有のコンベンションを無視して)。 一般に、例えば、これはフォームの名前が'満足している*'であることでのMIMEヘッダーフィールドのためのそうです。
Thus, we need to accommodate application-specific fields, while wishing to recognize and promote (where appropriate) commonality of other fields across multiple applications. Common repositories are used for all applications, and each registered header field specifies the application protocol for which the corresponding definition applies. A given field name may have multiple registry entries for different protocols; in the Permanent Message Header Field registry, a given header field name may be registered only once for any given protocol. (In some cases, the registration may reference several defining documents.)
したがって、複数のアプリケーションの向こう側に他の分野の共通点を認識して、促進することを(適切であるところ)願う間、私たちは、アプリケーション特有の野原を収容する必要があります。 一般的な倉庫はすべてのアプリケーションに使用されます、そして、それぞれの登録されたヘッダーフィールドは対応する定義が申し込まれるアプリケーション・プロトコルを指定します。 与えられたフィールド名には、異なったプロトコルのための複数の登録エントリーがあるかもしれません。 Permanent Message Header Field登録では、与えられたヘッダーフィールド名はどんな与えられたプロトコルのためにも一度だけ登録されるかもしれません。 (いくつかの場合、登録は参照いくつかの定義文書がそうするかもしれません)
Klyne, et al. Best Current Practice [Page 5] RFC 3864 Header Field Registration September 2004
Klyne、他 最も良い現在の練習[5ページ]RFC3864ヘッダーフィールド登録2004年9月
2.2.2. MIME Header Fields
2.2.2. MIMEヘッダーフィールド
Some header fields with names of the form Content-* are associated with the MIME data object encapsulation and labelling framework. These header fields can meaningfully be applied to a data object separately from the protocol used to carry it.
フォームContent-*の名前があるいくつかのヘッダーフィールドが、MIMEデータ・オブジェクトカプセル化に関連していて枠組みをラベルします。 別々にこれらのヘッダーフィールドをそれを運ぶのに使用されるプロトコルからデータ・オブジェクトに意味深長に適用できます。
MIME is used with email messages and other protocols that specify a MIME-based data object format. MIME header fields used with such protocols are defined in the registry with the protocol "mime", and as such are presumed to be usable in conjunction with any protocol that conveys MIME objects.
MIMEはMIMEベースのデータ・オブジェクト形式を指定するメールメッセージと他のプロトコルと共に使用されます。 そのようなプロトコルと共に使用されるMIMEヘッダーフィールドは、登録でプロトコル「パントマイム」で定義されて、そういうものとしてあえてMIME物を伝えるどんなプロトコルに関連して使用可能です。
Other protocols do not convey MIME objects, but define a number of header fields with similar names and functions to MIME. Notably, HTTP defines a number of entity header fields that serve a purpose in HTTP similar to MIME header fields in email. Some of these header fields have the same names and similar functions to their MIME counterparts (though there are some variations). Such header fields must be registered separately for any non-MIME-carrying protocol with which they may be used.
他のプロトコルはMIME物を伝えませんが、同様の名前と機能で多くのヘッダーフィールドをMIMEと定義してください。 著しく、HTTPはメールでMIMEヘッダーフィールドと同様のHTTPにおける目的に役立つ多くの実体ヘッダーフィールドを定義します。 これらのヘッダーフィールドのいくつかが同じ名前と同様の機能を彼らのMIME対応者に持っています(いくつかの変化がありますが)。 それらが使用されるかもしれないどんなMIMEを運ばないプロトコルのためにも別々にそのようなヘッダーフィールドを示さなければなりません。
It is poor practice to reuse a header field name from another protocol simply because the fields have similar (even "very similar") meanings. Protocols should share header field names only when their meanings are identical in all foreseeable circumstances. In particular, new header field names of the form Content-* should not be defined for non-MIME-carrying protocols unless their specification is exactly the same as in MIME.
単に分野には同様(「非常に同様」のさえ)の意味があるので、別のプロトコルからヘッダーフィールド名を再利用するのが、お粗末な商売です。 それらの意味はすべての予見できる事情が同じであるときにだけ、プロトコルがヘッダーフィールド名を共有するべきです。 それらの仕様がまさにMIMEと同じでない場合、特に、MIMEを運ばないプロトコルのためにフォームContent-*の新しいヘッダーフィールド名を定義するべきではありません。
3. Registry Usage Requirements
3. 登録用法要件
RFCs defining new header fields for Internet mail, HTTP, or MIME MUST include appropriate header registration template(s) (as given in Section 4.2) for all headers defined in the document in their IANA considerations section. Use of the header registry MAY be mandated by other protocol specifications, however, in the absence of such a mandate use of the registry is not required.
インターネット・メール、HTTP、またはMIMEのための新しいヘッダーフィールドを定義するRFCsは彼らのIANA問題部のドキュメントで定義されたすべてのヘッダーのために適切なヘッダー登録テンプレートを含まなければなりません(セクション4.2で与えるように)。 ヘッダー登録の使用は他のプロトコル仕様で強制されるかもしれなくて、そのようなものが不在のときしかしながら、登録の命令使用は必要ではありません。
4. Registration Procedure
4. 登録手順
The procedure for registering a message header field is:
メッセージヘッダーフィールドを示すための手順は以下の通りです。
1. Construct a header field specification
1. ヘッダーフィールド仕様を構成してください。
2. Prepare a registration template
2. 登録テンプレートを用意してください。
3. Submit the registration template
3. 登録テンプレートを提出してください。
Klyne, et al. Best Current Practice [Page 6] RFC 3864 Header Field Registration September 2004
Klyne、他 最も良い現在の練習[6ページ]RFC3864ヘッダーフィールド登録2004年9月
4.1. Header Field Specification
4.1. ヘッダーフィールド仕様
Registration of a new message header field starts with construction of a proposal that describes the syntax, semantics and intended use of the field. For entries in the Permanent Message Header Field Registry, this proposal MUST be published as an RFC, or as an Open Standard in the sense described by RFC 2026, section 7 [1].
新しいメッセージヘッダーフィールドの登録は分野の構文について説明する提案の工事、意味論、および意図している使用から始まります。 Permanent Message Header Field Registryのエントリーにおいて、RFCとして、または、RFC2026(セクション7[1])によって説明された意味におけるオープンStandardとしてこの提案を発行しなければなりません。
A registered field name SHOULD conform at least to the syntax defined by RFC 2822 [4], section 3.6.8.
SHOULDが少なくともRFC2822[4]、セクション3.6.8によって定義された構文に従わせる登録されたフィールド名。
Further, the "." character is reserved to indicate a naming sub- structure and MUST NOT be included in any registered field name. Currently, no specific sub-structure is defined; if used, any such structure MUST be defined by a standards track RFC document.
「さらに、」 . 」 キャラクタを、命名サブ構造を示すために予約して、どんな登録されたフィールド名にも含んではいけません。 現在、どんな特定の基礎も定義されません。 使用されるなら、標準化過程RFCドキュメントでどんなそのような構造も定義しなければなりません。
Header field names may sometimes be used in URIs, URNs and/or XML. To comply with the syntactic constraints of these forms, it is recommended that characters in a registered field name are restricted to those that can be used without escaping in a URI [20] or URN [13], and that are also legal in XML [32] element names.
ヘッダーフィールド名はURI、URNs、そして/または、XMLで時々使用されるかもしれません。 これらの形式の構文の規制に従うために、登録されたフィールド名のキャラクタがURI[20]かURN[13]で逃げないで使用できる、またXML[32]要素名で法的なものに制限されるのは、お勧めです。
Thus, for maximum flexibility, header field names SHOULD further be
restricted to just letters, digits, hyphen ('-') and underscore ('_')
characters, with the first character being a letter or underscore.
したがって、ヘッダーフィールド名SHOULDは最大の柔軟性のために、さらにまさしく手紙、ケタに制限されて、('--')をハイフンで結んで、手紙である最初のキャラクタでの('_')キャラクタか強調を強調します。
4.2. Registration Templates
4.2. 登録テンプレート
The registration template for a message header field may be contained in the defining document, or prepared separately.
メッセージヘッダーフィールドのための登録テンプレートは、別々に定義文書で含まれる、または準備されているかもしれません。
4.2.1. Permanent Message Header Field Registration Template
4.2.1. 永久的なメッセージヘッダーフィールド登録テンプレート
A header registered in the Permanent Message Header Field Registry MUST be published as an RFC or as an "Open Standard" in the sense described by RFC 2026, section 7 [1], and MUST have a name which is unique among all the registered permanent field names that may be used with the same application protocol.
Permanent Message Header Field Registryに登録されたヘッダーは、RFCとして、または、RFC2026、セクション7[1]によって説明された意味における「オープンスタンダード」として発表しなければならなくて、同じアプリケーション・プロトコルと共に使用されるかもしれないすべての登録された永久的なフィールド名の中でユニークな名前を持たなければなりません。
The registration template has the following form.
登録テンプレートで、以下は形成されます。
PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE:
永久的なメッセージヘッダーフィールド登録テンプレート:
Header field name:
The name requested for the new header field. This MUST conform to
the header field specification details noted in Section 4.1.
ヘッダーフィールド名: 名前は新しさのためにヘッダーフィールドを要求しました。 これはセクション4.1に述べられたヘッダーフィールド仕様の詳細に従わなければなりません。
Klyne, et al. Best Current Practice [Page 7] RFC 3864 Header Field Registration September 2004
Klyne、他 最も良い現在の練習[7ページ]RFC3864ヘッダーフィールド登録2004年9月
Applicable protocol:
Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616),
"netnews" (RFC 1036), or cite any other standards-track RFC
defining the protocol with which the header is intended to be
used.
適切なプロトコル: 「メール」(RFC2822)、「パントマイム」(RFC2045)、"http"(RFC2616)「ネットニュース」(RFC1036)を指定するか、またはヘッダーが使用されることを意図するプロトコルを定義するいかなる他の標準化過程RFCも引用してください。
Status:
Specify "standard", "experimental", "informational", "historic",
"obsoleted", or some other appropriate value according to the type
and status of the primary document in which it is defined. For
non-IETF specifications, those formally approved by other
standards bodies should be labelled as "standard"; others may be
"informational" or "deprecated" depending on the reason for
registration.
状態: それが定義される第一のドキュメントのタイプと状態に従って、「実験的で」、「情報」の、そして、「歴史的で」、「時代遅れにされた」「規格」、またはある他の適切な値を指定してください。 非IETF仕様に関しては、他の標準化団体によって正式に承認されたものは「標準である」とラベルされるべきです。 登録の理由によって、他のものは、「情報」か「推奨しないかもしれません」。
Author/Change controller:
For Internet standards-track, state "IETF". For other open
standards, give the name of the publishing body (e.g., ANSI, ISO,
ITU, W3C, etc.). For other specifications, give the name, email
address, and organization name of the primary specification
author. A postal address, home page URI, telephone and fax
numbers may also be included.
コントローラを書くか、または変えてください: インターネット標準化過程に関しては、"IETF"を述べてください。 他のオープンスタンダードのための、出版本文(例えば、ANSI、ISO、ITU、W3Cなど)の名前をお願いします。 第一の仕様作者の名前、Eメールアドレス、および他の仕様に関しては、組織名をお願いします。 また、郵便の宛先、ホームページURI、電話、およびファックス番号は含まれるかもしれません。
Specification document(s):
Reference to document that specifies the header for use with the
indicated protocol, preferably including a URI that can be used to
retrieve a copy of the document. An indication of the relevant
sections MAY also be included, but is not required.
仕様ドキュメント: それを記録する参照は示されたプロトコルで使用にヘッダーを指定します、望ましくは、ドキュメントのコピーを検索するのに使用できるURIを含んでいて。 関連セクションのしるしは、また、含まれるかもしれませんが、必要ではありません。
Related information:
Optionally, citations to additional documents containing further
relevant information. (This part of the registry may also be used
for IESG comments.) Where a primary specification refers to
another document for substantial technical detail, the referenced
document is usefully mentioned here.
関連情報: 任意に、追加ドキュメント含有への引用は関連情報を促進します。 (また、登録のこの部分はIESGコメントに使用されるかもしれません。) 第一の仕様がかなりの技術的な詳細のための別のドキュメントを参照するところでは、参照をつけられたドキュメントは有効にここに参照されます。
4.2.2. Provisional Message Header Field Submission Template
4.2.2. 暫定的なメッセージヘッダーフィールド服従テンプレート
Registration as a Provisional Message Header Field does not imply any kind of endorsement by the IETF, IANA or any other body.
Provisional Message Header Fieldとしての登録はIETF、IANAまたはいかなる他のボディーでもどんな種類の裏書きも含意しません。
The main requirements for a header field to be included in the provisional repository are that it MUST have a citable specification, and there MUST NOT be a corresponding entry (with same field name and protocol) in the permanent header field registry.
ヘッダーフィールドが暫定的な倉庫に含まれているという主な要件はそれにはcitable仕様がなければならなくて、対応するエントリー(同じフィールド名とプロトコルがある)が永久的なヘッダーフィールド登録にあるはずがないということです。
Klyne, et al. Best Current Practice [Page 8] RFC 3864 Header Field Registration September 2004
Klyne、他 最も良い現在の練習[8ページ]RFC3864ヘッダーフィールド登録2004年9月
The specification SHOULD indicate an email address for sending technical comments and discussion of the proposed message header.
仕様SHOULDは送付の技術的なコメントと提案されたメッセージヘッダーの議論のためのEメールアドレスを示します。
The submission template has the following form.
服従テンプレートで、以下は形成されます。
PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE:
暫定的なメッセージヘッダーフィールド服従テンプレート:
Header field name:
The name proposed for the new header field. This SHOULD conform
to the field name specification details noted in Section 4.1.
ヘッダーフィールド名: 名前は新しいヘッダーフィールドのために提案しました。 このSHOULDはセクション4.1に述べられたフィールド名仕様の詳細に従います。
Applicable protocol:
Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616),
"netnews" (RFC 1036), or cite any other standards-track RFC
defining the protocol with which the header is intended to be
used.
適切なプロトコル: 「メール」(RFC2822)、「パントマイム」(RFC2045)、"http"(RFC2616)「ネットニュース」(RFC1036)を指定するか、またはヘッダーが使用されることを意図するプロトコルを定義するいかなる他の標準化過程RFCも引用してください。
Status:
Specify: "provisional". This will be updated if and when the
header registration is subsequently moved to the permanent
registry.
状態: 指定します: 「暫定的です」。 次にヘッダー登録を永久的な登録に動かすと、これをアップデートするでしょう。
Author/Change controller:
The name, email address, and organization name of the submission
author, who may authorize changes to or retraction of the
repository entry. A postal address, home page URI, telephone and
fax numbers may also be included.
If the proposal comes from a standards body working group, give
the name and home page URI of the working group, and an email
address for discussion of or comments on the specification.
コントローラを書くか、または変えてください: 服従作者の名前、Eメールアドレス、および組織名。(その作者は、倉庫エントリーの変化か取消しを認可するかもしれません)。 また、郵便の宛先、ホームページURI、電話、およびファックス番号は含まれるかもしれません。 提案が標準化団体ワーキンググループから来るなら、ワーキンググループの名前とホームページURI、および仕様の議論かコメントのためのEメールアドレスを与えてください。
Specification document(s):
Reference to document that specifies the header for use with the
indicated protocol. The document MUST be an RFC, a current
Internet-draft or the URL of a publicly accessible document (so
IANA can verify availability of the specification). An indication
of the relevant sections MAY also be included, but is not
required.
仕様ドキュメント: それを記録する参照は示されたプロトコルで使用にヘッダーを指定します。 ドキュメントは、RFC、現在のインターネット草稿または公的にアクセス可能なドキュメントのURLであるに違いありません(したがって、IANAは仕様の有用性について確かめることができます)。 関連セクションのしるしは、また、含まれるかもしれませんが、必要ではありません。
NOTE: if the specification is available in printed form only,
then an Internet draft containing full reference to the paper
document should be published and cited in the registration
template. The paper specification MAY be cited under related
information.
以下に注意してください。 仕様が印刷された用紙だけで利用可能であるなら、紙の文書の完全な参照を含むインターネット草稿は、登録テンプレートで発行されて、引用されるべきです。 紙の仕様は関連する情報の下で引用されるかもしれません。
Related information:
Optionally, citations to additional documents containing further
relevant information.
関連情報: 任意に、追加ドキュメント含有への引用は関連情報を促進します。
Klyne, et al. Best Current Practice [Page 9] RFC 3864 Header Field Registration September 2004
Klyne、他 最も良い現在の練習[9ページ]RFC3864ヘッダーフィールド登録2004年9月
4.3. Submission of Registration
4.3. 登録の提案
The registration template is submitted for incorporation in one of the IANA message header field repositories by one of the following methods:
IANAメッセージヘッダーフィールド倉庫の1つでの編入のために以下の方法の1つで登録テンプレートを提出します:
o An IANA considerations section in a defining RFC, calling for
registration of the message header and referencing information as
required by the registration template within the same document.
Registration of the header is then processed as part of the RFC
publication process.
o 同じドキュメントの中の定義RFCと、メッセージヘッダーの登録のための呼ぶのと必要に応じて登録テンプレートで情報に参照をつけることにおけるIANA問題部。 そして、ヘッダーの登録はRFC公表の過程の一部として処理されます。
o Send a copy of the template to the designated email discussion
list [33] [34]. Allow a reasonable period - at least 2 weeks -
for discussion and comments, then send the template to IANA at the
designated email address [35]. IANA will publish the template
information if the requested name and the specification document
meet the criteria noted in Section 4.1 and Section 4.2.2, unless
the IESG or their designated expert have requested that it not be
published (see Section 4.4). IESG's designated expert should
confirm to IANA that the registration criteria have been
satisfied.
o 指定されたメール議論リスト[33][34]にテンプレートのコピーを送ってください。 相当期間を許容してください--そして、議論とコメントのための少なくとも2週間は指定されたEメールアドレス[35]でテンプレートをIANAに送ります。 要求された名前と仕様ドキュメントがセクション4.1とセクション4.2.2で注意した評価基準を満たすと、IANAはテンプレート情報を発表するでしょう、IESGか彼らの指定された専門家が、それが発行されないよう要求していないなら(セクション4.4を見てください)。 IESGの指定された専門家は、登録評価基準を満たしてあるとIANAに確認するべきです。
When a new entry is recorded in the permanent message header field registry, IANA will remove any corresponding entries (with the same field name and protocol) from the provisional registry.
新しいエントリーが永久的なメッセージヘッダーフィールド登録に記録されるとき、IANAは暫定的な登録からどんな対応するエントリー(同じフィールド名とプロトコルがある)も取り除くでしょう。
4.4. Objections to Registration
4.4. 登録への反論
Listing of an entry in the provisional repository should not be lightly refused. An entry MAY be refused if there is some credible reason to believe that such registration will be harmful. In the absence of such objection, IANA SHOULD allow any registration that meets the criteria set out in Section 4.1 and Section 4.2.2. Some reasonable grounds for refusal might be:
軽く暫定的な倉庫のエントリーのリストを拒否するべきではありません。 有害であるとそのような登録がなる信じる何らかの確かな理由があれば、エントリーは拒否されるかもしれません。 そのような異論がないとき、IANA SHOULDはセクション4.1とセクション4.2.2で始められた評価基準を満たすどんな登録も許します。 拒否のいくつかの正当な理由は以下の通りです。
o There is IETF consensus that publication is considered likely to
harm the Internet technical infrastructure in some way.
o 公表が何らかの方法でインターネット技術インフラに害を及ぼしそうであると考えられるというIETFコンセンサスがあります。
o Disreputable or frivolous use of the registration facilities.
o 登録施設のいかがわしいか軽薄な使用。
o The proposal is sufficiently lacking in purpose, or misleading
about its purpose, that it can be held to be a waste of time and
effort.
o 提案は、目的で十分欠けているか、または目的に関してミスリードすることであり、時間と努力の浪費であることをそれは保持できます。
o Conflict with some current IETF activity.
o 何らかの現在のIETF活動と衝突してください。
Klyne, et al. Best Current Practice [Page 10] RFC 3864 Header Field Registration September 2004
Klyne、他 最も良い現在の練習[10ページ]RFC3864ヘッダーフィールド登録2004年9月
Note that objections or disagreements about technical detail are not, of themselves, considered grounds to refuse listing in the provisional repository. After all, one of its purposes is to allow developers to communicate with a view to combining their ideas, expertise and energy to the maximum benefit of the Internet community.
技術的な詳細に関する反論か不一致が拒否する暫定的な倉庫に記載する根拠であることは自分たちで考えられないことに注意してください。 結局、目的の1つは開発者がインターネットコミュニティの最大限の利益への彼らの考え、専門的技術、およびエネルギーを結合するために交信するのを許容することです。
Publication in an RFC or other form of Open Standard document (per RFC 2026 [1], section 7) is sufficient grounds for publication in the permanent registry.
Standardが記録するRFCか他の形式のオープン(RFC2026[1]あたりのセクション7)における公表は永久的な登録での公表の十分な根拠です。
To assist IANA in determining whether or not there is a sustainable objection to any registration, IESG nominates a designated expert to liaise with IANA about new registrations. For the most part, the designated expert's role is to confirm to IANA that the registration criteria have been satisfied.
何か登録への持続可能な異論があるかどうか決定するのにIANAを助けるために、IESGは、指定された専門家が新しい登録証明書に関してIANAと連携するのを指名します。 指定された専門家の役割はだいたい、登録評価基準を満たしてあるとIANAに確認することです。
The IESG or their designated expert MAY require any change or commentary to be attached to any registry entry.
IESGか彼らの指定された専門家が、どんな変化や論評もどんな登録エントリーにも付けられているのを必要とするかもしれません。
The IESG is the final arbiter of any objection.
IESGはどんな異論の最終的な仲裁者です。
4.5. Change Control
4.5. 変化コントロール
Change control of a header field registration is subject to the same condition as the initial registration; i.e., publication (or reclassification) of an Open Standards specification for a Permanent Message Header Field, or on request of the indicated author/change controller for a Provisional Message Header (like the original submission, subject to review on the designated email discussion list [33].)
ヘッダーフィールド登録の変化コントロールは新規登録と同じ状態を受けることがあります。 すなわち、Permanent Message Header Field、またはProvisional Message Headerの示された作者/変化コントローラの要求に関するオープンStandards仕様の公表(または、再分類)(オリジナルの服従のように、指定されたメール議論に関するレビューを条件として[33]を記載してください。)
A change to a permanent message header field registration MAY be requested by the IESG.
永久的なメッセージヘッダーフィールド登録への変化はIESGによって要求されているかもしれません。
A change to or retraction of any Provisional Message Header Field Repository entry MAY be requested by the IESG or designated expert.
どんなProvisional Message Header Field Repositoryエントリーの変化か取消しも、IESGによって要求されているか、または専門家に指定されるかもしれません。
IANA MAY remove any Provisional Message Header Field Repository entry whose corresponding specification document is no longer available (e.g., expired Internet-draft, or URL not resolvable). Anyone may notify IANA of any such cases by sending an email to the designated email address [35]. Before removing an entry for this reason, IANA SHOULD contact the registered Author/Change controller to determine whether a replacement for the specification document (consistent with the requirements of section Section 4.2.2) is available.
IANA MAYは対応する仕様ドキュメントがもう利用可能でないどんなProvisional Message Header Field Repositoryエントリー(溶解性でない例えば、満期のインターネット草稿、またはURL)も取り除きます。 指定されたEメールアドレス[35]にメールを送ることによって、だれでもどんなそのような場合についてもIANAに通知するかもしれません。 この理由でエントリーを取り除く前に、IANA SHOULDは、仕様ドキュメント(セクションセクション4.2.2の要件と一致した)との交換が利用可能であるかどうか決定するために登録されたAuthor/変化コントローラに連絡します。
Klyne, et al. Best Current Practice [Page 11] RFC 3864 Header Field Registration September 2004
Klyne、他 最も良い現在の練習[11ページ]RFC3864ヘッダーフィールド登録2004年9月
It is intended that entries in the Permanent Message Header Field Registry may be used in the construction of URNs (per RFC 2141 [13]) which have particular requirements for uniqueness and persistence (per RFC 1737 [8]). Therefore, once an entry is made in the Permanent Message Header Registry, the combination of the header name and applicable protocol MUST NOT subsequently be registered for any other purpose. (This is not to preclude revision of the applicable specification(s) within the appropriate IETF Consensus rules, and corresponding updates to the specification citation in the header registration.)
どれに、ユニークさと固執のための特定の要件がRFC2141[13])単位であるか。Permanent Message Header Field RegistryのエントリーがURNsの構造に使用されるかもしれないことを意図する、((RFC1737[8])単位で。 したがって、Permanent Message Header Registryでいったんエントリーをすると、次に、いかなる他の目的のためにもヘッダー名と適切なプロトコルの組み合わせを登録してはいけません。 (これは適切なIETF Consensus規則、および対応するアップデートの中の適切な仕様の改正をヘッダー登録における仕様引用に排除しないためのものです。)
4.6. Comments on Header Definitions
4.6. ヘッダー定義のコメント
Comments on proposed registrations should be sent to the designated email discussion list [33].
指定されたメール議論リスト[33]に提案された登録証明書のコメントを送るべきです。
4.7. Location of Header Field Registry
4.7. ヘッダーフィールド登録の位置
The message header field registry is accessible from IANA's web site http://www.iana.org/assignments/message-headers/ message-header-index.html
メッセージヘッダーフィールド登録はIANAのウェブサイト http://www.iana.org/assignments/message-headers/ メッセージヘッダーindex.htmlからアクセスしやすいです。
5. IANA Considerations
5. IANA問題
This specification calls for:
この仕様は以下のために呼びます。
o A new IANA registry for permanent message header fields per
Section 4 of this document. The policy for inclusion in this
registry is described in Section 4.1 and Section 4.2.1.
o このドキュメントのセクション4あたりの永久的なメッセージヘッダーフィールドのための新しいIANA登録。 この登録での包含のための方針はセクション4.1とセクション4.2.1で説明されます。
o A new IANA repository listing provisional message header fields
per Section 4 of this document. The policy for inclusion in this
registry is described in Section 4.1 and Section 4.2.2.
o このセクション4あたりの暫定的なメッセージヘッダーフィールドが記録する新しいIANA倉庫リスト。 この登録での包含のための方針はセクション4.1とセクション4.2.2で説明されます。
o IESG appoints a designated expert to advise IANA whether
registration criteria for proposed registrations have been
satisfied.
o IESGは、提案された登録証明書の登録評価基準を満たしてあるようIANAにアドバイスするために指定された専門家を任命します。
No initial registry entries are provided.
どんな初期の登録エントリーも提供しません。
6. Security Considerations
6. セキュリティ問題
No security considerations are introduced by this specification beyond those already inherent in the use of message headers.
セキュリティ問題は全くこの仕様でメッセージヘッダーの使用に既に固有のそれらを超えて紹介されません。
Klyne, et al. Best Current Practice [Page 12] RFC 3864 Header Field Registration September 2004
Klyne、他 最も良い現在の練習[12ページ]RFC3864ヘッダーフィールド登録2004年9月
7. Acknowledgements
7. 承認
The shape of the registries described here owes much to energetic discussion of previous versions by many denizens of the IETF-822 mailing list.
ここで説明された登録の形はIETF-822メーリングリストの多くの住人による旧バージョンのエネルギッシュな議論から多くを借りています。
The authors also gratefully acknowledge the contribution of those who provided valuable feedback on earlier versions of this memo: Charles Lindsey, Dave Crocker, Pete Resnick, Jacob Palme, Ned Freed, Michelle Cotton.
また、作者は感謝してこのメモの以前のバージョンの有益なフィードバックを提供した人の貢献を承諾します: チャールズ・リンジー、デーヴ・クロッカー、ピートレズニック、ヤコブ・パルメ、解放されたネッド、ミシェルCotton。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[4] Resnick, P., Ed., "Internet Message Format", RFC 2822, April
2001.
[4] レズニック、P.、エド、「インターネットメッセージ・フォーマット」、RFC2822、4月2001日
8.2. Informative References
8.2. 有益な参照
[5] Horton, M. and R. Adams, "Standard for interchange of USENET
messages", RFC 1036, December 1987.
[5] ホートンとM.とR.アダムス、「USENETメッセージの置き換えの規格」、RFC1036、1987年12月。
[6] Alvestrand, H., Jordan, K., and J. Romaguera, "Rules for
downgrading messages from X.400/88 to X.400/84 when MIME
content-types are present in the messages", RFC 1496, August
1993.
[6] Alvestrand(H.、ジョーダン、K.、およびJ.Romaguera)は「MIMEの満足しているタイプがメッセージに出席しているときX.400/88からX.400/84までメッセージを格下げするために統治します」、RFC1496、1993年8月。
[7] Costanzo, A., Robinson, D., and R. Ullmann, "Encoding Header
Field for Internet Messages", RFC 1505, August 1993.
[7] コスタンゾとA.とロビンソン、D.とR.ウルマン、「インターネットメッセージのためのヘッダーフィールドをコード化します」、RFC1505、1993年8月。
[8] Sollins, K. and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994.
[8]SollinsとK.とL.Masinter、「一定のリソース名のための機能条件書」、RFC1737、1994年12月。
[9] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864,
October 1995.
[9] マイアーズとJ.とM.ローズ、「内容-MD5ヘッダーフィールド」、RFC1864、1995年10月。
[10] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[10]バーナーズ・リー、T.、フィールディング、R.、およびH.Frystyk、「HTTP/1インチ、RFC1945、1996年ハイパーテキスト転送プロトコル--5月。」
Klyne, et al. Best Current Practice [Page 13] RFC 3864 Header Field Registration September 2004
Klyne、他 最も良い現在の練習[13ページ]RFC3864ヘッダーフィールド登録2004年9月
[11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
解放された[11]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
解放された[12]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[13] Moats, R., "URN Syntax", RFC 2141, May 1997.
[13]堀(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
[14] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[14]Kille、S.、「ミキサー(パントマイムインターネットX.400はリレーを機能アップしました):」 「X.400とRFC822/の間でMIMEを写像します」、RFC2156、1998年1月。
[15] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Content-
Disposition Header Field", RFC 2183, August 1997.
[15] Troost、R.、デルナー、S.、およびK.ムーア、「中でプレゼンテーション情報を伝えて、インターネットは通信します」。 「内容気質ヘッダーフィールド」、RFC2183、1997年8月。
[16] Mogul, J. and P. Leach, "Simple Hit-Metering and Usage-Limiting
for HTTP", RFC 2227, October 1997.
[16] ムガール人、J.、P.リーチ、「簡単なヒット計量、HTTPのために用法で制限する」、RFC2227、10月1997日
[17] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word
Extensions: Character Sets, Languages, and Continuations", RFC
2231, November 1997.
解放された[17]、N.、およびK.ムーア、「パラメタ値をまねてください、そして、コード化されて、拡大を言い表してください」 「文字コード、言語、および続刊」、RFC2231、11月1997日
[18] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition
Notification", RFC 3798, May 2004.
[18] ハンセンとT.とG.ボードルイ、Eds、「メッセージ気質通知」、RFC3798、5月2004日
[19] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for
Core Mail List Commands and their Transport through Message
Header Fields", RFC 2369, July 1998.
[19] ニューフェルドとG.とJ.ベヤー、「CoreメールList CommandsとMessage Headerフィールズを通した彼らのTransportのためのMeta-構文としてのURLのUse」、RFC2369、1998年7月。
[20] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[20]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。
[21] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail -
version 2 (VPIMv2)", RFC 3801, June 2004.
[21] ボードルイ、G.、およびG.パーソンズ、「インターネットメールのためにProfileを声に出してください--バージョン2(VPIMv2)」、RFC3801、6月2004日
[22] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen,
"HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518,
February 1999.
[22]Goland、Y.、ホワイトヘッド、E.、Faizi、A.、カーター、S.、およびD.ジェンセン、「分配されたオーサリングのためのHTTP拡大--、WEBDAV、」、RFC2518(1999年2月)
[23] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, "MIME
Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC
2557, March 1999.
[23] パルメとF.とHopmannとA.とシェル、N.とE.Stefferud、「HTMLなどのAggregate Documents(MHTML)のMIME Encapsulation」RFC2557(1999年3月)。
Klyne, et al. Best Current Practice [Page 14] RFC 3864 Header Field Registration September 2004
Klyne、他 最も良い現在の練習[14ページ]RFC3864ヘッダーフィールド登録2004年9月
[24] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[24] フィールディング、R.、Gettys、J.、ムガール人、J.、ニールセン、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[25] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[25] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。
[26] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[26]Klensin、J.、エド、「簡単なメール転送プロトコル」、RFC2821、4月2001日
[27] Klyne, G., "Indicating Media Features for MIME Content", RFC
2912, September 2000.
[27]Klyne、G.、「MIME内容のためのメディア機能を示します」、RFC2912、2000年9月。
[28] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and
Namespace for the Identification of Mailing Lists", RFC 2919,
March 2001.
[28]Chandhok、R.、およびG.ウェンガー、「リストイド:」 「メーリングリストの識別のための構造化された分野と名前空間」(RFC2919)は2001を行進させます。
[29] Kristol, D. and L. Montulli, "HTTP State Management Mechanism",
RFC 2965, October 2000.
[29] クリストルとD.とL.Montulli、「HTTP国家管理メカニズム」、RFC2965、2000年10月。
[30] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[30] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[31] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[31] Alvestrand(H.、「満足している言語ヘッダー」、RFC3282)は2002がそうするかもしれません。
[32] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C
Recommendation xml, October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>.
[32] T.、パオリ、J.、Sperberg-マックィーン、C.、およびE.Maler、「拡張マークアップ言語(XML)1.0(2番目の教育)」をいななかせてください、W3C Recommendation xml、2000年10月、<http://www.w3.org/TR/2000/REC-xml-20001006>。
[33] "Mail address for announcement of new header field submissions",
Mail address: ietf-message-headers@lists.ietf.org
[33] 「新しいヘッダーフィールド差出の発表のための郵便の宛先」、メールアドレス: ietf-message-headers@lists.ietf.org
[34] "Mail address for subscription to ietf-message-
headers@lists.ietf.org. (DO NOT SEND SUBSCRIPTION REQUESTS TO
THE MAILING LIST ITSELF)", Mail address: ietf-message-headers-
request@lists.ietf.org
[34] 「ietf-メッセージ headers@lists.ietf.org の購読のためのアドレスを郵送してください。」 (購読要求をメーリングリスト自体に送りません)「メールは以下を記述します」 ietf-メッセージヘッダー- request@lists.ietf.org
[35] "Mail address for submission of new header field templates",
Mail address: iana@iana.org
[35] 「新しいヘッダーフィールドテンプレートの服従のための郵便の宛先」、メールアドレス: iana@iana.org
Klyne, et al. Best Current Practice [Page 15] RFC 3864 Header Field Registration September 2004
Klyne、他 最も良い現在の練習[15ページ]RFC3864ヘッダーフィールド登録2004年9月
9. Authors' Addresses
9. 作者のアドレス
Graham Klyne Nine by Nine
グラハムKlyne9時9分前
EMail: GK-IETF@ninebynine.org URI: http://www.ninebynine.net/
メール: GK-IETF@ninebynine.org ユリ: http://www.ninebynine.net/
Mark Nottingham BEA Systems 235 Montgomery St. Level 15 San Francisco, CA 94104 USA
マークノッティンガムBEA Systems235モンゴメリ聖レベル15 サンフランシスコ、カリフォルニア94104米国
EMail: mnot@pobox.com
メール: mnot@pobox.com
Jeffrey C. Mogul HP Labs 1501 Page Mill Road Palo Alto, CA 94304 US
ジェフリーC.要人hp研究室1501ページ工場Roadカリフォルニア94304パロアルト(米国)
EMail: JeffMogul@acm.org
メール: JeffMogul@acm.org
Klyne, et al. Best Current Practice [Page 16] RFC 3864 Header Field Registration September 2004
Klyne、他 最も良い現在の練習[16ページ]RFC3864ヘッダーフィールド登録2004年9月
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Klyne, et al. Best Current Practice [Page 17]
Klyne、他 最も良い現在の習慣[17ページ]
一覧
スポンサーリンク
