RFC2359 日本語訳

Network Working Group                                           J. Myers
Request for Comments: 2359                       Netscape Communications
Category: Standards Track                                      June 1998

コメントを求めるワーキンググループJ.マイアーズの要求をネットワークでつないでください: 2359年のネットスケープ・コミュニケーションズカテゴリ: 標準化過程1998年6月

                        IMAP4 UIDPLUS extension

IMAP4 UIDPLUS拡張子

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

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

IESG NOTE

IESG注意

   The IMAP extension described here assumes a particular means of using
   IMAP to support disconnected operation.  However, this means of
   supporting disconnected operation is not yet documented.  Also, there
   are multiple theories about how best to do disconnected operation in
   IMAP, and as yet, there is no consensus on which one should be
   adopted as a standard.

ここで説明されたIMAP拡張子は操作であると切断されたサポートにIMAPを使用する特定の手段を仮定します。 しかしながら、操作であると切断されたサポートすることのこの手段はまだ記録されていません。 また、規格として採用されるべきである尽くすベストがIMAPで操作から切断して、まだ、どんなオンであるコンセンサスもどうないかに関する複数の理論があります。

   This document is being approved as a Proposed Standard because it
   does not appear to have technical flaws in itelf.  However, approval
   of this document as a Proposed Standard should not be considered an
   IETF endorsement of any particular means of doing disconnected
   operation in IMAP.

itelfに技術的な欠点を持っているように見えないので、このドキュメントはProposed Standardとして承認されています。 しかしながら、IMAPでの操作であると切断されたすることのどんな特定の手段のIETF裏書きであるともProposed Standardとしてのこのドキュメントの承認を考えるべきではありません。

Table of Contents

目次

   1.   Abstract ..............................................    2
   2.   Conventions Used in this Document .....................    2
   3.   Introduction and Overview .............................    2
   4.   Features ..............................................    2
   4.1. UID EXPUNGE Command ...................................    2
   4.2. APPENDUID response code ...............................    3
   4.3. COPYUID response code .................................    4
   5.   Formal Syntax .........................................    4
   6.   References ............................................    4
   7.   Security Considerations ...............................    5
   8.   Author's Address ......................................    5
   9.   Full Copyright Statement ..............................    6

1. 要約… 2 2. このDocumentのコンベンションUsed… 2 3. 序論と概要… 2 4. 特徴… 2 4.1. UIDはコマンドを梢消します… 2 4.2. APPENDUID応答コード… 3 4.3. COPYUID応答コード… 4 5. 正式な構文… 4 6. 参照… 4 7. セキュリティ問題… 5 8. 作者のアドレス… 5 9. 完全な著作権宣言文… 6

Myers                       Standards Track                     [Page 1]

RFC 2359                IMAP4 UIDPLUS extension                June 1998

マイアーズStandards Track[1ページ]RFC2359IMAP4 UIDPLUS拡張子1998年6月

1.   Abstract

1. 要約

   The UIDPLUS extension of the Internet Message Access Protocol [IMAP4]
   provides a set of features intended to reduce the amount of time and
   resources used by some client operations.  The features in UIDPLUS
   are primarily intended for disconnected-use clients.

インターネットMessage Accessプロトコル[IMAP4]のUIDPLUS拡張子はいくつかのクライアント操作で時間と運用資金を短縮することを意図する1セットの特徴を提供します。 UIDPLUSの特徴は切断している使用クライアントのために主として意図します。

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:」 クライアントとサーバによってそれぞれ送られた系列を示してください。

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as defined in "Key words for
   use in RFCs to Indicate Requirement Levels" [KEYWORDS].

キーワード“MUST"、「必須NOT」“SHOULD"、「」 「5月」は「RFCsにおける使用が要件レベルを示すキーワード」[キーワード]で定義されるように本書では解釈されることになっているべきです。

3.   Introduction and Overview

3. 序論と概要

   The UIDPLUS extension is present in any IMAP4 server implementation
   which returns "UIDPLUS" as one of the supported capabilities to the
   CAPABILITY command.  The UIDPLUS extension contains one additional
   command and additional data returned with successful APPEND and COPY
   commands.

UIDPLUS拡張子はサポートしている能力の1つとして「UIDPLUS」を能力コマンドに返すどんなIMAP4サーバ実装でも存在しています。 UIDPLUS拡張子はうまくいっているAPPENDとCOPYコマンドと共に返された1つの追加コマンドと追加データを含んでいます。

   Clients that wish to use the new command in UIDPLUS must of course
   first test for the presence of the extension by issuing a CAPABILITY
   command.  Each of the features in UIDPLUS are optimizations; clients
   can provide the same functionality, albeit more slowly, by using
   commands in the base protocol.  With each feature, this document
   recommends a fallback approach to take when the UIDPLUS extension is
   not supported by the server.

