RFC4731 日本語訳

Network Working Group                                        A. Melnikov
Request for Comments: 4731                                     Isode Ltd
Category: Standards Track                                    D. Cridland
                                                   Inventure Systems Ltd
                                                           November 2006

コメントを求めるワーキンググループA.メリニコフの要求をネットワークでつないでください: 4731年のIsode Ltdカテゴリ: 標準化過程D.Cridland InventureシステムLtd2006年11月

           IMAP4 Extension to SEARCH Command for Controlling
                  What Kind of Information Is Returned

どういう情報が返されるかを制御するための探しコマンドへのIMAP4拡張子

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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The IETF Trust (2006).

IETFが信じる著作権(C)(2006)。

Abstract

要約

   This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands
   with several result options, which can control what kind of
   information is returned. The following result options are defined:
   minimal value, maximal value, all found messages, and number of found
   messages.

このドキュメントはいくつかの結果オプションでIMAP(RFC3501)検索とUID SEARCHコマンドを広げています。(オプションは、どういう情報が返されるかを制御できます)。 以下の結果オプションは定義されます: 最小量の値、メッセージが見つけられて、すべてがメッセージ、および数を設立する最大値。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Conventions Used in This Document ...............................2
   3. IMAP Protocol Changes ...........................................2
      3.1. New SEARCH/UID SEARCH Result Options .......................2
      3.2. Interaction with CONDSTORE extension .......................4
   4. Formal Syntax ...................................................5
   5. Security Considerations .........................................6
   6. IANA Considerations .............................................6
   7. Normative References ............................................6
   8. Acknowledgments .................................................6

1. 序論…2 2. このドキュメントで中古のコンベンション…2 3. IMAPは変化について議定書の中で述べます…2 3.1. 新しい検索/UIDは結果オプションを捜します…2 3.2. CONDSTORE拡張子との相互作用…4 4. 正式な構文…5 5. セキュリティ問題…6 6. IANA問題…6 7. 標準の参照…6 8. 承認…6

Melnikov & Cridland         Standards Track                     [Page 1]

RFC 4731               IMAP4 Extension to SEARCH           November 2006

2006年11月に捜すメリニコフとCridland標準化過程[1ページ]RFC4731IMAP4拡張子

1.  Introduction

1. 序論

   [IMAPABNF] extended SEARCH and UID SEARCH commands with result
   specifiers (also known as result options), which can control what
   kind of information is returned.

[IMAPABNF]は結果特許説明書の作成書(また、結果オプションとして、知られている)と共に検索とUID SEARCHコマンドを広げました。(その特許説明書の作成書は、どういう情報が返されるかを制御できます)。

   A server advertising the ESEARCH capability supports the following
   result options:  minimal value, maximal value, all found messages,
   and number of found messages.  These result options allow clients to
   get SEARCH results in more convenient forms, while also saving
   bandwidth required to transport the results, for example, by finding
   the first unseen message or returning the number of unseen or deleted
   messages.  Also, when a single MIN or a single MAX result option is
   specified, servers can optimize execution of SEARCHes.

ESEARCH能力の広告を出すサーバは、以下の結果がオプションであるとサポートします: 最小量の値、メッセージが見つけられて、すべてがメッセージ、および数を設立する最大値。 クライアントは、より便利なフォームでこれらの結果オプションで検索結果を得ることができます、また、節約している帯域幅が例えば、最初の見えないメッセージを見つけるか、または見えないか削除されたメッセージの数を返すことによって結果を輸送するのが必要ですが。 また、独身のMINかただ一つのMAX結果オプションが指定されるとき、サーバはSEARCHesの実行を最適化できます。

2.  Conventions Used in This Document

2. 本書では使用されるコンベンション

   In examples, "C:" and "S:" indicate lines sent by the client and
   server, respectively.

例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。

   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 [KEYWORDS].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[キーワード]で説明されるように本書では解釈されることであるべきですか?

3.   IMAP Protocol Changes

