RFC4978 日本語訳

Network Working Group                                     A. Gulbrandsen
Request for Comments: 4978                        Oryx Mail Systems GmbH
Category: Standards Track                                    August 2007

Gulbrandsenがコメントのために要求するワーキンググループA.をネットワークでつないでください: 4978年のオリックスメールシステムGmbHカテゴリ: 標準化過程2007年8月

                      The IMAP COMPRESS Extension

IMAPは拡大を圧縮します。

Status of this Memo

この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)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   The COMPRESS extension allows an IMAP connection to be effectively
   and efficiently compressed.

COMPRESS拡張子は、IMAP接続が事実上、効率的に圧縮されるのを許容します。

   Table of Contents

目次

   1. Introduction and Overview .......................................2
   2. Conventions Used in This Document ...............................2
   3. The COMPRESS Command ............................................3
   4. Compression Efficiency ..........................................4
   5. Formal Syntax ...................................................6
   6. Security Considerations .........................................6
   7. IANA Considerations .............................................6
   8. Acknowledgements ................................................7
   9. References ......................................................7
      9.1. Normative References .......................................7
      9.2. Informative References .....................................7

1. 序論と概要…2 2. このドキュメントで中古のコンベンション…2 3. 圧縮コマンド…3 4. 圧縮効率…4 5. 正式な構文…6 6. セキュリティ問題…6 7. IANA問題…6 8. 承認…7 9. 参照…7 9.1. 標準の参照…7 9.2. 有益な参照…7

Gulbrandsen                 Standards Track                     [Page 1]

RFC 4978              The IMAP COMPRESS Extension            August 2007

IMAPが拡大2007年8月に圧縮するGulbrandsen標準化過程[1ページ]RFC4978

1.  Introduction and Overview

1. 序論と概要

   A server which supports the COMPRESS extension indicates this with
   one or more capability names consisting of "COMPRESS=" followed by a
   supported compression algorithm name as described in this document.

1つ以上の能力名がサポートしている圧縮アルゴリズム名が本書では説明されるようにあとに続いた「湿布=」から成っていて、COMPRESSが拡大であるとサポートするサーバはこれを示します。

   The goal of COMPRESS is to reduce the bandwidth usage of IMAP.

COMPRESSの目標はIMAPの帯域幅使用法を減少させることです。

   Compared to PPP compression (see [RFC1962]) and modem-based
   compression (see [MNP] and [V42BIS]), COMPRESS offers much better
   compression efficiency.  COMPRESS can be used together with Transport
   Security Layer (TLS) [RFC4346], Simple Authentication and Security
   layer (SASL) encryption, Virtual Private Networks (VPNs), etc.
   Compared to TLS compression [RFC3749], COMPRESS has the following
   (dis)advantages:

PPP圧縮([RFC1962]を見る)とモデムベースの圧縮([MNP]と[V42BIS]を見る)と比べて、COMPRESSははるかに良い圧縮効率を提供します。 Transport Security Layer(TLS)[RFC4346]、Simple Authentication、およびSecurity層(SASL)の暗号化、Virtual兵士のNetworks(VPNs)などと共にCOMPRESSを使用できます。 COMPRESSには、TLS圧縮[RFC3749]と比べて、以下の(けなします)利点があります:

   - COMPRESS can be implemented easily both by IMAP servers and
     clients.

- IMAPサーバとクライアントは容易にCOMPRESSを実装することができます。

   - IMAP COMPRESS benefits from an intimate knowledge of the IMAP
     protocol's state machine, allowing for dynamic and aggressive
     optimization of the underlying compression algorithm's parameters.

- IMAP COMPRESSはIMAPプロトコルの州のマシンに関する詳細な知識の利益を得ます、基本的な圧縮アルゴリズムのパラメタのダイナミックで攻撃的な最適化を考慮して。

   - When the TLS layer implements compression, any protocol using that
     layer can transparently benefit from that compression (e.g., SMTP
     and IMAP).  COMPRESS is specific to IMAP.

- TLS層が圧縮を実装すると、その層を使用するどんなプロトコルも透過的に、その圧縮(例えば、SMTPとIMAP)の利益を得ることができます。 COMPRESSはIMAPに特定です。

   In order to increase interoperation, it is desirable to have as few
   different compression algorithms as possible, so this document
   specifies only one.  The DEFLATE algorithm (defined in [RFC1951]) is
   standard, widely available and fairly efficient, so it is the only
   algorithm defined by this document.