UIDPLUSの新しいコマンドを使用したがっているクライアントは、最初に、もちろん拡大の存在がないかどうかCAPABILITYコマンドを発行することによって、テストしなければなりません。 UIDPLUSのそれぞれの特徴は最適化です。 よりゆっくりですが、クライアントは、ベースプロトコルにコマンドを使用することによって、同じように機能性を提供できます。 UIDPLUS拡張子がサーバによってサポートされないとき、各特徴で、このドキュメントは、後退アプローチが取ることを勧めます。

4.   Features

4. 特徴

4.1. UID EXPUNGE Command

4.1. UID梢消コマンド

   Arguments:  message set

議論: メッセージセット

   Data:       untagged responses: EXPUNGE

データ: 非タグ付けをされた応答: 梢消します。

   Result:     OK - expunge completed
               NO - expunge failure (e.g. permission denied)
               BAD - command unknown or arguments invalid

結果: OK--完成したノーを梢消してください--失敗(例えば否定された許可)BADを梢消してください--未知か議論病人を命令してください。

Myers                       Standards Track                     [Page 2]

RFC 2359                IMAP4 UIDPLUS extension                June 1998

マイアーズStandards Track[2ページ]RFC2359IMAP4 UIDPLUS拡張子1998年6月

      The UID EXPUNGE command permanently removes from the currently
      selected mailbox all messages that both have the \Deleted flag set
      and have a UID that is included in the specified message set.  If
      a message either does not have the \Deleted flag set or is has a
      UID that is not included in the specified message set, it is not
      affected.

UID EXPUNGEコマンドは永久に、現在選択されたメールボックスから両方がDeleted旗が設定した\を持っていて、指定されたメッセージセットに含まれているUIDを持っているというすべてのメッセージを取り除きます。 どちらかはDeleted旗が設定した\を持っていないか、またはあるというメッセージが指定されたメッセージセットに含まれていないUIDを持っているなら、影響を受けません。

      This command may be used to ensure that a replayed EXPUNGE command
      does not remove any messages that have been marked as \Deleted
      between the time that the user requested the expunge operation and
      the time the server processes the command.

このコマンドが再演されたEXPUNGEコマンドが\Deletedとしてユーザが要求した時間の間でマークされたどんなメッセージも取り除かないのを保証するのに使用されるかもしれない、サーバがコマンドを処理する操作と時を梢消してください。

      If the server does not support the UIDPLUS capability, the client
      should fall back to using the STORE command to temporarily remove
      the \Deleted flag from messages it does not want to remove.  The
      client could alternatively fall back to using the EXPUNGE command,
      risking the unintended removal of some messages.

サーバが、UIDPLUSが能力であるとサポートしないなら、クライアントは一時Deletedがそれが取り除きたがっていないメッセージから旗を揚げさせる\を取り除くストアコマンドを使用することへ後ろへ下がるべきです。 あるいはまた、クライアントはいくつかのメッセージの故意でない取り外しを危険にさらして、EXPUNGEコマンドを使用することへ後ろへ下がることができました。

   Example:    C: A003 UID EXPUNGE 3000:3002
               S: * 3 EXPUNGE
               S: * 3 EXPUNGE
               S: * 3 EXPUNGE
               S: A003 OK UID EXPUNGE completed

例: C: A003 UIDは: 3002秒間、3000を梢消します: * 3 Sを梢消してください: * 3 Sを梢消してください: * 3 Sを梢消してください: 完成したA003 OK UID EXPUNGE

4.2. APPENDUID response code

4.2. APPENDUID応答コード

   Successful APPEND commands return an APPENDUID response code in the
   tagged OK response.  The APPENDUID response code contains as
   arguments the UIDVALIDITY of the destination mailbox and the UID
   assigned to the appended message.

うまくいっているAPPENDコマンドはタグ付けをされたOK応答におけるAPPENDUID応答コードを返します。 APPENDUID応答コードは議論としてあて先メールボックスのUIDVALIDITYと追加されたメッセージに割り当てられたUIDを含んでいます。

   If the server does not support the UIDPLUS capability, the client can
   only discover this information by selecting the destination mailbox
   and issuing FETCH commands.

サーバが、UIDPLUSが能力であるとサポートしないなら、クライアントは、あて先メールボックスを選択して、FETCHにコマンドを発行することによって、この情報を発見できるだけです。

   Example:    C: A003 APPEND saved-messages (\Seen) {310}
               C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
               C: From: Fred Foobar <foobar@Blurdybloop.COM>
               C: Subject: afternoon meeting
               C: To: mooch@owatagu.siam.edu
               C: Message-Id: <B27397-0100000@Blurdybloop.COM>
               C: MIME-Version: 1.0
               C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
               C:
               C: Hello Joe, do you think we can meet at 3:30 tomorrow?
               C:
               S: A003 OK [APPENDUID 38505 3955] APPEND completed