3. IMAPプロトコル変化

3.1.  New SEARCH/UID SEARCH Result Options

3.1. 新しい検索/UID検索結果オプション

   The SEARCH/UID SEARCH commands are extended to allow for the
   following result options:

検索/UID SEARCHコマンドは以下の結果オプションを考慮するために広げられます:

      MIN
         Return the lowest message number/UID that satisfies the SEARCH
         criteria.

検索評価基準を満たすMIN Returnの最も低いメッセージ番号/UID。

         If the SEARCH results in no matches, the server MUST NOT
         include the MIN result option in the ESEARCH response; however,
         it still MUST send the ESEARCH response.

検索がマッチを全くもたらさないなら、サーバはESEARCH応答におけるMIN結果オプションを含んではいけません。 しかしながら、それはまだESEARCH応答を送らなければなりません。

      MAX
         Return the highest message number/UID that satisfies the SEARCH
         criteria.

検索評価基準を満たすMAX Returnの最も高いメッセージ番号/UID。

         If the SEARCH results in no matches, the server MUST NOT
         include the MAX result option in the ESEARCH response; however,
         it still MUST send the ESEARCH response.

検索がマッチを全くもたらさないなら、サーバはESEARCH応答におけるMAX結果オプションを含んではいけません。 しかしながら、それはまだESEARCH応答を送らなければなりません。

Melnikov & Cridland         Standards Track                     [Page 2]

RFC 4731               IMAP4 Extension to SEARCH           November 2006

2006年11月に捜すメリニコフとCridland標準化過程[2ページ]RFC4731IMAP4拡張子

      ALL
         Return all message numbers/UIDs that satisfy the SEARCH
         criteria.  Unlike regular (unextended) SEARCH, the messages are
         always returned using the sequence-set syntax.  A sequence-set
         representation may be more compact and can be used as is in a
         subsequent command that accepts sequence-set.  Note, the client
         MUST NOT assume that messages/UIDs will be listed in any
         particular order.

すべてReturnは検索評価基準を満たす数/UIDsをすべて通信させます。 定期的な(「非-広げ」られる)検索と異なって、シーケンスセット構文を使用することでメッセージをいつも返します。 シーケンスセット表現は、よりコンパクトであるかもしれなく、シーケンスセットを受け入れるその後のコマンドにそのままで使用できます。 注意、クライアントは、メッセージ/UIDsがどんな特定のオーダーにも記載されると仮定してはいけません。

         If the SEARCH results in no matches, the server MUST NOT
         include the ALL result option in the ESEARCH response; however,
         it still MUST send the ESEARCH response.

検索がいいえをインクルードではなく、マッチ、サーバがそうしなければならないもたらす、すべての結果オプション、ESEARCH応答で。 しかしながら、それはまだESEARCH応答を送らなければなりません。

      COUNT
         Return number of the messages that satisfy the SEARCH criteria.
         This result option MUST always be included in the ESEARCH
         response.

検索評価基準を満たすメッセージのCOUNT Return番号。 ESEARCH応答にいつもこの結果オプションを含まなければなりません。

   If one or more result options described above are specified, the
   extended SEARCH command MUST return a single ESEARCH response
   [IMAPABNF], instead of the SEARCH response.

上で説明された1つ以上の結果オプションが指定されるなら、拡張検索命令はただ一つのESEARCH応答[IMAPABNF]を返さなければなりません、検索応答の代わりに。

   An extended UID SEARCH command MUST cause an ESEARCH response with
   the UID indicator present.

UIDインディケータが存在していた状態で、拡張UID SEARCHコマンドはESEARCH応答を引き起こさなければなりません。

   Note that future extensions to this document can allow servers to
   return multiple ESEARCH responses for a single extended SEARCH
   command.  These extensions will have to describe how results from
   multiple ESEARCH responses are to be amalgamated.