interoperationを増強するために、このドキュメントが1つだけを指定して、できるだけわずかな異なった圧縮アルゴリズムしか持っていないのは望ましいです。 DEFLATEアルゴリズム([RFC1951]では、定義される)が標準で、広く利用可能でかなり効率的であるので、それはこのドキュメントによって定義された唯一のアルゴリズムです。

   In order to increase interoperation, IMAP servers that advertise this
   extension SHOULD also advertise the TLS DEFLATE compression mechanism
   as defined in [RFC3749].  IMAP clients MAY use either COMPRESS or TLS
   compression, however, if the client and server support both, it is
   RECOMMENDED that the client choose TLS compression.

また、interoperationを増強するために、この拡大SHOULDの広告を出すIMAPサーバは[RFC3749]で定義されるようにTLS DEFLATE圧縮機構の広告を出します。 IMAPクライアントはCOMPRESSかTLS圧縮のどちらかを使用するかもしれなくて、クライアントとサーバが両方をサポートするなら、しかしながら、クライアントがTLS圧縮を選ぶのは、RECOMMENDEDです。

   The extension adds one new command (COMPRESS) and no new responses.

1つの新しいコマンド(COMPRESS)を加えますが、拡大はどんな新しい応答も加えません。

2.  Conventions Used in This Document

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

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

   Formal syntax is defined by [RFC4234] as modified by [RFC3501].

正式な構文は[RFC3501]によって変更される[RFC4234]によって定義されます。

Gulbrandsen                 Standards Track                     [Page 2]

RFC 4978              The IMAP COMPRESS Extension            August 2007

IMAPが拡大2007年8月に圧縮するGulbrandsen標準化過程[2ページ]RFC4978

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

例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。 「[…]」 発音省略を指示します。

3.  The COMPRESS Command

3. 圧縮コマンド

   Arguments: Name of compression mechanism: "DEFLATE".

議論: 圧縮機構の名前: 「空気を抜いてください。」

   Responses: None

応答: なし

   Result: OK The server will compress its responses and expects the
              client to compress its commands.
           NO Compression is already active via another layer.
          BAD Command unknown, invalid or unknown argument, or COMPRESS
              already active.

結果: サーバが応答を圧縮して、クライアントを予想するOKはコマンドを圧縮します。 どんなCompressionも別の層で既にアクティブではありません。 BAD Commandの未知の、または、無効の、または、未知の議論、またはCOMPRESS、既にアクティブです。

   The COMPRESS command instructs the server to use the named
   compression mechanism ("DEFLATE" is the only one defined) for all
   commands and/or responses after COMPRESS.

COMPRESSコマンドは、湿布の後にすべてのコマンド、そして/または、応答に、命名された圧縮機構(「空気を抜いてください」は定義された唯一無二である)を使用するようサーバに命令します。

   The client MUST NOT send any further commands until it has seen the
   result of COMPRESS.  If the response was OK, the client MUST compress
   starting with the first command after COMPRESS.  If the server
   response was BAD or NO, the client MUST NOT turn on compression.

それがCOMPRESSの結果を見るまで、クライアントは少しのさらなるコマンドも送ってはいけません。 応答がOKであったなら、クライアントはCOMPRESSの後に最初のコマンドからの始めを圧縮しなければなりません。 サーバ応答がBADであったかいいえなら、クライアントは圧縮をつけてはいけません。

   If the server responds NO because it knows that the same mechanism is
   active already (e.g., because TLS has negotiated the same mechanism),
   it MUST send COMPRESSIONACTIVE as resp-text-code (see [RFC3501],
   Section 7.1), and the resp-text SHOULD say which layer compresses.

同じメカニズムが既にアクティブであることを知っているので(例えば、TLSが同じメカニズムを交渉したので)サーバがいいえを反応させるなら、respテキストコードとしてCOMPRESSIONACTIVEを送らなければなりません、そして、([RFC3501]を見てください、セクション7.1)resp-テキストSHOULDはどの層の湿布を示すか。

   If the server issues an OK response, the server MUST compress
   starting immediately after the CRLF which ends the tagged OK
   response.  (Responses issued by the server before the OK response
   will, of course, still be uncompressed.)  If the server issues a BAD
   or NO response, the server MUST NOT turn on compression.