例: C: A003 APPENDの保存しているメッセージ(\Seen)310C: 日付: 月曜日、1994年2月7日21:52:25 -0800(太平洋標準時の)のC: From: フレッド Foobar <foobar@Blurdybloop.COM 、gt;、C: Subject: 午後のミーティングC: To: mooch@owatagu.siam.edu C: メッセージイド: <B27397-0100000@Blurdybloop.COM>C: MIMEバージョン: 1.0C: コンテントタイプ: テキスト/平野。 CHARSETは米国のASCII Cと等しいです: C: こんにちは、ジョー、あなたは私たちが明日の3:30に会うことができると思いますか? C: S: 完成したA003 OK[APPENDUID38505 3955]APPEND

Myers                       Standards Track                     [Page 3]

RFC 2359                IMAP4 UIDPLUS extension                June 1998

マイアーズStandards Track[3ページ]RFC2359IMAP4 UIDPLUS拡張子1998年6月

4.3. COPYUID response code

4.3. COPYUID応答コード

   Successful COPY and UID COPY commands return a COPYUID response code
   in the tagged OK response whenever at least one message was copied.
   The COPYUID response code contains as an argument the UIDVALIDITY of
   the appended-to mailbox, a message set containing the UIDs of the
   messages copied to the destination mailbox, in the order they were
   copied, and a message containing the UIDs assigned to the copied
   messages, in the order they were assigned.  Neither of the message
   sets may contain extraneous UIDs or the symbol '*'.

少なくとも1つのメッセージがコピーされたときはいつも、うまくいっているCOPYとUID COPYコマンドはタグ付けをされたOK応答におけるCOPYUID応答コードを返します。 コードが添えているメールボックスのUIDVALIDITY、あて先メールボックスにコピーされたメッセージのUIDsを含んでいて、メッセージがセットして、オーダーでは、それらがコピーされたという主張、およびコピーされたメッセージに割り当てられたUIDsを含むメッセージとして含むCOPYUID応答、オーダーでは、それらは割り当てられました。 メッセージセットのどちらも'*'という異質なUIDsかシンボルを含まないかもしれません。

   If the server does not support the UIDPLUS capability, the client can
   only discover this information by selecting the destination mailbox
   and issuing FETCH commands.

サーバが、UIDPLUSが能力であるとサポートしないなら、クライアントは、あて先メールボックスを選択して、FETCHにコマンドを発行することによって、この情報を発見できるだけです。

   Example:    C: A003 COPY 2:4 MEETING
               S: A003 OK [COPYUID 38505 304,319:320 3956:3958] Done
               C: A003 UID COPY 305:310 MEETING
               S: A003 OK Done

例: C: A003は2:4ミーティングSをコピーします: A003が承認する、[COPYUID38505 304,319: 320 3956: 3958] Cをします: A003 UIDコピー305: 310 ミーティングS: 行われたA003OK

5.   Formal Syntax

5. 正式な構文

   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]によって定義されるように参照をつけられましたが、以下で定義されなかった非端末があります。

   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.

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

   resp_code_apnd  ::= "APPENDUID" SPACE nz_number SPACE uniqueid

resp_コード_は以下をapndします:= "APPENDUID"SPACE nz_番号SPACE uniqueid

   resp_code_copy  ::= "COPYUID" SPACE nz_number SPACE set SPACE set

resp_コード_は以下をコピーします:= "COPYUID"SPACE nz_番号SPACEセットSPACEはセットしました。

   uid_expunge     ::= "UID" SPACE "EXPUNGE" SPACE set

uid_は以下を梢消します:= "UID"SPACEはスペースセットを「梢消します」。

6.   References

6. 参照

   [IMAP4]    Crispin, M., "Internet Message Access Protocol -
              Version 4rev1", RFC 2060, December 1996.

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

   [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月。

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

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

Myers                       Standards Track                     [Page 4]

RFC 2359                IMAP4 UIDPLUS extension                June 1998

マイアーズStandards Track[4ページ]RFC2359IMAP4 UIDPLUS拡張子1998年6月

7.   Security Considerations

7. セキュリティ問題

   There are no known security issues with this extension.

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

8.   Author's Address

8. 作者のアドレス

   John Gardiner Myers
   Netscape Communications
   501 East Middlefield Road
   Mail Stop MV-029
   Mountain View, CA  94043

マウンテンビュー、ジョンガーディナーマイアーズネットスケープ・コミュニケーションズ501の東Middlefield道路メール停止MV-029カリフォルニア 94043

   EMail: jgmyers@netscape.com

メール: jgmyers@netscape.com

Myers                       Standards Track                     [Page 5]

RFC 2359                IMAP4 UIDPLUS extension                June 1998

マイアーズStandards Track[5ページ]RFC2359IMAP4 UIDPLUS拡張子1998年6月

9.  Full Copyright Statement

9. 完全な著作権宣言文

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Myers                       Standards Track                     [Page 6]

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