サーバがこのドキュメントへの今後の拡大でただ一つの拡張検索命令のための複数のESEARCH応答を返すことができることに注意してください。 これらの拡大は合併される複数のESEARCH応答からの結果がことである方法を説明しなければならないでしょう。

   If the list of result options is empty, that requests the server to
   return an ESEARCH response instead of the SEARCH response.  This is
   equivalent to "(ALL)".

結果オプションのリストが空であるなら、それは、検索応答の代わりにESEARCH応答を返すようサーバに要求します。 これは「(すべて)」に同等です。

      Example:    C: A282 SEARCH RETURN (MIN COUNT) FLAGGED
                     SINCE 1-Feb-1994 NOT FROM "Smith"
                  S: * ESEARCH (TAG "A282") MIN 2 COUNT 3
                  S: A282 OK SEARCH completed

例: C: どんな「スミス」Sからの少しの1994年2月1日以来もA282検索リターン(分は重要である)は弛みませんでした: * ESEARCH(タグ"A282")分2は3秒間、重要です: 完成したA282 OK SEARCH

      Example:    C: A283 SEARCH RETURN () FLAGGED
                     SINCE 1-Feb-1994 NOT FROM "Smith"
                  S: * ESEARCH (TAG "A283") ALL 2,10:11
                  S: A283 OK SEARCH completed

例: C: どんな「スミス」Sからの少しの1994年2月1日以来もA283検索リターン()は弛みませんでした: * ESEARCH、(: 11秒間、"A283") 2、10にすべて、タグ付けをしてください: 完成したA283 OK SEARCH

   The following example demonstrates finding the first unseen message
   as returned in the UNSEEN response code on a successful SELECT
   command:

以下の例はうまくいっているSELECTコマンドのUNSEEN応答コードで返すように最初の見えないメッセージを見つけながら、示されます:

Melnikov & Cridland         Standards Track                     [Page 3]

RFC 4731               IMAP4 Extension to SEARCH           November 2006

2006年11月に捜すメリニコフとCridland標準化過程[3ページ]RFC4731IMAP4拡張子

      Example:    C: A284 SEARCH RETURN (MIN) UNSEEN
                  S: * ESEARCH (TAG "A284") MIN 4
                  S: A284 OK SEARCH completed

例: C: A284はリターンの(分)見えないSを捜します: * ESEARCH(タグ"A284")4秒間分: 完成したA284 OK SEARCH

   The following example demonstrates that if the ESEARCH UID indicator
   is present, all data in the ESEARCH response is referring to UIDs;
   for example, the MIN result specifier will be followed by a UID.

以下の例は、ESEARCH UIDインディケータが存在しているなら、ESEARCH応答におけるすべてのデータがUIDsについて言及しているのを示します。 例えば、MIN結果特許説明書の作成書はUIDによって続かれるでしょう。

      Example:    C: A285 UID SEARCH RETURN (MIN MAX) 1:5000
                  S: * ESEARCH (TAG "A285") UID MIN 7 MAX 3800
                  S: A285 OK SEARCH completed

例: C: A285 UIDはリターン(MINマックス)1: 5000秒間、探します: * 3800秒間のESEARCH(タグ"A285")UID MIN7マックス: 完成したA285 OK SEARCH

   The following example demonstrates returning the number of deleted
   messages:

以下の例は削除されたメッセージの数を返しながら、示されます:

      Example:    C: A286 SEARCH RETURN (COUNT) DELETED
                  S: * ESEARCH (TAG "A286") COUNT 15
                  S: A286 OK SEARCH completed

例: C: A286検索リターン(数える)はSを削除しました: * ESEARCH(タグ"A286")は15秒間、数えます: 完成したA286 OK SEARCH

3.2.  Interaction with CONDSTORE extension

3.2. CONDSTORE拡張子との相互作用

   When the server supports both the ESEARCH and the CONDSTORE
   [CONDSTORE] extension, and the client requests one or more result
   option described in section 3.1 together with the MODSEQ search
   criterion in the same SEARCH/UID SEARCH command, then the server MUST
   return the ESEARCH response containing the MODSEQ result option
   (described in the following paragraph) instead of the extended SEARCH
   response described in section 3.5 of [CONDSTORE].