サーバがOK応答を発行するなら、サーバはCRLF直後始めを圧縮しなければなりません(タグ付けをされたOK応答を終わらせます)。 (それでも、OK応答の前にサーバによって発行された応答はもちろん解凍されるでしょう。) BADを発行しますが、サーバがどんな応答も発行しないなら、サーバが圧縮をつけてはいけません。

   For DEFLATE (as for many other compression mechanisms), the
   compressor can trade speed against quality.  When decompressing there
   isn't much of a tradeoff.  Consequently, the client and server are
   both free to pick the best reasonable rate of compression for the
   data they send.

DEFLATE(他の多くの圧縮機構のような)に関しては、コンプレッサーは品質に対して速度を取り引きできます。 減圧するとき、大した見返りがありません。 その結果、クライアントとサーバはともに無料でそれらが送るデータのための圧縮の最も良い妥当な速度を選ぶことができます。

   When COMPRESS is combined with TLS (see [RFC4346]) or SASL (see
   [RFC4422]) security layers, the sending order of the three extensions
   MUST be first COMPRESS, then SASL, and finally TLS.  That is, before
   data is transmitted it is first compressed.  Second, if a SASL
   security layer has been negotiated, the compressed data is then
   signed and/or encrypted accordingly.  Third, if a TLS security layer
   has been negotiated, the data from the previous step is signed and/or

COMPRESSがTLS([RFC4346]を見る)かSASL([RFC4422]を見る)セキュリティ層に結合されるとき、3つの拡大の送付注文は、最初に、COMPRESSと、次に、SASLと、最終的にTLSであるに違いありません。 すなわち、データが送られる前に、それは最初に、圧縮されます。 2番目に、SASLセキュリティ層が交渉されたなら、圧縮されたデータは、それに従って、次に、署名される、そして/または、暗号化されます。 そして/またはTLSセキュリティ層が交渉されたなら、3番目に、前のステップからのデータが署名される。

Gulbrandsen                 Standards Track                     [Page 3]

RFC 4978              The IMAP COMPRESS Extension            August 2007

IMAPが拡大2007年8月に圧縮するGulbrandsen標準化過程[3ページ]RFC4978

   encrypted accordingly.  When receiving data, the processing order
   MUST be reversed.  This ensures that before sending, data is
   compressed before it is encrypted, independent of the order in which
   the client issues COMPRESS, AUTHENTICATE, and STARTTLS.

それに従って、暗号化されます。 データを受け取るとき、処理命令を逆にしなければなりません。 これは発信する前にそれを確実にして、それが暗号化されている前にデータは圧縮されます、クライアントがCOMPRESS、AUTHENTICATE、およびSTARTTLSを発行する注文の如何にかかわらず。

   The following example illustrates how commands and responses are
   compressed during a simple login sequence:

以下の例はコマンドと応答が簡単なログイン系列の間、どう圧縮されるかを例証します:

        S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE]
        C: a starttls
        S: a OK TLS active

S: * OK[能力IMAP4REV1 STARTTLS湿布=は空気を抜く]C: starttls S: OK TLS能動態

            From this point on, everything is encrypted.

この地点から先は、すべてが暗号化されています。

        C: b login arnt tnra
        S: b OK Logged in as arnt
        C: c compress deflate
        S: d OK DEFLATE active

C: bログインarnt tnra S: bはarnt CとしてLoggedを承認します: c湿布はSに空気を抜かせます: d OK DEFLATEアクティブです。

            From this point on, everything is compressed before being
            encrypted.

この地点から先は、暗号化される前にすべてが圧縮されます。

   The following example demonstrates how a server may refuse to
   compress twice:

サーバが、二度以下を圧縮するのをどう拒否するかもしれないかを以下の例は示します。

        S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=DEFLATE]
        [...]
        C: c compress deflate
        S: c NO [COMPRESSIONACTIVE] DEFLATE active via TLS

S: * OK[能力IMAP4REV1 STARTTLS湿布=は空気を抜きます][…] C: c湿布はSに空気を抜かせます: TLSを通してアクティブなcノー[COMPRESSIONACTIVE]DEFLATE

4.  Compression Efficiency

4. 圧縮効率

   This section is informative, not normative.

このセクションは規範的であるのではなく、有益です。

   IMAP poses some unusual problems for a compression layer.

IMAPは圧縮層のためにいくつかの異常な問題を引き起こします。

   Upstream is fairly simple.  Most IMAP clients send the same few
   commands again and again, so any compression algorithm that can
   exploit repetition works efficiently.  The APPEND command is an
   exception; clients that send many APPEND commands may want to
   surround large literals with flushes in the same way as is
   recommended for servers later in this section.

