RFC2061 日本語訳

Network Working Group                                         M. Crispin
Request for Comments: 2061                      University of Washington
Category: Informational                                    December 1996

コメントを求めるワーキンググループM.クリスピン要求をネットワークでつないでください: 2061年のワシントン大学カテゴリ: 情報の1996年12月

                   IMAP4 COMPATIBILITY WITH IMAP2BIS

IMAP2BISとのIMAP4の互換性

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Introduction

序論

   The Internet Message Access Protocol (IMAP) has been through several
   revisions and variants in its 10-year history.  Many of these are
   either extinct or extremely rare; in particular, several undocumented
   variants and the variants described in RFC 1064, RFC 1176, and RFC
   1203 fall into this category.

10年の歴史のいくつかの改正と異形を通してインターネットMessage Accessプロトコル(IMAP)がありました。 これらの多くが、消光しているか、または非常にまれです。 特に、いくつかの正式書類のない異形と異形はRFC1064、RFC1176、およびRFCで1203年の秋についてこのカテゴリに説明しました。

   One variant, IMAP2bis, is at the time of this writing very common and
   has been widely distributed with the Pine mailer.  Unfortunately,
   there is no definite document describing IMAP2bis.  This document is
   intended to be read along with RFC 1176 and the most recent IMAP4
   specification (RFC 2060) to assist implementors in creating an IMAP4
   implementation to interoperate with implementations that conform to
   earlier specifications.  Nothing in this document is required by the
   IMAP4 specification; implementors must decide for themselves whether
   they want their implementation to fail if it encounters old software.

1つの異形(IMAP2bis)が、この書くこと時点で、非常に一般的であり、Pine郵送者と共に広く分配されました。 残念ながら、IMAP2bisについて説明するどんな明確なドキュメントもありません。 以前の仕様に従う実装で共同利用するためにIMAP4実装を作成するのに作成者を助けるためにRFC1176と最新のIMAP4仕様(RFC2060)と共にこのドキュメントが読まれることを意図します。 何もIMAP4仕様によって本書では必要とされません。 それが古いソフトウェアに遭遇するなら彼らが、彼らの実装が失敗して欲しいか否かに関係なく、作成者は自分たちの有利な判決を下さなければなりません。

   At the time of this writing, IMAP4 has been updated from the version
   described in RFC 1730.  An implementor who wishes to interoperate
   with both RFC 1730 and RFC 2060 should refer to both documents.

この書くこと時点で、RFC1730で説明されたバージョンからIMAP4をアップデートしました。 RFC1730とRFC2060の両方で共同利用したがっている作成者は両方のドキュメントを参照するべきです。

   This information is not complete; it reflects current knowledge of
   server and client implementations as well as "folklore" acquired in
   the evolution of the protocol.  It is NOT a description of how to
   interoperate with all variants of IMAP, but rather with the old
   variant that is most likely to be encountered.  For detailed
   information on interoperating with other old variants, refer to RFC
   1732.

この情報は完全ではありません。 それはプロトコルの発展で取得された「民俗学」と同様にサーバとクライアント実装に関する現在の知識を反映します。 それはIMAPのすべての異形にもかかわらず、むしろ最も遭遇しそうな古い異形でどう共同利用するかに関する記述ではありません。 他の古い異形で共同利用することの詳細な情報について、RFC1732を参照してください。

IMAP4 client interoperability with IMAP2bis servers

IMAP2bisサーバがあるIMAP4クライアント相互運用性

   A quick way to check whether a server implementation supports the
   IMAP4 specification is to try the CAPABILITY command.  An OK response
   will indicate which variant(s) of IMAP4 are supported by the server.

サーバ実装が、IMAP4が仕様であるとサポートするかどうかチェックする迅速な方法はCAPABILITYコマンドを試みることです。 OK応答は、IMAP4のどの異形がサーバによってサポートされるかを示すでしょう。

Crispin                      Informational                      [Page 1]

RFC 2061                  IMAP4 Compatibility              December 1996

[1ページ]RFC2061IMAP4互換性1996年12月の情報のクリスピン

   If the client does not find any of its known variant in the response,
   it should treat the server as IMAP2bis.  A BAD response indicates an
   IMAP2bis or older server.

クライアントが応答で知られている異形のいずれも見つけないなら、それはIMAP2bisとしてサーバを扱うべきです。 BAD応答はIMAP2bisか、より古いサーバを示します。

   Most IMAP4 facilities are in IMAP2bis.  The following exceptions
   exist:

ほとんどのIMAP4施設がIMAP2bisにあります。 以下の例外は存在しています:

   CAPABILITY command
            The absense of this command indicates IMAP2bis (or older).

CAPABILITYは、このコマンドのabsenseが示すと命令します。IMAP2bisと(より古い。)です。

   AUTHENTICATE command.
            Use the LOGIN command.

AUTHENTICATEは命令します。 LOGINコマンドを使用してください。

   LSUB, SUBSCRIBE, and UNSUBSCRIBE commands
            No direct functional equivalent.  IMAP2bis had a concept
            called "bboards" which is not in IMAP4.  RFC 1176 supported
            these with the BBOARD and FIND BBOARDS commands.  IMAP2bis
            augmented these with the FIND ALL.BBOARDS, SUBSCRIBE BBOARD,
            and UNSUBSCRIBE BBOARD commands.  It is recommended that
            none of these commands be implemented in new software,
            including servers that support old clients.