サーバが、ESEARCHとCONDSTOREの両方[CONDSTORE]が拡大と、1つ以上の結果オプションが同じ検索/UID SEARCHコマンドにおけるMODSEQ検索評価基準と共にセクション3.1で説明したクライアント要求であるとサポートすると、サーバは[CONDSTORE]のセクション3.5で説明された拡張検索応答の代わりにMODSEQ結果オプションを含む(以下のパラグラフで、説明されます)ESEARCH応答を返さなければなりません。

   If the SEARCH/UID SEARCH command contained a single MIN or MAX result
   option, the MODSEQ result option contains the mod-sequence for the
   found message.  If the SEARCH/UID SEARCH command contained both MIN
   and MAX result options and no ALL/COUNT option, the MODSEQ result
   option contains the highest mod-sequence for the two returned
   messages.  Otherwise the MODSEQ result option contains the highest
   mod-sequence for all messages being returned.

検索/UID SEARCHコマンドが独身のMINかMAX結果オプションを含んだなら、MODSEQ結果オプションは備え付けることのメッセージのためのモッズ系列を含んでいます。 検索/UID SEARCHコマンドがMINとMAX結果オプションとすべての/COUNTオプションの両方を含んだなら、MODSEQ結果オプションは2つの返されたメッセージのための最も高いモッズ系列を含んでいます。 さもなければ、MODSEQ結果オプションは返されるすべてのメッセージのための最も高いモッズ系列を含んでいます。

   Example: The following example demonstrates how Example 15 from
   [CONDSTORE] would look in the presence of one or more result option:

例: 以下の例は[CONDSTORE]からのExample15が1つ以上の結果オプションがあるときどう見えるだろうかを示します:

         C: a1 SEARCH RETURN (MIN) MODSEQ "/flags/\\draft"
             all 620162338
         S: * ESEARCH (TAG "a1") MIN 2 MODSEQ 917162488
         S: a1 OK Search complete