上流はかなり簡単です。 ほとんどのIMAPクライアントが同じわずかなコマンドを再三送るので、反復を利用できるどんな圧縮アルゴリズムも効率的に利きます。 APPENDコマンドは例外です。 多くのAPPENDコマンドを送るクライアントは後でサーバのためにこのセクションで推薦されるのと同じように大きいリテラルを水洗に取り巻きたがっているかもしれません。

   Downstream has the unusual property that several kinds of data are
   sent, confusing all dictionary-based compression algorithms.

川下には、すべての辞書ベースの圧縮アルゴリズムを混乱させて、数種類のデータが送られる異常な性質があります。

Gulbrandsen                 Standards Track                     [Page 4]

RFC 4978              The IMAP COMPRESS Extension            August 2007

IMAPが拡大2007年8月に圧縮するGulbrandsen標準化過程[4ページ]RFC4978

   One type is IMAP responses.  These are highly compressible; zlib
   using its least CPU-intensive setting compresses typical responses to
   25-40% of their original size.

1つのタイプがIMAP応答です。 これらは非常に圧縮性です。 使用する中でCPU設定最も徹底的でないzlibがそれらの原寸の25-40%に典型的反応を圧縮します。

   Another type is email headers.  These are equally compressible, and
   benefit from using the same dictionary as the IMAP responses.

別のタイプはメールヘッダーです。 これらは、等しく圧縮性であり、IMAP応答と同じ辞書を使用するのから利益を得ます。

   A third type is email body text.  Text is usually fairly short and
   includes much ASCII, so the same compression dictionary will do a
   good job here, too.  When multiple messages in the same thread are
   read at the same time, quoted lines etc. can often be compressed
   almost to zero.

3番目のタイプはメール本文です。 テキストが通常、かなり短く、多くのASCIIを含んでいるので、同じ圧縮辞書はここでの良い仕事もするでしょう。 同じスレッドにおける複数のメッセージが同時に読まれるとき、しばしば系列の引用されたなどをほとんどゼロに圧縮できます。

   Finally, attachments (non-text email bodies) are transmitted, either
   in binary form or encoded with base-64.

最終的に、付属(非テキストメール本文)は、どちらか二部形式で伝えられるかベース-64でコード化されています。

   When attachments are retrieved in binary form, DEFLATE may be able to
   compress them, but the format of the attachment is usually not IMAP-
   like, so the dictionary built while compressing IMAP does not help.
   The compressor has to adapt its dictionary from IMAP to the
   attachment's format, and then back.  A few file formats aren't
   compressible at all using deflate, e.g., .gz, .zip, and .jpg files.

付属が二部形式で検索されるとき、DEFLATEはそれらを圧縮できるかもしれませんが、付属の形式は通常、どんなIMAPも好きでないのでIMAPを圧縮している間に構築された辞書が助けないということです。 コンプレッサーは、IMAPから付属の形式までの辞書を翻案して、次に、後部を翻案しなければなりません。 いくつかのファイル形式は使用が空気を抜かせるすべて、例えば、.gz、.zip、および.jpgファイルで圧縮性ではありません。

   When attachments are retrieved in base-64 form, the same problems
   apply, but the base-64 encoding adds another problem.  8-bit
   compression algorithms such as deflate work well on 8-bit file
   formats, however base-64 turns a file into something resembling 6-bit
   bytes, hiding most of the 8-bit file format from the compressor.

付属がベース-64フォームで検索されるとき、同じ問題は適用されますが、ベース-64コード化は別の問題を加えます。 しかしながら、空気を抜くような8ビットの圧縮アルゴリズムは8ビットのファイル形式でうまくいって、ベース-64は6ビットのバイトに類似しながら、ファイルを何かに変えます、コンプレッサーから8ビットのファイル形式の大部分を隠して。

   When using the zlib library (see [RFC1951]), the functions
   deflateInit2(), deflate(), inflateInit2(), and inflate() suffice to
   implement this extension.  The windowBits value must be in the range
   -8 to -15, or else deflateInit2() uses the wrong format.
   deflateParams() can be used to improve compression rate and resource
   use.  The Z_FULL_FLUSH argument to deflate() can be used to clear the
   dictionary (the receiving peer does not need to do anything).

