Network Working Group R. Chandhok
Request for Comments: 2919 G. Wenger
Category: Standards Track QUALCOMM, Inc.
March 2001
List-Id:
A Structured Field and Namespace for the
Identification of Mailing Lists
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
Software that handles electronic mailing list messages (servers and user agents) needs a way to reliably identify messages that belong to a particular mailing list. With the advent of list management headers, it has become even more important to provide a unique identifier for a mailing list regardless of the particular host that serves as the list processor at any given time.
メーリングリストのメッセージ（サーバやユーザエージェント）を扱うソフトウェアが確実に特定のメーリングリストに属しているメッセージを識別するための方法が必要です。リスト管理ヘッダの出現により、それは関係なく、任意の時点で、リストプロセッサとして機能し、特定のホストのメーリングリストの一意の識別子を提供することが一層重要になってきています。
The List-Id header provides a standard location for such an identifier. In addition, a namespace for list identifiers based on fully qualified domain names is described. This namespace is intended to guarantee uniqueness for list owners who require it, while allowing for a less rigorous namespace for experimental and personal use.
リスト-IDヘッダは、識別子のための標準的な場所を提供します。また、完全修飾ドメイン名に基づいてリスト識別子の名前空間が記載されています。この名前空間は、実験的および個人的な使用のためにあまり厳格な名前空間を可能にしながら、それを必要とするリストの所有者のための一意性を保証することを意図しています。
By including the List-Id field, list servers can make it easier for mail clients to provide automated tools for users to perform list functions. The list identifier can serve as a key to make many automated processing tasks easier, and hence more widely available.
一覧-Idフィールドを含めることで、リストサーバは、それが簡単にメールクライアントは、ユーザーがリストの機能を実行するための自動化ツールを提供するために作ることができます。リスト識別子は、簡単に多くの自動処理タスクを作成し、それゆえ、より広く利用可能にするためのキーとして機能することができます。
Internet mailing lists have evolved into fairly sophisticated forums for group communication and collaboration; however, corresponding changes in the underlying infrastructure have lagged behind. Recent proposals like [RFC2369] have expanded the functionality that the MUA can provide by providing more information in each message sent by the mailing list distribution software.
インターネットのメーリングリストは、グループのコミュニケーションとコラボレーションのために、かなり洗練されたフォーラムに進化してきました。しかし、基盤となるインフラストラクチャの対応する変化は遅れをとっています。 [RFC2369]のような最近の提案は、MUAがメーリングリスト配信ソフトウェアによって送信される各メッセージに多くの情報を提供することにより、提供できる機能を拡大しています。
Actually implementing such functionality in the MUA depends on the ability to accurately identify messages as belonging to a particular mailing list. The problem then becomes what attribute or property to use to identify a mailing list. The most likely candidate is the submission address of the mailing list itself. Unfortunately, when the list server host, the list processing software, or the submission policy of the list changes the submission address itself can change. This causes great difficulty for automated processing and filtering.
MUAで実際に実装するような機能を正確に特定のメーリングリストに属するものとしてメッセージを識別するための能力に依存します。問題はその後、メーリングリストを識別するために使用するためにどのような属性やプロパティになります。最も可能性の高い候補者がメーリングリスト自体の提出アドレスです。残念ながら、リストサーバのホスト、リスト処理ソフトウェア、またはリストの提出の方針自体は変更することができ提出アドレスを変更したとき。これは、自動処理やフィルタリングのために大きな困難を引き起こします。
In order to further automate (and make more accurate) the processing a software agent can do, there needs to be some unique identifier to use as an identifier for the mailing list. This identifier can be simply used for string matching in a filter, or it can be used in more sophisticated systems to uniquely identify messages as belonging to a particular mailing list independent of the particular host delivering the actual messages. This identifier can also act as a key into a database of mailing lists.
さらにソフトウェアエージェントが行うことができ、処理を自動化（より正確にする）ためには、メーリングリストの識別子として使用するためのいくつかのユニークな識別子である必要があります。この識別子は、単にフィルタの文字列マッチングのために使用することができ、または一意に実際のメッセージを配信する特定のホストの特定のメーリングリスト独立に属するものとしてメッセージを識別するために、より洗練されたシステムで使用することができます。この識別子は、また、メーリングリストのデータベースへのキーとして機能することができます。
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 RFC 2119.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈されます。
The list identifier will, in most cases, appear like a host name in a domain of the list owner. In other words, the domain name system is used to delegate namespace authority for list identifiers just as it has been used to distribute that authority for other internet resources.
リスト識別子は、ほとんどの場合、リストの所有者のドメインでホスト名のように表示されます。言い換えれば、ドメインネームシステムは、他のインターネットリソースのためにその権限を配布するために使用されてきたと同じように、リスト識別子の名前空間の権限を委任するために使用されます。
Using the domain name system as a basis for the list identifier namespace is intended to leverage an existing authority structure into a new area of application. By using the domain name system to delegate list identifier namespace authority, it becomes instantly clear who has the right to create a particular list identifier, and separates the list identifier from any particular delivery host or mechanism. Only the rights-holder of a domain or subdomain has the authority to create list identifiers in the namespace of that domain. For example, only the rights-holder to the "acm.org" domain has the authority to create list identifiers in "acm.org" domain.
リスト識別子の名前空間の基礎は、アプリケーションの新しい領域に既存の権限構造を活用することを意図しているとして、ドメインネームシステムを使用しました。リスト識別子の名前空間の権限を委任するために、ドメインネームシステムを使用することで、特定のリストの識別子を作成する権限を持っており、任意の特定の配信ホストまたはメカニズムからリスト識別子を区切る誰即座に明らかになりました。ドメインまたはサブドメインの唯一の権利所有者が、そのドメインの名前空間にリスト識別子を作成する権限を持っています。たとえば、「acm.org」ドメインへの唯一の権利保有者は、「acm.org」ドメインのリスト識別子を作成する権限を持っています。
While it is perfectly acceptable for a list identifier to be completely independent of the domain name of the host machine servicing the mailing list, the owner of a mailing list MUST NOT generate list identifiers in any domain namespace for which they do not have authority. For example, a mailing list hosting service may choose to assign list identifiers in their own domain based namespace, or they may allow their clients (the list owners) to provide list identifiers in a namespace for which the owner has authority.
リスト識別子がメーリングリストにサービスを提供するホストマシンのドメイン名とは完全に独立であるために、それは完全に許容ですが、メーリングリストの所有者は、彼らが権限を持っていない任意のドメイン名前空間のリスト識別子を生成してはなりません。例えば、メーリングリストのホスティングサービスでは、独自のドメインベースの名前空間にリスト識別子を割り当てることを選択することができ、または、彼らは彼らのクライアント（リストの所有者は）所有者が権限を持つ名前空間にリスト識別子を提供することを可能にします。
If the owner of the list does not have the authority to create a list identifier in a domain-based namespace, they may create unmanaged list identifiers in the special unmanaged domain "localhost". This would apply to personal users, or users unable to afford domain name registration fees.
リストの所有者がドメインベースの名前空間にリスト識別子を作成する権限を持っていない場合、彼らは特別な管理対象外のドメインは「localhost」で管理されていないリストの識別子を作成することができます。これは、個人ユーザー、またはドメイン名の登録料を支払うことができないユーザーに適用されます。
The syntax for a list identifier in ABNF [RFC2234] follows:
ABNFでリスト識別子の構文は、[RFC2234]は、次のとおりです。
list-id = list-label "." list-id-namespace
リスト-ID =リスト・ラベル ""リスト-ID-名前空間
list-label = dot-atom-text
リストラベル=ドット原子テキスト
list-id-namespace = domain-name / unmanaged-list-id-namespace
リスト-ID-名前空間=ドメイン名/管理対象外リスト-ID-名前空間
unmanaged-list-id-namespace = "localhost"
非管理リスト-ID-名前空間= "localhost" を
domain-name = dot-atom-text
ドメイン名=ドット原子テキスト
Where:
どこ：
dot-atom-text is defined in [DRUMS]
ドット原子テキストが[DRUMS]で定義されています
"localhost" is a reserved domain name is defined in [RFC2606]
「localhost」は予約されたドメイン名が定義されている[RFC2606]
In addition, a list identifier (list-id) MUST NOT be longer than 255 octets in length, for future compatibility. It should be noted that "localhost" is not valid for the domain-name rule.
また、リストの識別子（リスト-ID）は、将来の互換性のために、長さが255オクテットよりも長くてはなりません。 「localhost」をドメイン名のルールに対して有効ではないことに留意すべきです。
This document presents a header field which will provide an identifier for an e-mail distribution list. This header SHOULD be included on all messages distributed by the list (including command responses to individual users), and on other messages where the message clearly applies to this particular distinct list. There MUST be no more than one of each field present in any given message.
この文書は、電子メール配布リストの識別子を提供しますヘッダフィールドを提示します。このヘッダは、（個々のユーザへのコマンド応答を含む）のリストによって配布すべてのメッセージに、メッセージが明確にこの特定の別個のリストに適用される他のメッセージに含まれるべきです。任意のメッセージ中に存在する各フィールドの1つ以下があってはなりません。
This field MUST only be generated by mailing list software, not end users.
このフィールドは唯一のメーリングリストソフトウェアによって生成されなければならない、エンドユーザーにありません。
The contents of the List-Id header mostly consist of angle-bracket ('<', '>') enclosed identifier, with internal whitespace being ignored. MTAs MUST NOT insert whitespace within the brackets, but client applications should treat any such whitespace, that might be inserted by poorly behaved MTAs, as characters to ignore.
リスト-IDヘッダの内容は、主に内部の空白は無視される角度ブラケット（「<」、「>」）囲まれた識別子からなります。 MTAが括弧内に空白を挿入してはなりませんが、クライアント・アプリケーションは、文字を無視するように、悪い行儀のMTAによって挿入される可能性がありますそのような空白を、扱うべきです。
The list header fields are subject to the encoding and character restrictions for mail headers as described in [RFC822].
リストヘッダフィールドは、[RFC822]に記載されているように、メールヘッダの符号化及び文字制限の対象となっています。
The List-Id header MAY optionally include a description by including it as a "phrase" [DRUMS] before the angle-bracketed list identifier. The MUA MAY choose to use this description in its user interface; however, any MUA that intends to make use of the description should be prepared to properly parse and decode any encoded strings or other legal phrase components. For many MUAs the parsing of the List-Id header will simply consist of extracting the list identifier from between the delimiting angle brackets.
リスト-IDヘッダは、必要に応じて[DRUMS]角括弧リスト識別子の前に「という語句」としてそれを含めることによって、記述を含むことができます。 MUAは、そのユーザーインターフェイスで、この記述を使用することもできます。しかし、説明の使用をしようとする任意のMUAが適切に解析し、任意のエンコードされた文字列またはその他の法的なフレーズコンポーネントをデコードするために準備する必要があります。多くのMUAのlist-IDヘッダの解析は単に区切り角括弧の間からリスト識別子を抽出からなります。
The syntax of the List-Id header follows:
一覧-IDヘッダーの構文は次のとおりです。
list-id-header = "List-ID:" [phrase] "<" list-id ">" CRLF
リスト-IDヘッダ= "リスト-ID：" [語句 "<" リスト-ID ">" CRLF
where phrase and CRLF are as defined in [DRUMS]. Unlike most headers in [RFC822], the List-Id header does not allow free insertion of whitespace and comments around tokens. Any descriptive text must be presented in the optional phrase component of the header.
語句とCRLFは[DRUMS]で定義した通りです。 [RFC822]の中で最もヘッダとは異なり、リスト-IDヘッダは、トークンの周りの空白やコメントを自由に挿入することはできません。任意の説明文は、ヘッダのオプションフレーズ成分に提示されなければなりません。
Examples:
例：
List-Id: List Header Mailing List <list-header.nisto.com> List-Id: <commonspace-users.list-id.within.com> List-Id: "Lena's Personal Joke List" <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost> List-Id: "An internal CMU List" <0Jks9449.list-id.cmu.edu> List-Id: <da39efc25c530ad145d41b86f7420c3b.052000.localhost>
<commonspace-users.list-id.within.com>リストID：リスト-ID：一覧<list-header.nisto.com>リスト-IDをメーリングリストヘッダー "レナの個人ジョーク一覧" <たLenas-jokes.da39efc25c530ad145d41b86f7420c3b .021999.localhost>リスト-ID： "内部CMU一覧" <0Jks9449.list-id.cmu.edu>一覧-ID：<da39efc25c530ad145d41b86f7420c3b.052000.localhost>
Although the list identifier MAY be changed by the mailing list administrator this is not desirable. (Note that there is no disadvantage to changing the description portion of the List-Id header.) A MUA may not recognize the change to the list identifier because the MUA SHOULD treat a different list identifier as a different list. As such the mailing list administrator SHOULD avoid changing the list identifier even when the host serving the list changes. On the other hand, transitioning from an informal unmanaged-list-id-namespace to a domain namespace is an acceptable reason to change the list identifier. Also if the focus of the list changes sufficiently the administrator may wish to retire the previous list and its associated identifier to start a new list reflecting the new focus.
リスト識別子は、メーリングリストの管理者が変更することができるが、これは望ましいことではありません。 （リスト-IDヘッダの記述部分を変更することに何の不利益がないことに注意してください。）MUAが異なるリストのような異なるリスト識別子を治療する必要があるためMUAリスト識別子の変更を認識しないかもしれません。このようメーリングリストの管理者は、ホストがリストの変更にサービスを提供しても、リストの識別子を変更することは避けるべきとおり。一方、ドメイン名前空間への非公式の非管理リスト-ID-名前空間から移行すると、リストの識別子を変更するための許容可能な理由です。また、リストの変更の焦点は、十分に管理者が新たな焦点を反映した新しいリストを開始する前のリストとそれに関連する識別子を引退したい場合があります。
This proposal seeks to leverage the existing administrative process already in place for domain name allocation. In particular, we exploit the fact that domain name ownership creates a namespace that by definition can be used to create unique identifiers within the domain.
この提案は、ドメイン名の割り当てのための場所では、既存の管理プロセスを活用することを目指しています。特に、我々は、ドメイン名の所有権を定義することにより、ドメイン内で一意の識別子を作成するために使用することができるの名前空間を作成する、という事実を利用します。
In addition, there must be a mechanism for identification of mailing lists that are administrated by some entity without administrative access to a domain. In this case, general heuristics can be given to reduce the chance of collision, but it cannot be guaranteed. If a list owner requires a guarantee, they are free to register a domain name under their control.
また、ドメインへの管理アクセスすることなく、いくつかのエンティティにより管理されているメーリングリストを識別するためのメカニズムが存在しなければなりません。この場合、一般的な経験則は、衝突の可能性を減らすために与えることができますが、それは保証できません。リストの所有者が保証を必要とする場合、彼らは自分の管理下にドメイン名を登録するのは自由です。
It is suggested, but not required, that list identifiers be created under a subdomain of "list-id" within any given domain. This can help to reduce internal conflicts between the administrators of the subdomains of large organizations. For example, list identifiers at "within.com" are generated in the subdomain of "list-id.within.com".
そのリストの識別子が任意のドメイン内の「リスト-ID」のサブドメインの下に作成され、提案が、必須ではありません。これは、大規模な組織のサブドメインの管理者との間の内部対立を減らすのに役立つことができます。たとえば、「within.com」のリスト識別子は、「list-id.within.com」のサブドメインで生成されます。
List-IDs not ending with ".localhost" MUST be globally unique in reference to all other mailing lists.
「.localhost」で終わらないリスト-IDは、他のすべてのメーリングリストを参照して、グローバルに一意でなければなりません。
List owners wishing to use the special "localhost" namespace for their list identifier SHOULD use the month and year (in the form MMYYYY) that they create the list identifier as a "subdomain" of the "localhost" namespace. In addition, some portion of the list identifier MUST be a randomly generated string. List owners generating such identifiers should refer to [MSGID] for further suggestions on generating a unique identifier, and [RFC1750] for suggestions on generating random numbers. In particular, list identifiers that have a random component SHOULD contain a hex encoding of 128 bits of randomness (resulting in 32 hex characters) as part of the list identifier
自分のリスト識別子のための特別な「localhost」を名前空間を使用したいリストの所有者は、彼らが「localhost」を名前空間の「サブドメイン」としてリスト識別子を作成すること（フォームMMYYYYで）月と年を使用すべきです。また、リスト識別子の一部は、ランダムに生成された文字列でなければなりません。そのような識別子を生成するリストの所有者は、乱数を発生させるの提案のためのユニークな識別子を生成する上で更なる提案のための[MSGID]、および[RFC1750]を参照してください。具体的には、ランダム成分を有するリスト識別子はリスト識別子の一部として（32進文字で得られた）ランダムの128ビットの進符号化を含むべきです
Thus, list identifiers such as <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost> and <da39efc25c530ad145d41b86f7420c3b.051998.localhost> conform to these guidelines, while <lenas-jokes.021999.localhost> and
このように、のようなリスト識別子<たLenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost>と<da39efc25c530ad145d41b86f7420c3b.051998.localhost>これらのガイドラインに準拠して、しばらく<たLenas-jokes.021999.localhost>と
<mylist.localhost> do not. A particular list owner with several lists MAY choose to use the same random number subdomain when generating list identifiers for each of the lists.
<mylist.localhost>にはありません。いくつかのリストを持つ特定のリストの所有者は、リストの各リストの識別子を生成するときに、同じ乱数のサブドメインを使用することもできます。
List-IDs ending with ".localhost" are not guaranteed to be globally unique.
「.localhost」で終わる一覧-IDは、グローバルに一意であることが保証されていません。
There is only one operation defined for list identifiers, that of case insensitive equality (See Section 3.4.7., CASE INDEPENDENCE [RFC822]). The sole use of a list identifier is to identify a mailing list, and the sole use of the List-Id header is to mark a particular message as belonging to that list. The comparison operation MUST ignore any part of the List-Id header outside of the angle brackets, the MUA MAY choose to inform the user if the descriptive name of a mailing list changes.
リスト識別子、大文字小文字を区別しない平等のために定義された1つの操作のみ（セクション3.4.7を参照してください。、CASE INDEPENDENCE [RFC822]）があります。リスト識別子の単独使用はメーリングリストを識別することである、とList-IDヘッダの単独使用は、そのリストに属するものとして特定のメッセージをマークすることです。比較演算は、角括弧の外リスト-IDヘッダのどの部分を無視しなければならない、MUAは、メーリングリストの変化のわかりやすい名前場合、ユーザーに通知するために選ぶかもしれません。
A list that is a sublist for another list in a nested mailing list hierarchy MUST NOT modify the List-Id header field; however, this will only be possible when the nested mailing list is aware of the relationship between it and its "parent" mailing lists. If a mailing list processor encounters a List-Id header field from any unexpected source it SHOULD NOT pass it through to the list. This implies that mailing list processors may have to be updated to properly support List-Ids for nested lists.
一覧-IDヘッダフィールドを変更してはいけませんネストされたメーリングリスト階層内の別のリストのためのサブリストであるリスト。ネストされたメーリングリストはそれとその「親」のメーリングリストとの関係を認識しているときしかし、これはのみ可能となります。メーリングリストプロセッサが予期しないソースからのリスト-IDヘッダーフィールドに遭遇した場合には、リストにそれを通過すべきではありません。これは、メーリングリストプロセッサが正しくネストされたリストの一覧-IDをサポートするように更新しなければならないかもしれないことを示唆しています。
There are very few new security concerns generated with this proposal. Message headers are an existing standard, designed to easily accommodate new types. There may be concern with headers being forged, but this problem is inherent in Internet e-mail, not specific to the header described in this document. Further, the implications are relatively harmless.
この提案で生成された非常にいくつかの新しいセキュリティ上の懸念があります。メッセージヘッダーは、簡単に新しいタイプに対応するように設計された既存の標準的な、です。そこのヘッダーが偽造されているとの懸念であってもよいが、この問題は、この文書で説明ヘッダーに固有のものではない、インターネット電子メールに固有のものであること。さらに、影響が比較的無害です。
As mentioned above, mail list processors SHOULD NOT allow any user-originated List-Id fields to pass through to their lists, lest they confuse the user and have the potential to create security problems.
前述したように、メールリストプロセッサは、彼らは、ユーザーを混乱させ、セキュリティ上の問題を作成する可能性を持っていけないので、任意のユーザー発信リスト-IDフィールドは、そのリストに通過させるべきではありません。
On the client side, a forged list identifier may break automated processing. The list identifier (in its current form) SHOULD NOT be used as an indication of the authenticity of the message.
クライアント側では、偽造リスト識別子は、自動化された処理を壊すことがあります。 （その現在の形で）リスト識別子は、メッセージの真正性の指標として使用することはできません。
The numerous participants of the List-Header [LISTHEADER] and ListMom-Talk [LISTMOM] mailing lists contributed much to the formation and structure of this document.
リスト・ヘッダー[LISTHEADER]とListMomトークの多数の参加者は、[LISTMOM]メーリングリストは、このドキュメントの生成と構造に多くを貢献しました。
Grant Neufeld <grant@acm.org> focused much of the early discussion, and thus was essential in the creation of this document.
グラントノイフェルドは<grant@acm.org>初期の議論の多くを集中し、したがって、この文書の作成に不可欠でした。
References
リファレンス
[LISTHEADER] "List-Header" Mail list. list-header@list.nisto.com <http://www.nisto.com/listspec/mail/> <http://www.nisto.com/listspec/>
[LISTHEADER]「リスト・ヘッダー」メールリスト。 list-header@list.nisto.com <http://www.nisto.com/listspec/mail/> <http://www.nisto.com/listspec/>
[LISTMOM] "ListMom-Talk" Mail list. listmom-talk@skyweyr.com <http://cgi.skyweyr.com/ListMom.Home>
[LISTMOM] "ListMomトーク" メールリスト。 listmom-talk@skyweyr.com <http://cgi.skyweyr.com/ListMom.Home>
[MSGID] J. Zawinski, M. Curtin, "Recommendations for generating Message IDs", Work in Progress.
[MSGID] J. Zawinski、M.カーティン、 "メッセージIDを生成するための推奨事項"、ProgressのWork。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982.
[RFC822]クロッカー、D.、RFC 822 "標準ARPAインターネットテキストメッセージのフォーマットについて"、1982年8月。
[RFC1750] Eastlake, D., Crocker S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]イーストレイク、D.、クロッカーS.とJ.シラー、 "セキュリティのためのランダム性に関する推奨事項"、RFC 1750、1994年12月。
[RFC2234] Crocker, D. and P. Overell. "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]クロッカー、D.、およびP. Overell。 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[RFC2369] 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.
[RFC2369]ノイフェルドG.とJ.ベア、RFC 2369、1998年7月「コアメールリストコマンドとメッセージヘッダフィールドを通じてそれらの輸送のためのメタ構文としてのURLの使用」。
[RFC2606] Eastlake, 3rd, D., and S. Panitz. "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]イーストレーク、第3、D.、およびS. Panitz。 "予約トップレベルDNS名"、BCP 32、RFC 2606、1999年6月。
[RFC2822] Resnick, P., Editor, "Internet Message Format Standard", STD 11, RFC 2822, March 2001.
[RFC2822]レズニック、P.、エディタ、 "インターネットメッセージ形式標準"、STD 11、RFC 2822、2001年3月。
Authors' Addresses
著者のアドレス
Ravinder Chandhok QUALCOMM, Inc. 5775 Morehouse Drive San Diego, CA 92121 USA
Ravinder Chandhok QUALCOMM社5775モアハウスドライブサンディエゴ、CA 92121 USA
EMail: chandhok@qualcomm.com
メールアドレス：chandhok@qualcomm.com
Geoffrey Wenger QUALCOMM, Inc. 5775 Morehouse Drive San Diego, CA 92121 USA
ジェフリー・ウェンガーQUALCOMM社5775モアハウスドライブサンディエゴ、CA 92121 USA
EMail: gwenger@qualcomm.com
メールアドレス：gwenger@qualcomm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。