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: メーリングリストを識別するための構築された(Structured)フィー ルドと名前空間 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. このメモの状態 この文書は、インターネット共同体のためのインターネット標準トラックプロ トコルを規定し、進化のための議論と提案を求めている。標準化の状態とこの プロトコルの状態は"Internet Official Protocol Standards"(STD1)の現在の 版を参照してほしい。このメモの配布は無制限である。 Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. 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ヘッダは、そのような識別子の標準的な位置を提供する。加えて、 FQDNを基にしたリスト識別子のための名前空間について記す。この名前空間は リストオーナに求められる唯一性を保証するつもりであり、また実験的、また 個人使用のためのやや正確でない名前空間を許可する。 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フィールドを含めることで、リストサーバは、メールクライアントに 対してユーザのためにリストの機能を実行するための、自動化されたツールを 開発することを容易にする。 このリスト識別子は多くの自動化されたタスク処理を容易にするための鍵を提 供でき、すなわちより広く利用できる。 1. Introduction 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 Chandhok & Wenger Standards Track [Page 1] RFC 2919 List-Id March 2001 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. 1 導入 インターネットのメーリングリストは、グループのコミュニケーションや共同 作業のための、まさに洗練された討論会場として発展してきた。しかしながら、 根本的な基盤に関連した変化は遅れをとっている。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", "SHALL", "SHALL NOT", "SHOULD","SHOULD NOT", "RECOMMENDEED", "MAY", "OPTIONAL"のキーワードに ついてはRFC2119に記されたように解釈すべきものとする。 2. The List Identifier Syntax 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. 2 List識別子の構文 ほとんどの場合、list識別子はリストオーナのドメイン中のホスト名のように 見えるだろう。いいかえれば、リスト識別子のための名前空間の権限の委譲の ためには、ちょうど他のインターネット資源の権限の分配に使われたように、 ドメインネームシステムが使われる。 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"ドメインにリスト識別子を作る権限を持つ。 Chandhok & Wenger Standards Track [Page 2] RFC 2919 List-Id March 2001 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. リスト識別子が、メーリングリストを提供するホストマシンのドメイン名と完 全に独立していることが完全に満足できるので、メーリングリストのオーナは、 権限を持たないいかなるドメインの名前空間にもリスト識別子を生成してはな らない(MUST NOT)。例えば、 メーリングリストをホスティングするサービスは、彼ら自身のドメインの名前 空間にリスト識別子を割りあてることを選択するかもしれず、彼らの顧客(リ ストオーナ)に、オーナが権限を持つ名前空間のリスト識別子を提供すること を許すかもしれない。 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. もしもリストのオーナがドメインを基本とした名前空間にlist識別子を生成する 権限を持っていない場合には、管理されないリスト識別子を、特殊な管理され ないドメイン"localhost"に生成してもよい。これは、個人ユーザやドメイン 名の登録費用が払えないユーザに適用されるだろう。 The syntax for a list identifier in ABNF [RFC2234] follows: list識別子の構文は以下の通り： list-id = list-label "." list-id-namespace list-label = dot-atom-text 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] ここで、dot-atom-textは [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識別子(list-id)は255オクテットより長く てはならない(MUST NOT)。注意されるべきこととして、"localhost"はドメイ ン名のルールでは有効でない。 3. The List-Id Header Field 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. 3 List-Idヘッダフィールド この文書は、メーリングリストの識別子を提供するためのヘッダフィールドを 公開する。このヘッダは、そのリストから配送されるすべてのメッセージに含 まれるべきであり(SHOULD、個人ユーザへのコマンド応答を含む)、この特別に 識別されたリストにあてられた別のメッセージに含まれるべきである。いかな るメッセージにも、それぞれのフィールドは1回を越えて存在してはならない (MUST)。 Chandhok & Wenger Standards Track [Page 3] RFC 2919 List-Id March 2001 This field MUST only be generated by mailing list software, not end users. このフィールドは、エンドユーザではなく、メーリングリストソフトウェアに よってのみ生成されなければならない(MUST)。 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ヘッダの内容は、識別子を囲む角かっこ('<', '>')からなるのが普通 であり、かっこ内部のホワイトスペースが無視される。MTAはかっこの中にホ ワイトスペースを挿入してはならない(MUST NOT)が、クライアントのアプリケー ションは、悪いふるまいをする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ヘッダはオプションで、角かっこでかこまれたリスト識別子の前に "phrase"として含めることで、解説を含んでもよい(MAY)。MUAはユーザインター フェイスでこの解説を利用してもよい(MAY)。しかしながら、解説を利用する つもりのあるどのMUAも、正しくパースし、エンコードされた文字列や他の合 法なフレーズ(phrase)要素をデコードして準備するべきである。多くの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. フレーズ(Phrase)とCRLFは[DRUMS]に定義されている。RFC822にあるほとんど のヘッダと違い、List-Idヘッダはホワイトスペースやコメントを、トークン のまわりに自由に挿入することが許可されていない。どの説明テキストも、ヘッ ダのオプションのフレーズ要素中に存在しなければならない。 Examples: 例) List-Id: List Header Mailing List List-Id: List-Id: "Lena's Personal Joke List" List-Id: "An internal CMU List" <0Jks9449.list-id.cmu.edu> List-Id: 4. Persistence of List Identifiers 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 Chandhok & Wenger Standards Track [Page 4] RFC 2919 List-Id March 2001 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. 4 リスト識別子の持続性 リスト識別子はメーリングリスト管理者によって変更され得る(MAY)にもかか わらず、これはおすすめできない。(List-Idヘッダの説明部分を変更するのは、 何ら不都合がないことに注意。)MUAは、異なるリスト識別子を異なるリストと して扱うべきである(SHOULD)ので、MUAはリスト識別子の変更を理解しないか もしれない。これらにより、リストを提供するホストが変更になったときでさ え、メーリングリストの管理者はリスト識別子の変更を避けるべきである (SHOULD)。 他方、非公式の管理されないlist識別子の名前空間から、ドメインの名前空間 への移行は、リスト識別子を変更するに受け入れられる理由である。 もし、リストの焦点が変化したら、新しい焦点を反映する新しいリストを開始 するために、管理者がいままでのリストとそれに関連する識別子をやめるのを 望むかもしれない。 5. Uniqueness of List Identifiers 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. 5 リスト識別子がユニークでないこと この提案では、手段をドメイン名の割りあての場所という既存の管理プロセスに 求めている。特に、我々は、ドメイン名の持ち主が、ドメイン内でユニークな 識別子を作るのに使われる名前空間を、定義として作るという事実を開発した。 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". リスト識別子は、与えられたドメイン名の中の、"list-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"で終わらないList-Idは、すべての他のメーリングリストを照会 し、グローバルに一意でなければならない(MUST)。 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"の名前空間を使うことを望むリストオーナは、リ スト識別子を生成するとき、月と年(MMYYYYの形で)を"localhost"の名前空間 のサブドメインとして使うべきである(SHOULD)。加えて、リスト識別子のいく つかの部分は乱数的に生成した文字列でなければならない(MUST)。そのような 識別子を生成するリストオーナは、ユニークな識別子の生成方法をより提案し ている[MSGID]を参照すべきであり、また乱数発生を提案している[RFC1750]を 参照すべきである。特に、乱数要素を持つリスト識別子では、128bitの乱数の ヘクスエンコード(32ヘクスキャラクターとなる)をリスト識別子の一部として 含むべきである(SHOULD)。 Thus, list identifiers such as and conform to these guidelines, while and Chandhok & Wenger Standards Track [Page 5] RFC 2919 List-Id March 2001 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. ゆえに、 と はこのガイドラ インに適合し、やは適合 しない。いくつかのリストを持つ特定のリストオーナは、それぞれのリストに リスト識別子を作る際、同じ乱数のサブドメインを使ってもよい(MAY)。 List-IDs ending with ".localhost" are not guaranteed to be globally unique. ".localhost"で終わるList-IDはグローバルに一意であることが保証されない。 6. Operations on List Identifiers 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. 6 List識別子の運用 list識別子として定義された運用はたった1つしかなく、大文字小文字を識別 せず同等と扱う(3.4.7節とRFC822の"CASE INDEPENDENCE"を見よ)。たった1つ のlist識別子の利用方法はメーリングリストの識別であり、たった1つの List-Idヘッダの利用方法は、あるメッセージがそのリストに属することを示 すだけである。比較するときにはList-Idヘッダの角かっこ(<>)の外のいかな る部分も無視されなければならず(MUST)、MUAは、メーリングリストの説明的 な名前が変更されたなら、MUAはそれをユーザに情報提供してもよい(MAY)。 7. Supporting Nested Lists 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. 7 ネストしたリストのサポート ネストしたメーリングリスト階層中、他のリストのサブリスト(部分リスト)で あるリストは、List-Idヘッダフィールドを変更してはならない(MUST NOT); しかしながらこれは、それとその「親の」メーリングリストの間の関係をネス トしたメーリングリストが知っているときだけ可能であろう。もしもメーリン グリスト処理プログラムが予期せぬ源からのList-Idヘッダフィールドを見付 けたなら、それをリストに配送すべきではない(SHOULD NOT)。これは、 メーリングリスト処理プログラムは、ネストされたリストのList-Idを、適切 にサポートするために更新しなければならないかもしれないことを意味する。 8. Security Considerations 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. 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. 8. セキュリティに関する考察 この提案が作られることにより、新しいセキュリティに関する心配事はほんの わずかしか生じない。メッセージヘッダは、簡単に新しいタイプに適応できる ようデザインされた、既存の標準である。ヘッダが捏造されるという心配があ るかもしれないが、この問題はインターネットのe-mailから継承したものであ り、この文書に書いたヘッダ特有のものではない。加えて、その意味は比較的 無害である。 上で延べた通り、メーリングリストの処理プログラムは、ユーザが書いた List-Idフィールドについて、それらがユーザを混乱させないよう、またセキュ リティの問題をつくる可能性があるため、そのメーリングリストに配送してし まうことを許すべきではない(SHOULD NOT)。 クライアント側としては、捏造されたlist識別子は自動的な処理により消され るかもしれない。list識別子は(現在の形では)メッセージが認証されたしるし として用いるべきではない(SHOULD NOT)。 Chandhok & Wenger Standards Track [Page 6] RFC 2919 List-Id March 2001 9. Acknowledgements The numerous participants of the List-Header [LISTHEADER] and ListMom-Talk [LISTMOM] mailing lists contributed much to the formation and structure of this document. Grant Neufeld focused much of the early discussion, and thus was essential in the creation of this document. 9 謝辞 List-HeaderとListMom-Talkメーリングリストの多くの参加者は、この文書の 生成と構築に多大な寄与をした。 Grant Neufeld は初期の議論の多くを集め、よってこの文書 の生成における本質であった。 References [LISTHEADER] "List-Header" Mail list. list-header@list.nisto.com [LISTMOM] "ListMom-Talk" Mail list. listmom-talk@skyweyr.com [MSGID] J. Zawinski, M. Curtin, "Recommendations for generating Message IDs", Work in Progress. [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982. [RFC1750] Eastlake, D., Crocker S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC2234] Crocker, D. and P. Overell. "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [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. [RFC2606] Eastlake, 3rd, D., and S. Panitz. "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999. [RFC2822] Resnick, P., Editor, "Internet Message Format Standard", STD 11, RFC 2822, March 2001. Chandhok & Wenger Standards Track [Page 7] RFC 2919 List-Id March 2001 Authors' Addresses 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 EMail: gwenger@qualcomm.com Chandhok & Wenger Standards Track [Page 8] RFC 2919 List-Id March 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. 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. Chandhok & Wenger Standards Track [Page 9] ---- 訳について この訳は、美森勇気 が個人的な目的で行いました。利用 は自由ですが、一切の保証はしません。