RFC2088 日本語訳

Network Working Group                                           J. Myers
Request for Comments: 2088                               Carnegie Mellon
Cateogry: Standards Track                                   January 1997

コメントを求めるワーキンググループJ.マイアーズの要求をネットワークでつないでください: 2088カーネギーメロンCateogry: 標準化過程1997年1月

                    IMAP4 non-synchronizing literals

IMAP4非連動リテラル

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

1.   Abstract

1. 要約

   The Internet Message Access Protocol [IMAP4] contains the "literal"
   syntactic construct for communicating strings.  When sending a
   literal from client to server, IMAP4 requires the client to wait for
   the server to send a command continuation request between sending the
   octet count and the string data.  This document specifies an
   alternate form of literal which does not require this network round
   trip.

インターネットMessage Accessプロトコル[IMAP4]はストリングを伝えるための構文の「文字通り」の構造物を含んでいます。 クライアントからサーバにリテラルを送るとき、IMAP4は、クライアントが、八重奏カウントと列データを送ることの間にサーバがコマンド継続要求を送るのを待つのを必要とします。 このドキュメントは旅行の周りでこのネットワークを必要としない代替のフォームのリテラルを指定します。

2.   Conventions Used in this Document

2. このDocumentのコンベンションUsed

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

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

3.   Specification

3. 仕様

   The non-synchronizing literal is added an alternate form of literal,
   and may appear in communication from client to server instead of the
   IMAP4 form of literal.  The IMAP4 form of literal, used in
   communication from client to server, is referred to as a
   synchronizing literal.

非連動リテラルが加えられて、補欠が形成するということである、リテラル、リテラルのIMAP4フォームの代わりにコミュニケーションにクライアントからサーバまで現れるかもしれません。 クライアントからサーバまでのコミュニケーションで使用されるリテラルのIMAP4書式は連動リテラルと呼ばれます。

   Non-synchronizing literals may be used with any IMAP4 server
   implementation which returns "LITERAL+" as one of the supported
   capabilities to the CAPABILITY command.  If the server does not
   advertise the LITERAL+ capability, the client must use synchronizing
   literals instead.

非連動リテラルはサポートしている能力の1つとして「リテラル+」を能力コマンドに返すどんなIMAP4サーバ実装と共にも使用されるかもしれません。 サーバがLITERAL+能力の広告を出さないなら、クライアントは代わりに連動リテラルを使用しなければなりません。

   The non-synchronizing literal is distinguished from the original
   synchronizing literal by having a plus ('+') between the octet count
   and the closing brace ('}').  The server does not generate a command
   continuation request in response to a non-synchronizing literal, and

非連動リテラルは、オリジナルの連動リテラルと八重奏カウントと終わりの支柱('}')の間のプラス('+')を持っていることによって、区別されます。 そしてサーバが非連動リテラルに対応してコマンド継続要求を生成しない。

Myers                       Standards Track                     [Page 1]

RFC 2088                        LITERAL                     January 1997

マイアーズ規格は1997年1月にRFC2088リテラルを追跡します[1ページ]。

   clients are not required to wait before sending the octets of a non-
   synchronizing literal.

非連動しているリテラルの八重奏を送る前に、クライアントは待つ必要はありません。

   The protocol receiver of an IMAP4 server must check the end of every
   received line for an open brace ('{') followed by an octet count, a
   plus ('+'), and a close brace ('}') immediately preceeding the CRLF.
   If it finds this sequence, it is the octet count of a non-
   synchronizing literal and the server MUST treat the specified number
   of following octets and the following line as part of the same
   command.  A server MAY still process commands and reject errors on a
   line-by-line basis, as long as it checks for non-synchronizing
   literals at the end of each line.

IMAP4サーバのプロトコル受信機が開きの中括弧がないかどうかあらゆる容認された行の終わりをチェックしなければならない、('、'、)、すぐにCRLFをpreceedingしながら八重奏カウント、プラス('+')、および近い支柱('}')に従った、' この系列を見つけるなら、それは非連動しているリテラルの八重奏カウントです、そして、サーバは同じコマンドの一部として八重奏と以下の系列に続く指定された数を扱わなければなりません。 サーバは、まだコマンドを処理していて、1行ずつベースで誤りを拒絶するかもしれません、それぞれの行の終わりの非連動リテラルがないかどうかチェックする限り。

   Example:    C: A001 LOGIN {11+}
               C: FRED FOOBAR {7+}
               C: fat man
               S: A001 OK LOGIN completed

例: C: A001ログイン11+、C: フレッドFOOBAR7+、C: 太った男の人S: 完成したA001 OK LOGIN

4.   Formal Syntax

4. 正式な構文

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
   Non-terminals referenced but not defined below are as defined by
   [IMAP4].

以下の構文仕様は変更されるとしての[RFC-822]ごとの指定されるとしての増大しているBN記法(BNF)記法を使用します。 [IMAP4]によって定義されるように参照をつけられましたが、以下で定義されなかった非端末があります。

   literal         ::= "{" number ["+"] "}" CRLF *CHAR8
                       ;; Number represents the number of CHAR8 octets

リテラル:、:= 「「数[「+」]」」CRLF*CHAR8。 数はCHAR8八重奏の数を表します。

6.   References

6. 参照

   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
   draft-crispin-imap-base-XX.txt, University of Washington, April 1996.

[IMAP4] クリスピン、M.、「バージョン4インチ、草稿crispin-imapベースXX.txt、ワシントン大学、1996年インターネットメッセージアクセス・プロトコル--4月。」

   [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
   Messages", STD 11, RFC 822.

[RFC-822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822。

7.   Security Considerations

7. セキュリティ問題

   There are no known security issues with this extension.

この拡大の安全保障問題は知られていません。

8.   Author's Address

8. 作者のアドレス

   John G. Myers
   Carnegie-Mellon University
   5000 Forbes Ave.
   Pittsburgh PA, 15213-3890

ジョンG.マイアーズカーネギーメロン大学5000フォーブズAve。 ピッツバーグPA、15213-3890

   Email: jgm+@cmu.edu

メール: jgm+@cmu.edu

Myers                       Standards Track                     [Page 2]

マイアーズ標準化過程[2ページ]