C: すべての620162338秒間のa1SEARCH RETURN(MIN)MODSEQ「/flags/\\草稿」: * ESEARCH、(タグ、「a1") 917162488秒間の分2MODSEQ:、」 a1OK検索完全です。

         C: a2 SEARCH RETURN (MAX) MODSEQ "/flags/\\draft"
             all 620162338
         S: * ESEARCH (TAG "a2") MAX 23 MODSEQ 907162321

C: すべての620162338秒間のa2SEARCH RETURN(マックス)MODSEQ「/flags/\\草稿」: * ESEARCH、(「a2") 最大23MODSEQ907162321」にタグ付けをしてください。

Melnikov & Cridland         Standards Track                     [Page 4]

RFC 4731               IMAP4 Extension to SEARCH           November 2006

2006年11月に捜すメリニコフとCridland標準化過程[4ページ]RFC4731IMAP4拡張子

         S: a2 OK Search complete

S: a2OK検索完全です。

         C: a3 SEARCH RETURN (MIN MAX) MODSEQ "/flags/\\draft"
             all 620162338
         S: * ESEARCH (TAG "a3") MIN 2 MAX 23 MODSEQ 917162488
         S: a3 OK Search complete

C: すべての620162338秒間のa3SEARCH RETURN(MIN MAX)MODSEQ「/flags/\\草稿」: * ESEARCH、(タグ、「a3")分2は917162488秒間、23MODSEQに最大限にします」。 a3OK検索完全です。

         C: a4 SEARCH RETURN (MIN COUNT) MODSEQ "/flags/\\draft"
             all 620162338
         S: * ESEARCH (TAG "a4") MIN 2 COUNT 10 MODSEQ 917162500
         S: a4 OK Search complete

C: すべての620162338秒間のa4SEARCH RETURN(MIN COUNT)MODSEQ「/flags/\\草稿」: * ESEARCH、(タグ、「a4")分2は917162500秒間、10MODSEQを数えます」。 a4OK検索完全です。

4.  Formal Syntax

4. 正式な構文

   The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) notation as specified in [ABNF].

以下の構文仕様は[ABNF]の指定されるとしてのAugmented BN記法(ABNF)記法を使用します。

   Non-terminals referenced but not defined below are as defined by
   [IMAP4], [CONDSTORE], or [IMAPABNF].

[IMAP4]、[CONDSTORE]、または[IMAPABNF]によって定義されるように参照をつけられましたが、以下で定義されなかった非端末があります。

   Except as noted otherwise, all alphabetic characters are case-
   insensitive.  The use of upper or lowercase characters to define
   token strings is for editorial clarity only.  Implementations MUST
   accept these strings in a case-insensitive fashion.

別の方法で注意されるのを除いて、すべての英字がケース神経が鈍いです。 トークンストリングを定義する上側の、または、小文字のキャラクタの使用は編集の明快だけのためのものです。 実装は大文字と小文字を区別しないファッションでこれらのストリングを受け入れなければなりません。

     capability         =/ "ESEARCH"

能力=/"ESEARCH"

     search-return-data = "MIN" SP nz-number /
                          "MAX" SP nz-number /
                          "ALL" SP sequence-set /
                          "COUNT" SP number
                          ;; conforms to the generic
                          ;; search-return-data syntax defined
                          ;; in [IMAPABNF]

検索リターンデータは「分」SP nz-番号/「マックス」SP nz-番号/「すべて」SPシーケンスセット/「カウント」SP番号と等しいです。 ジェネリックに従います。 定義された検索リターンデータ構文。 コネ[IMAPABNF]

     search-return-opt  = "MIN" / "MAX" / "ALL" / "COUNT"
                          ;; conforms to generic search-return-opt
                          ;; syntax defined in [IMAPABNF]

検索リターンが選ばれた=「分」/「マックス」/「すべて」/「カウント」。 検索リターンが選ばれた状態で、ジェネリックに従います。 中で定義された構文[IMAPABNF]

     When the CONDSTORE [CONDSTORE] IMAP extension is also supported,
     the ABNF is updated as follows:

また、CONDSTORE[CONDSTORE]IMAP拡張子をサポートするとき、以下の通りABNFをアップデートします:

     search-return-data =/ "MODSEQ" SP mod-sequence-value
                          ;; mod-sequence-value is defined
                          ;; in [CONDSTORE]

検索リターンデータ"MODSEQ"SPモッズ系列=/価値。 モッズ系列価値は定義されます。 コネ[CONDSTORE]

Melnikov & Cridland         Standards Track                     [Page 5]

RFC 4731               IMAP4 Extension to SEARCH           November 2006

2006年11月に捜すメリニコフとCridland標準化過程[5ページ]RFC4731IMAP4拡張子

5.  Security Considerations

5. セキュリティ問題

   In the general case, the IMAP SEARCH/UID SEARCH commands can be CPU
   and/or IO intensive, and are seen by some as a potential attack point
   for denial of service attacks, so some sites/implementations even
   disable them entirely.  This is quite unfortunate, as SEARCH command
   is one of the best examples demonstrating IMAP advantage over POP3.

一般的な場合では、IMAP SEARCH/UID SEARCHコマンドがCPU、そして/または、IO徹底的である場合があり、サービスの否定のための起こり得るかもしれない攻撃ポイントが攻撃されるときいくつかによって見られるので、いくつかのサイト/実装がそれらを完全に無効にさえします。 これは、検索命令がPOP3よりIMAP利点を示す最も良い例の1つであるので、かなり不運です。

   The ALL and COUNT return options don't change how SEARCH is working
   internally; they only change how information about found messages is
   returned.  MIN and MAX SEARCH result options described in this
   document can lighten the load on IMAP servers that choose to optimize
   SEARCHes containing only one or both of them.

すべてとCOUNTリターンオプションは検索がどう内部的に働いているかを変えません。 彼らはどう備え付けることのメッセージの情報を返すかを変えるだけです。 彼らの1か両方だけを含んでいて、結果オプションが説明したMINとマックスSEARCHはSEARCHesを最適化するのを選ぶIMAPサーバで本書では負担を軽くすることができます。

   It is believed that this extension doesn't raise any additional
   security concerns not already discussed in [IMAP4].

この拡大が[IMAP4]で既に議論しなかった少しの追加担保関心も高めないと信じられています。

6.  IANA Considerations

6. IANA問題

   IMAP4 capabilities are registered by publishing a standards track RFC
   or an IESG-approved experimental RFC.  The registry is currently
   located at <http://www.iana.org/assignments/imap4-capabilities>.

IMAP4能力は、標準化過程RFCかIESGによって承認された実験的なRFCを発行することによって、登録されます。 登録は現在、<imap4http://www.iana.org/課題/能力>に位置しています。

   This document defines the ESEARCH IMAP capability, which IANA added
   to the registry.

このドキュメントはESEARCH IMAP能力を定義します。(IANAは登録にそれを加えました)。

7.  Normative References

7. 引用規格

   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [IMAP4]     Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
               4rev1", RFC 3501, March 2003.

[IMAP4] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」

   [ABNF]      Crocker, D. (Ed.) and P. Overell , "Augmented BNF for
               Syntax Specifications: ABNF", RFC 4234, October 2005.

[ABNF]クロッカー、D.編とP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。

   [IMAPABNF]  Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
               ABNF", RFC 4466, April 2006..

[IMAPABNF] メリニコフとA.とC.Daboo、「IMAP4 ABNFへの集まっている拡大」、RFC4466、2006年4月。

   [CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
               STORE", RFC 4551, June 2006.

[CONDSTORE] メリニコフとA.とS.穴、「条件付きの店のためのIMAP拡張子」、RFC4551、2006年6月。

8.  Acknowledgments

8. 承認

   Thanks to Michael Wener, Arnt Gulbrandsen, Cyrus Daboo, Mark Crispin,
   and Pete Maclean for comments and corrections.

コメントと修正をマイケルWener、Arnt Gulbrandsen、サイラスDaboo、マーク・クリスピン、およびピートマクレーンをありがとうございます。

Melnikov & Cridland         Standards Track                     [Page 6]

RFC 4731               IMAP4 Extension to SEARCH           November 2006

2006年11月に捜すメリニコフとCridland標準化過程[6ページ]RFC4731IMAP4拡張子

Authors' Addresses

作者のアドレス

   Alexey Melnikov
   Isode Limited
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex, TW12 2BX
   UK

AlexeyメリニコフIsode株式会社5城のビジネス村の36駅のRoadハンプトン、ミドルセックスTW12 2BXイギリス

   EMail: Alexey.Melnikov@isode.com

メール: Alexey.Melnikov@isode.com

   Dave A. Cridland
   Inventure Systems Limited

デーヴA.Cridland Inventureシステム株式会社

   EMail: dave.cridland@inventuresystems.co.uk
   URL: http://invsys.co.uk/dave/

メール: dave.cridland@inventuresystems.co.uk URL: http://invsys.co.uk/dave/

Melnikov & Cridland         Standards Track                     [Page 7]

RFC 4731               IMAP4 Extension to SEARCH           November 2006

2006年11月に捜すメリニコフとCridland標準化過程[7ページ]RFC4731IMAP4拡張子

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2006).

IETFが信じる著作権(C)(2006)。

   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.

このドキュメントは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, THE IETF TRUST,
   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.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、IETF信頼、「そのままで」という基礎と貢献者の上で提供していて、そして、インターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

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機能のための基金は現在、インターネット協会によって提供されます。

Melnikov & Cridland         Standards Track                     [Page 8]

メリニコフとCridland標準化過程[8ページ]