[要約] RFC 2919は、メーリングリストの識別のための構造化フィールドと名前空間を提供するものであり、メーリングリストの識別と管理を容易にすることを目的としています。
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
List-ID：メーリングリストの識別のための構造化されたフィールドと名前空間
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.
Copyright（c）The Internet Society（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.
List-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.
List-IDフィールドを含めることにより、List Serverは、メールクライアントがユーザーがリスト機能を実行できるように自動化されたツールを簡単に提供できるようにすることができます。リスト識別子は、多くの自動処理タスクを容易にするための鍵として機能し、したがってより広く利用可能です。
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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
List Identifier NameSpaceの基礎としてドメイン名システムを使用すると、既存の権限構造を新しいアプリケーション領域に活用することを目的としています。Domain Name Systemを使用してリスト識別子NameSpace Authorityを委任することにより、特定のリスト識別子を作成する権利を持つ権利がある人が即座に明確になり、リスト識別子を特定の配信ホストまたはメカニズムから分離します。ドメインまたはサブドメインの権利所有者のみが、そのドメインの名前空間にリスト識別子を作成する権限を持っています。たとえば、「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
list-id = list-label "。"List-ID-NamesPace
list-label = dot-atom-text
list-id-namespace = domain-name / unmanaged-list-id-namespace
list-id-namespace = domain-name / unmanaged-list-id-namespace
unmanaged-list-id-namespace = "localhost"
domain-name = dot-atom-text
Where:
ただし：
dot-atom-text is defined in [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.
さらに、将来の互換性のために、リスト識別子（List-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.
List-IDヘッダーの内容は、主にAngle-Bracket（ '<'、 '>'）囲まれた識別子で構成され、内部の空白は無視されます。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.
List-IDヘッダーには、オプションで、Angle-Bracketed List Identifierの前に「フレーズ」[ドラム]として含めることにより、説明を含めることができます。MUAは、この説明をユーザーインターフェイスで使用することを選択できます。ただし、説明を使用しようとするMUAは、エンコードされた文字列またはその他の法的フレーズコンポーネントを適切に解析およびデコードするために準備する必要があります。多くのMUAにとって、List-IDヘッダーの解析は、描写角度ブラケットの間からリスト識別子を抽出するだけで構成されます。
The syntax of the List-Id header follows:
List-IDヘッダーの構文は次のとおりです。
list-id-header = "List-ID:" [phrase] "<" list-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が定義されています。[RFC822]のほとんどのヘッダーとは異なり、List-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>
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.
リスト識別子はメーリングリスト管理者によって変更される場合がありますが、これは望ましくありません。（List-IDヘッダーの説明部分を変更することには欠点はないことに注意してください。）MUAは、MUAが別のリスト識別子を別のリストとして扱う必要があるため、リスト識別子の変更を認識しない場合があります。そのため、メーリングリストの管理者は、リストにサービスを提供するホストが変更された場合でも、リスト識別子の変更を避ける必要があります。一方、非公式のマネージドリストID-Namespaceからドメイン名空間に移行することは、リスト識別子を変更する許容可能な理由です。また、リストの焦点が十分に変更された場合、管理者は以前のリストとその関連する識別子を廃止して、新しい焦点を反映した新しいリストを開始することを希望する場合があります。
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」のサブドメインの下に作成されることが示唆されていますが、必須ではありません。これは、大規模な組織のサブドメインの管理者間の内部紛争を減らすのに役立ちます。たとえば、「内部」のリスト識別子は、「list-id.within.com」のサブドメインで生成されます。
List-IDs not ending with ".localhost" MUST be globally unique in reference to all other mailing lists.
「.localhost」で終わりではないList-idsは、他のすべてのメーリングリストに関連してグローバルにユニークでなければなりません。
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]を参照する必要があります。特に、ランダムコンポーネントを持つリスト識別子には、リスト識別子の一部として128ビットのランダム性（32ヘクス文字をもたらす）の16進コードを含める必要があります
Thus, list identifiers such as
<lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost> and
<da39efc25c530ad145d41b86f7420c3b.051998.localhost> conform to these
guidelines, while <lenas-jokes.021999.localhost> and
<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」で終わるList-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。、症例独立性[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.
ネストされたメーリングリストの階層にある別のリストのサブリストであるリストは、List-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.
上記のように、メールリストのプロセッサは、ユーザーに由来するList-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.
List-Header [Listheader]とListMom-Talk [ListMom]メーリングリストの多数の参加者が、このドキュメントの形成と構造に大きく貢献しました。
Grant Neufeld <grant@acm.org> focused much of the early discussion, and thus was essential in the creation of this document.
Grant Neufeld <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/>
[LISTMOM] "ListMom-Talk" Mail list. 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。Curtin、「メッセージIDを生成するための推奨事項」、進行中の作業。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982.
[RFC822] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、RFC 822、1982年8月。
[RFC1750] Eastlake, D., Crocker S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750] Eastlake、D.、Crocker S.およびJ. Schiller、「セキュリティのためのランダム性推奨」、RFC 1750、1994年12月。
[RFC2234] Crocker, D. and P. Overell. "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] Crocker、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] Neufeld G.およびJ. Baer、「コアメールリストのコマンドとメッセージヘッダーフィールドを介したトランスポートのメタシンタックスとしてのURLの使用」、RFC 2369、1998年7月。
[RFC2606] Eastlake, 3rd, D., and S. Panitz. "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]イーストレイク、3rd、D。、およびS.パニッツ。「予約済みのトップレベルDNS名」、BCP 32、RFC 2606、1999年6月。
[RFC2822] Resnick, P., Editor, "Internet Message Format Standard", STD 11, RFC 2822, March 2001.
[RFC2822] Resnick、P.、編集者、「インターネットメッセージフォーマット標準」、STD 11、RFC 2822、2001年3月。
Authors' Addresses
著者のアドレス
Ravinder Chandhok QUALCOMM, Inc. 5775 Morehouse Drive San Diego, CA 92121 USA
Ravinder Chandhok Qualcomm、Inc。5775 Morehouse Drive San Diego、CA 92121 USA
EMail: chandhok@qualcomm.com
Geoffrey Wenger QUALCOMM, Inc. 5775 Morehouse Drive San Diego, CA 92121 USA
Geoffrey Wenger Qualcomm、Inc。5775 Morehouse Drive San Diego、CA 92121 USA
EMail: gwenger@qualcomm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。