RFC3502 日本語訳
3502 Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension.M. Crispin. March 2003. (Format: TXT=13379 bytes) (Updated by RFC4466, RFC4469) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Crispin Request for Comments: 3502 University of Washington Category: Standards Track March 2003
コメントを求めるワーキンググループM.クリスピン要求をネットワークでつないでください: 3502年のワシントン大学カテゴリ: 2003年の標準化過程行進
Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension
インターネットメッセージアクセス・プロトコル(IMAP)--MULTIAPPEND拡張子
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 (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document describes the multiappending extension to the Internet Message Access Protocol (IMAP) (RFC 3501). This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server.
このドキュメントはインターネットMessage Accessプロトコル(IMAP)(RFC3501)にマルチ追加拡大について説明します。 この拡大はIMAPクライアントのための一度にサーバで複数のメッセージをメールボックスにアップロードするかなりの性能改良を提供します。
A server which supports this extension indicates this with a capability name of "MULTIAPPEND".
この拡大を支持するサーバは能力名"MULTIAPPEND"でこれを示します。
Terminology
用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「」、「5月」、このドキュメントで「任意」は中[キーワード]で説明されるように解釈されることであるべきです。
Introduction
序論
The MULTIAPPEND extension permits uploading of multiple messages with a single command. When used in conjunction with the [LITERAL+] extension, the entire upload is accomplished in a single command/response round trip.
MULTIAPPEND拡張子はただ一つのコマンドによる複数のメッセージのアップロードを可能にします。 [LITERAL+]拡大に関連して使用されると、全体のアップロードはただ一つのコマンド/応答周遊旅行で実行されます。
A MULTIAPPEND APPEND operation is atomic; either all messages are successfully appended, or no messages are appended.
MULTIAPPEND APPEND操作は原子です。 首尾よくすべてのメッセージを追加するか、またはメッセージを全く追加しません。
In the base IMAP specification, each message must be appended in a separate command, and there is no mechanism to "unappend" messages if an error occurs while appending. Also, some mail stores may require
ベースIMAP仕様では、別々のコマンドで各メッセージを追加しなければなりません、そして、誤りが追加している間、発生するなら、"unappend"メッセージへのメカニズムが全くありません。 店が必要とするかもしれない何らかのメールも
Crispin Standards Track [Page 1] RFC 3502 IMAP MULTIAPPEND March 2003
クリスピンStandardsは2003年のIMAP MULTIAPPEND行進のときにRFC3502を追跡します[1ページ]。
an expensive "open/lock + sync/unlock/close" operation as part of appending; this can be quite expensive if it must be done on a per-message basis.
追加の一部としての高価な「戸外/錠+同時性/アンロック/近い」操作。 1メッセージあたり1個のベースでそれをしなければならないなら、これはかなり高価である場合があります。
If the server supports both LITERAL+ and pipelining but not MULTIAPPEND, it may be possible to get some of the performance advantages of MULTIAPPEND by doing a pipelined "batch" append. However, it will not work as well as MULTIAPPEND for the following reasons:
サーバがLITERAL+とMULTIAPPENDではなく、パイプライン処理の両方を支持するなら、pipelined「バッチ」をするのによるMULTIAPPENDの利点が追加する性能のいくつかを得るのは可能であるかもしれません。 しかしながら、以下の理由によるMULTIAPPENDと同様に、働かないでしょう:
1) Multiple APPEND commands, even as part of a pipelined batch,
are non-atomic by definition. There is no way to revert the
mailbox to the state before the batch append in the event of an
error.
1) pipelinedバッチの一部としてさえ、複数のAPPENDコマンドが定義上非原子です。 バッチの前の状態へのメールボックスが誤りの場合、追加する復帰者には道が全くありません。
2) It may not be feasible for the server to coalesce pipelined
APPEND operations so as to avoid the "open/lock +
sync/unlock/close" overhead described above. In any case, such
coalescing would be timing dependent and thus potentially
unreliable. In particular, with traditional UNIX mailbox files,
it is assumed that a lock is held only for a single atomic
operation, and many applications disregard any lock that is
older than 5 minutes.
2) サーバがpipelined APPEND操作を合体させるのは、上で説明された「戸外/錠+同時性/アンロック/近い」オーバーヘッドを避けるために可能でないかもしれません。 どのような場合でも、そのような合体は依存してその結果、潜在的に頼り無いタイミングです。 伝統的なUNIXメールボックスファイルで、特に、錠がただ一つの原子操作のためだけに持たれていると思われて、多くのアプリケーションが5分より古いどんな錠も無視します。
3) If an error occurs, depending upon the nature of the error,
it is possible for additional messages to be appended after the
error. For example, the user wants to append 5 messages, but a
disk quota error occurs with the third message because of its
size. However, the fourth and fifth messages have already been
sent in the pipeline, so the mailbox ends up with the first,
second, fourth, and fifth messages of the batch appended.
3) 誤りの本質によって、誤りが発生するなら、誤りの後に追加されるべき追加メッセージに、可能です。 例えば、ユーザは5つのメッセージを追加したがっていますが、ディスク・クオータ誤りはサイズのために3番目のメッセージで発生します。 しかしながら、パイプラインで既に4番目と5番目のメッセージを送ったので、メールボックスは1番目で4番目、およびバッチに関するメッセージが追加した5番目を2番目に、終わらせます。
6.3.11. APPEND Command
6.3.11. 追加コマンド
Arguments: mailbox name
one or more messages to upload, specified as:
OPTIONAL flag parenthesized list
OPTIONAL date/time string
message literal
議論: 以下として指定されたアップロードへの、よりメールボックスより多くの名1のメッセージ OPTIONAL旗は文字通りでリストOPTIONAL日付/時間ストリングメッセージをparenthesizedしました。
Data: no specific responses for this command
データ: このコマンドのための特定の応答がありません。
Result: OK - append completed
NO - append error: can't append to that mailbox, error
in flags or date/time or message text,
append cancelled
BAD - command unknown or arguments invalid
結果: OK--完成したノーを追加してください--誤りを追加してください: メールボックス、旗、日付/時間またはメッセージ・テキストにおける誤りをそれに追加して、取り消されたBADは追加できません--未知か議論病人を命令してください。
Crispin Standards Track [Page 2] RFC 3502 IMAP MULTIAPPEND March 2003
クリスピンStandardsは2003年のIMAP MULTIAPPEND行進のときにRFC3502を追跡します[2ページ]。
The APPEND command appends the literal arguments as new messages
to the end of the specified destination mailbox. This argument
SHOULD be in the format of an [RFC-2822] message. 8-bit
characters are permitted in the message. A server implementation
that is unable to preserve 8-bit data properly MUST be able to
reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB]
content transfer encoding.
APPENDコマンドは新しいメッセージとして指定されたあて先メールボックスの端に文字通りの議論を追加します。 この議論SHOULDは[RFC-2822]メッセージの形式においてそうです。 8ビットのキャラクタはメッセージで受入れられます。 適切に8ビットのデータを保存できないサーバ実現はreversiblyに[MIME-IMB]内容を使用する7ビット転送コード化に8ビットのAPPENDデータを変換できなければなりません。
Note: There MAY be exceptions, e.g., draft messages, in
which required [RFC-2822] header lines are omitted in the
message literal argument to APPEND. The full implications
of doing so MUST be understood and carefully weighed.
以下に注意してください。 例外、例えば草稿メッセージがあるかもしれません。そこでは、必要な[RFC-2822]ヘッダー線がメッセージの文字通りの議論でAPPENDに省略されます。 そうする完全な含意を理解されて、慎重に熟慮しなければなりません。
If a flag parenthesized list is specified, the flags SHOULD be set
in the resulting message; otherwise, the flag list of the
resulting message is set empty by default.
旗がparenthesizedされたなら、リストは指定されて、旗はSHOULDです。結果として起こるメッセージに設定されてください。 さもなければ、結果として起こるメッセージに関する現役将官名簿はデフォルトで空の状態で設定されます。
If a date-time is specified, the internal date SHOULD be set in
the resulting message; otherwise, the internal date of the
resulting message is set to the current date and time by default.
日付-時間が指定されるなら、インターナルは中のセットが結果として起こるメッセージであったならSHOULDとデートします。 さもなければ、結果として起こるメッセージの内部の期日はデフォルトで現在の期日と時間に決められます。
A zero-length message literal argument is an error, and MUST
return a NO. This can be used to cancel the append.
ゼロ・レングスのメッセージの文字通りの議論は、誤りであり、NO.を返さなければなりません。 取り消すのにこれを使用できる、追加します。
If the append is unsuccessful for any reason (including being
cancelled), the mailbox MUST be restored to its state before the
APPEND attempt; no partial appending is permitted. The server MAY
return an error before processing all the message arguments.
追加、どんな理由(取り消されるのを含んでいる)でも失敗しています、APPEND試みの前にメールボックスを状態に返さなければならないということです。 部分的な追加は受入れられません。 すべてのメッセージ議論を処理する前に、サーバは誤りを返すかもしれません。
If the destination mailbox does not exist, a server MUST return an
error, and MUST NOT automatically create the mailbox. Unless it
is certain that the destination mailbox can not be created, the
server MUST send the response code "[TRYCREATE]" as the prefix of
the text of the tagged NO response. This gives a hint to the
client that it can attempt a CREATE command and retry the APPEND
if the CREATE is successful.
あて先メールボックスが存在していないなら、サーバは、誤りを返さなければならなくて、自動的にメールボックスを作成してはいけません。 あて先メールボックスを作成できないのが確かでない場合、サーバはタグ付けをされたいいえ応答のテキストの接頭語として「[TRYCREATE]」という応答コードを送らなければなりません。 これはCREATEがうまくいくなら、CREATEコマンドを試みて、APPENDを再試行できるというクライアントへのヒントを与えます。
If the mailbox is currently selected, the normal new message
actions SHOULD occur. Specifically, the server SHOULD notify the
client immediately via an untagged EXISTS response. If the server
does not do so, the client MAY issue a NOOP command (or failing
that, a CHECK command) after one or more APPEND commands.
メールボックスが現在選択されるなら、正常な新しいメッセージ動作SHOULDは起こります。 明確に、すぐuntagged EXISTS応答でサーバSHOULDはクライアントに通知します。 サーバがそうしないなら、1APPENDが命令した後にクライアントはNOOPコマンド(または、それに失敗するCHECKコマンド)を発行するかもしれません。
Crispin Standards Track [Page 3] RFC 3502 IMAP MULTIAPPEND March 2003
クリスピンStandardsは2003年のIMAP MULTIAPPEND行進のときにRFC3502を追跡します[3ページ]。
Example: C: A003 APPEND saved-messages (\Seen) {329}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.example.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.example.net
C: Message-Id: <B27397-0100000@Blurdybloop.example.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: (\Seen) " 7-Feb-1994 22:43:04 -0800" {295}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST)
C: From: Joe Mooch <mooch@OWaTaGu.example.net>
C: Subject: Re: afternoon meeting
C: To: foobar@blurdybloop.example.com
C: Message-Id: <a0434793874930@OWaTaGu.example.net>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: 3:30 is fine with me.
C:
S: A003 OK APPEND completed
C: A004 APPEND bogusname (\Flagged) {1023}
S: A004 NO [TRYCREATE] No such mailbox as bogusname
C: A005 APPEND test (\Flagged) {99}
S: + Ready for literal data
C: Date: Mon, 7 Feb 2000 22:43:04 -0800 (PST)
C: From: Fred Foobar <fred@example.com>
C: Subject: hmm...
C: {35403}
S: A005 NO APPEND failed: Disk quota exceeded
例: C: A003 APPEND救われたメッセージ(\Seen)329S: +は文字通りのデータのためにCを準備します: 日付: 月曜日、1994年2月7日21:52:25 -0800(太平洋標準時の)のC: From: フレッド Foobar <foobar@Blurdybloop.example.COM 、gt;、C: Subject: 午後のミーティングC: To: mooch@owatagu.example.net C: メッセージイド: <B27397-0100000@Blurdybloop.example.COM>C: MIMEバージョン: 1.0C: コンテントタイプ: テキスト/平野。 CHARSETは米国のASCII Cと等しいです: C: こんにちは、ジョー、あなたは私たちが明日の3:30に会うことができると思いますか? C: (見られた\) 「1994年2月7日22:43:04 -0800」295、S: +は文字通りのデータのためにCを準備します: 日付: 月曜日、1994年2月7日22:43:04 -0800(太平洋標準時の)のC: From: ジョー Mooch <mooch@OWaTaGu.example.net 、gt;、C: Subject: Re: 午後のミーティングC: To: foobar@blurdybloop.example.com C: メッセージイド: <a0434793874930@OWaTaGu.example.net>C: MIMEバージョン: 1.0C: コンテントタイプ: テキスト/平野。 CHARSETは米国のASCII Cと等しいです: C: 3:30は大丈夫です。 C: S: A003 OK APPENDはCを完成しました: A004 APPEND bogusname(\Flagged)1023S: bogusname CとしてのA004 NO[TRYCREATE]のいいえのそのようなメールボックス: A005 APPENDは(\Flagged)99Sをテストします: +は文字通りのデータのためにCを準備します: 日付: 月曜日、2000年2月7日22:43:04 -0800(太平洋標準時の)のC: From: フレッド Foobar <fred@example.com 、gt;、C: Subject: ふむ… C: 35403、S: A005 NO APPENDは失敗しました: 超えられていたディスク・クオータ
Note: The APPEND command is not used for message delivery,
because it does not provide a mechanism to transfer [SMTP]
envelope information.
以下に注意してください。 APPENDコマンドはメッセージ配送に使用されません、[SMTP]封筒情報を移すためにメカニズムを提供しないので。
Modification to IMAP4rev1 Base Protocol Formal Syntax
IMAP4rev1の基地のプロトコルの正式な構文への変更
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
以下の構文仕様は[ABNF]の指定されるとしてのAugmented BN記法(ABNF)記法を使用します。
append = "APPEND" SP mailbox 1*append-message
SPメールボックス1*が追加する=「追加」を追加してください、-通信してください。
append-message = [SP flag-list] [SP date-time] SP literal
メッセージを追加している=[SP現役将官名簿][SP日付-時間]SP文字通りです。
Crispin Standards Track [Page 4] RFC 3502 IMAP MULTIAPPEND March 2003
クリスピンStandardsは2003年のIMAP MULTIAPPEND行進のときにRFC3502を追跡します[4ページ]。
MULTIAPPEND Interaction with UIDPLUS Extension
UIDPLUS拡張子とのMULTIAPPEND相互作用
Servers which support both MULTIAPPEND and [UIDPLUS] will have the "resp-code-apnd" rule modified as follows:
MULTIAPPENDと[UIDPLUS]の両方を支持するサーバで、以下の通り「respコードapnd」規則を変更するでしょう:
resp-code-apnd = "APPENDUID" SP nz-number SP set
respコードapndはSPが設定する"APPENDUID"SP nz-番号と等しいです。
That is, the APPENDUID response code returns as many UIDs as there were messages appended in the multiple append. The UIDs returned should be in the order the articles where appended. The message set may not contain extraneous UIDs or the symbol "*".
すなわち、応答コードが追加されたメッセージがあったのと同じくらい多くのUIDsを返す倍数が追加するAPPENDUID。 オーダーでは、返されたUIDsは追加されているところの記事であるべきです。 メッセージセットは「*」という異質なUIDsかシンボルを含まないかもしれません。
Security Considerations
セキュリティ問題
The MULTIAPPEND extension does not raise any security considerations that are not present in the base [IMAP] protocol, and these issues are discussed in [IMAP]. Nevertheless, it is important to remember that IMAP4rev1 protocol transactions, including electronic mail data, are sent in the clear over the network unless protection from snooping is negotiated, either by the use of STARTTLS, privacy protection is negotiated in the AUTHENTICATE command, or some other protection mechanism is in effect.
MULTIAPPEND拡張子はどんなベース[IMAP]プロトコルで存在していないセキュリティ問題も提起しません、そして、[IMAP]でこれらの問題について議論します。 それにもかかわらず、詮索からの保護が交渉されない場合電子メールデータを含むIMAP4rev1プロトコル取引がネットワークの上の明確で送られたのを覚えているのが重要である、STARTTLSの使用で、プライバシー保護がAUTHENTICATEコマンドで交渉されるか、またはある他の保護メカニズムは有効です。
Normative References
引用規格
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[IMAP] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, March 2003.
[IMAP] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」
[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月。
[MIME-IMB] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet
Mail Extensions) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
解放された[MIME-IMB]、N.、およびN.Borenstein、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[RFC-2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
Crispin Standards Track [Page 5] RFC 3502 IMAP MULTIAPPEND March 2003
クリスピンStandardsは2003年のIMAP MULTIAPPEND行進のときにRFC3502を追跡します[5ページ]。
Informative References
有益な参照
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
January 1997.
[LITERAL+] マイアーズ、J.、「IMAP4非連動誤字誤植」、RFC2088、1997年1月。
[UIDPLUS] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1988.
[UIDPLUS]マイアーズ、J.、「IMAP4 UIDPLUS拡張子」、RFC2359、1988年6月。
[SMTP] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC
2821, April 2001.
[SMTP] Klensin、J.、エディタ、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
Author's Address
作者のアドレス
Mark R. Crispin Networks and Distributed Computing University of Washington 4545 15th Avenue NE Seattle, WA 98105-4527
マークR.クリスピンネットワークと第15分散コンピューティングワシントン大学4545アベニューNeシアトル、ワシントン98105-4527
Phone: (206) 543-5762 EMail: MRC@CAC.Washington.EDU
以下に電話をしてください。 (206) 543-5762 メールしてください: MRC@CAC.Washington.EDU
Crispin Standards Track [Page 6] RFC 3502 IMAP MULTIAPPEND March 2003
クリスピンStandardsは2003年のIMAP MULTIAPPEND行進のときにRFC3502を追跡します[6ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Crispin Standards Track [Page 7]
クリスピン標準化過程[7ページ]
一覧
スポンサーリンク