inflateInit2()、zlibライブラリ([RFC1951]を見る)、機能deflateInit2()を使用するときには()に空気を抜かせてください、そして、ふくらませてください。() 十分であって、この拡大を実装してください。 windowBits値が範囲に-8〜-15にあるに違いありませんか、またはdeflateInit2()は間違った形式を使用します。圧縮率とリソース使用を改良するのにdeflateParams()は使用できます。 辞書をきれいにするのに()に空気を抜かせるZ_FULL_FLUSH議論を使用できます(受信同輩は何もする必要はありません)。

   A client can improve downstream compression by implementing BINARY
   (defined in [RFC3516]) and using FETCH BINARY instead of FETCH BODY.
   In the author's experience, the improvement ranges from 5% to 40%
   depending on the attachment being downloaded.

クライアントは、BINARY([RFC3516]では、定義される)を実装して、FETCH BODYの代わりにFETCH BINARYを使用することによって、川下の圧縮を改良できます。 作者の経験では、改良は5%からダウンロードされる付属による40%まで及びます。

   A server can improve downstream compression if it hints to the
   compressor that the data type is about to change strongly, e.g., by
   sending a Z_FULL_FLUSH at the start and end of large non-text
   literals (before and after '*CHAR8' in the definition of literal in
   RFC 3501, page 86).  Small literals are best left alone.  A possible
   boundary is 5k.

'データ型が強く変えようとしているコンプレッサーをほのめかすなら、サーバは川下の圧縮を改良できます、例えば、大きい非テキストリテラル(RFC3501とのリテラルの定義における'*CHAR8'の前後に86ページ)の始めと終わりにZ_FULL_FLUSHを送ることによって。 小さいリテラルは特に放っておかれます。 可能な境界は5kです。

Gulbrandsen                 Standards Track                     [Page 5]

RFC 4978              The IMAP COMPRESS Extension            August 2007

IMAPが拡大2007年8月に圧縮するGulbrandsen標準化過程[5ページ]RFC4978

   A server can improve the CPU efficiency both of the server and the
   client if it adjusts the compression level (e.g., using the
   deflateParams() function in zlib) at these points, to avoid trying to
   compress incompressible attachments.  A very simple strategy is to
   change the level to 0 at the start of a literal provided the first
   two bytes are either 0x1F 0x8B (as in deflate-compressed files) or
   0xFF 0xD8 (JPEG), and to keep it at 1-5 the rest of the time.  More
   complex strategies are possible.

それが圧縮不可能な付属を圧縮しようとするのを避けるように、これらのポイントで圧縮レベル(例えば、zlibでdeflateParams()機能を使用する)を調整するなら、サーバはサーバとクライアントのCPU効率を高めることができます。 同じくらい中、非常に簡単な戦略が最初の2バイトが0x1F 0x8Bであるならレベルをリテラルの始めの0に変えることである、(空気を抜く、-、圧縮、ファイル)、0xFF 0xD8(JPEG)、1-5 現代の残りでそれを保ちます。 より複雑な戦略は可能です。

5.  Formal Syntax

5. 正式な構文

   The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) notation as specified in [RFC4234].  This syntax augments
   the grammar specified in [RFC3501].  [RFC4234] defines SP and
   [RFC3501] defines command-auth, capability, and resp-text-code.

以下の構文仕様は[RFC4234]の指定されるとしてのAugmented BN記法(ABNF)記法を使用します。 この構文は[RFC3501]で指定された文法を増大させます。 [RFC4234]はSPを定義します、そして、[RFC3501]はコマンド-auth、能力、およびrespテキストコードを定義します。

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

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

       command-auth =/ compress

コマンド-auth=/湿布

       compress    = "COMPRESS" SP algorithm

=「湿布」SPアルゴリズムを圧縮してください。

       capability  =/ "COMPRESS=" algorithm
                     ;; multiple COMPRESS capabilities allowed

能力=/「湿布=」アルゴリズム。 能力が許容した複数のCOMPRESS

       algorithm   = "DEFLATE"

アルゴリズムは「空気を抜いてください」と等しいです。

       resp-text-code =/ "COMPRESSIONACTIVE"

respテキストコード=/"COMPRESSIONACTIVE"

   Note that due the syntax of capability names, future algorithm names
   must be atoms.

能力名、将来のアルゴリズム名の構文がそうしなければならない支払われるべきものが原子であることに注意してください。

6.  Security Considerations

6. セキュリティ問題

   As for TLS compression [RFC3749].

TLS圧縮[RFC3749]のように。

7.  IANA Considerations

7. IANA問題

   The IANA has added COMPRESS=DEFLATE to the list of IMAP capabilities.

IANAはIMAP能力のリストにCOMPRESS=DEFLATEを追加しました。

Gulbrandsen                 Standards Track                     [Page 6]