LSUB、登録、登録削除。どんなダイレクト機能的な同等物も命令しません。 IMAP2bisには、IMAP4にない"bboards"と呼ばれる概念がありました。 RFC1176はBBOARDとFIND BBOARDSコマンドでこれらをサポートしました。 FIND ALL.BBOARDS、SUBSCRIBE BBOARD、およびUNSUBSCRIBE BBOARDコマンドによると、IMAP2bisはこれらを増大させました。 年取ったクライアントをサポートするサーバを含んでいて、これらのコマンドのいずれも新しいソフトウェアで実装されないのは、お勧めです。

   LIST command
            Use the command FIND ALL.MAILBOXES, which has a similar syn-
            tax and response to the FIND MAILBOXES command described in
            RFC 1176.  The FIND MAILBOXES command is unlikely to produce
            useful information.

LISTはUseコマンドFIND ALL.MAILBOXESを命令します。(FIND ALL.MAILBOXESはRFC1176で説明されたFIND MAILBOXESコマンドに同様のsyn税と応答を持っています)。 FIND MAILBOXESコマンドは役に立つ情報を作り出しそうにはありません。

   * in a sequence
            Use the number of messages in the mailbox from the EXISTS
            unsolicited response.

* EXISTSの求められていない応答からのメールボックスの中の系列Useのメッセージの数。

   SEARCH extensions (character set, additional criteria)
            Reformulate the search request using only the RFC 1176 syn-
            tax.  This may entail doing multiple searches to achieve the
            desired results.

RFC1176synだけを使用する検索が要求する検索拡大(文字集合、追加評価基準)Reformulateが課税します。 これは、望み通りの成果を獲得するために複数の検索をするのを伴うかもしれません。

   BODYSTRUCTURE fetch data item
            Use the non-extensible BODY data item.

BODYSTRUCTUREは非広げることができるBODYデータ項目をデータ項目Useにとって来ます。

   body sections HEADER, TEXT, MIME, HEADER.FIELDS, HEADER.FIELDS.NOT
            Use body section numbers only.

ボディーセクションHEADER、TEXT、MIME、HEADER.FIELDS、HEADER.FIELDS.NOT Useボディーセクション番号専用。

   BODY.PEEK[section]
            Use BODY[section] and manually clear the \Seen flag as
            necessary.

BODY.PEEK[セクション]はBODY[セクション]を使用して、手動でSeenが必要に応じて旗を揚げさせる\をクリアします。

Crispin                      Informational                      [Page 2]

RFC 2061                  IMAP4 Compatibility              December 1996

[2ページ]RFC2061IMAP4互換性1996年12月の情報のクリスピン

   FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items
            Use the corresponding non-SILENT versions and ignore the
            untagged FETCH responses which come back.

そして、FLAGS.SILENT、+ FLAGS.SILENT、および-FLAGS.SILENTがデータ項目Useの対応する非SILENTを保存する、バージョン、戻るuntagged FETCH応答を無視してください。

   UID fetch data item and the UID commands
            No functional equivalent.

UIDはデータ項目をとって来ます、そして、UIDはどんな機能的な同等物も命令しません。

   CLOSE command
            No functional equivalent.

CLOSEはどんな機能的な同等物も命令しません。

   In IMAP2bis, the TRYCREATE special information token is sent as a
   separate unsolicited OK response instead of inside the NO response.

IMAP2bisでは、いいえ応答の代わりに別々の求められていないOK応答としてTRYCREATEの特別な情報トークンを送ります。

   IMAP2bis is ambiguous about whether or not flags or internal dates
   are preserved on COPY.  It is impossible to know what behavior is
   supported by the server.

IMAP2bisは旗か内部の期日がCOPYに保持されるかどうかあいまいです。 どんな振舞いがサーバで後押しされているかを知るのは不可能です。

IMAP4 server interoperability with IMAP2bis clients

IMAP2bisクライアントがいるIMAP4サーバ相互運用性

   The only interoperability problem between an IMAP4 server and a
   well-written IMAP2bis client is an incompatibility with the use of
   "\" in quoted strings.  This is best avoided by using literals
   instead of quoted strings if "\" or <"> is embedded in the string.

IMAP4サーバと上手に書かれたIMAP2bisクライアントの間の唯一の相互運用性問題が引用文字列における「\」の使用がある不一致です。 これは「\」であるなら引用文字列の代わりにリテラルを使用することによって避けられたベストであるか<は「>はストリングに埋め込まれています」です。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Author's Address

作者のアドレス

   Mark R. Crispin
   Networks and Distributed Computing
   University of Washington
   4545 15th Aveneue NE
   Seattle, WA  98105-4527

マークR.クリスピンネットワークと分散コンピューティングのワシントン大学4545の第15Aveneue NEシアトル、ワシントン98105-4527

   Phone: (206) 543-5762
   EMail: MRC@CAC.Washington.EDU

以下に電話をしてください。 (206) 543-5762 メールしてください: MRC@CAC.Washington.EDU

Crispin                      Informational                      [Page 3]

クリスピンInformationalです。[3ページ]