RFC 4978              The IMAP COMPRESS Extension            August 2007

IMAPが拡大2007年8月に圧縮するGulbrandsen標準化過程[6ページ]RFC4978

8.  Acknowledgements

8. 承認

   Eric Burger, Dave Cridland, Tony Finch, Ned Freed, Philip Guenther,
   Randall Gellens, Tony Hansen, Cullen Jennings, Stephane Maes, Alexey
   Melnikov, Lyndon Nerenberg, and Zoltan Ordogh have all helped with
   this document.

エリックBurger、デーヴCridland、トニーFinch、ネッド・フリード、フィリップ・グンサー、ランドルGellens、トニー・ハンセン、Cullenジョニングス、ステファーヌMaes、Alexeyメリニコフ、リンドン・ネーレンバーグ、およびゾルタンOrdoghはこのドキュメントですべて助けました。

   The author would also like to thank various people in the rooms at
   meetings, whose help is real, but not reflected in the author's
   mailbox.

また、作者は助けが本当ですが、作者のメールボックスの中に反射していないミーティングで部屋で様々な人々に感謝したがっています。

9.  References

9. 参照

9.1.  Normative References

9.1. 引用規格

   [RFC1951]  Deutsch, P., "DEFLATE Compressed Data Format Specification
              version 1.3", RFC 1951, May 1996.

ドイツ語、[RFC1951]P.、「DEFLATE Compressed Data Format Specification、バージョン1.3インチ、RFC1951、1996インチ年5月。

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

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

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

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

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

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

9.2.  Informative References

9.2. 有益な参照

   [RFC1962]  Rand, D., "The PPP Compression Control Protocol (CCP)",
              RFC 1962, June 1996.

D.、「ppp圧縮制御プロトコル(CCP)」、RFC1962 1996年6月の[RFC1962]底ならし革。

   [RFC3516]  Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
              April 2003.

[RFC3516] ネーレンバーグ、L.、「IMAP4の2進の満足している拡張子」、RFC3516、2003年4月。

   [RFC3749]  Hollenbeck, S., "Transport Layer Security Protocol
              Compression Methods", RFC 3749, May 2004.

[RFC3749]Hollenbeck(S.、「トランスポート層セキュリティプロトコル圧縮方法」、RFC3749)は2004がそうするかもしれません。

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

[RFC4346] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。

   [RFC4422]  Melnikov, A. and  K. Zeilenga, "Simple Authentication and
              Security Layer (SASL)", RFC 4422, June 2006.

[RFC4422] メリニコフとA.とK.Zeilenga、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、2006年6月。

   [V42BIS]   ITU, "V.42bis: Data compression procedures for data
              circuit-terminating equipment (DCE) using error correction
              procedures", http://www.itu.int/rec/T-REC-V.42bis, January
              1990.

[V42BIS]ITU、「V.42bis:」 「回路を終えるデータ設備(DCE)のためのエラー修正手順を用いるデータ圧縮手順」、 http://www.itu.int/rec/T-REC-V.42bis 、1990年1月。

Gulbrandsen                 Standards Track                     [Page 7]

RFC 4978              The IMAP COMPRESS Extension            August 2007

IMAPが拡大2007年8月に圧縮するGulbrandsen標準化過程[7ページ]RFC4978

   [MNP]      Gilbert Held, "The Complete Modem Reference", Second
              Edition, Wiley Professional Computing, ISBN 0-471-00852-4,
              May 1994.

[MNP]ギルバートは0-471-00852-4と、1994年5月に「完全なモデム参照」、第2版、ワイリー専門家が計算することでのISBNを持っていました。

Author's Address

作者のアドレス

    Arnt Gulbrandsen
    Oryx Mail Systems GmbH
    Schweppermannstr. 8
    D-81671 Muenchen
    Germany

Arnt GulbrandsenオリックスメールシステムGmbH Schweppermannstr。 8 D-81671 Muenchenドイツ

    Fax: +49 89 4502 9758
    EMail: arnt@oryx.com

Fax: +49 89 4502 9758はメールされます: arnt@oryx.com

Gulbrandsen                 Standards Track                     [Page 8]

RFC 4978              The IMAP COMPRESS Extension            August 2007

IMAPが拡大2007年8月に圧縮するGulbrandsen標準化過程[8ページ]RFC4978

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

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

   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に情報を扱ってください。

Gulbrandsen                 Standards Track                     [Page 9]

Gulbrandsen標準化過程[9ページ]