RFC4469 日本語訳

Network Working Group                                         P. Resnick
Request for Comments: 4469                         QUALCOMM Incorporated
Updates: 3501, 3502                                           April 2006
Category: Standards Track

コメントを求めるワーキンググループP.レズニックの要求をネットワークでつないでください: 4469のクアルコムの法人組織のアップデート: 3501、3502年2006年4月のカテゴリ: 標準化過程

       Internet Message Access Protocol (IMAP) CATENATE Extension

インターネットメッセージアクセス・プロトコル(IMAP)カテナート拡大

Status of This 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 (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   The CATENATE extension to the Internet Message Access Protocol (IMAP)
   extends the APPEND command to allow clients to create messages on the
   IMAP server that may contain a combination of new data along with
   parts of (or entire) messages already on the server.  Using this
   extension, the client can catenate parts of an already existing
   message onto a new message without having to first download the data
   and then upload it back to the server.

インターネットMessage AccessプロトコルへのCATENATE拡張子がクライアントが部品に伴う新しいデータの組み合わせを含むかもしれないIMAPサーバにメッセージを作成するのを許容するAPPENDコマンドを広げている、(IMAP)(全体)、既に、サーバでは、最初に、データをダウンロードして、次に、それをサーバにアップロードして戻す必要はなくて. この拡張子を使用するクライアント缶のカテナートの部品を既に既存のメッセージについて新しいメッセージへ通信させます。

Resnick                     Standards Track                     [Page 1]

RFC 4469                IMAP CATENATE Extension               April 2006

レズニックStandardsはIMAPカテナート拡大2006年4月にRFC4469を追跡します[1ページ]。

1.  Introduction

1. 序論

   The CATENATE extension to the Internet Message Access Protocol (IMAP)
   [1] allows the client to create a message on the server that can
   include the text of messages (or parts of messages) that already
   exist on the server without having to FETCH them and APPEND them back
   to the server.  The CATENATE extension extends the APPEND command so
   that, instead of a single message literal, the command can take as
   arguments any combination of message literals (as described in IMAP
   [1]) and message URLs (as described in the IMAP URL Scheme [2]
   specification).  The server takes all the pieces and catenates them
   into the output message.  The CATENATE extension can also coexist
   with the MULTIAPPEND extension [3] to APPEND multiple messages in a
   single command.

インターネットMessage Accessプロトコル(IMAP)1へのCATENATE拡張子はサーバに既にFETCHにそれらを持っていなくて存在するメッセージ(または、メッセージの部分)のテキストを含むことができるサーバにメッセージを作成するクライアントとAPPENDにサーバへのそれらを許容します; CATENATE拡張子は、コマンドがただ一つのメッセージリテラルの代わりに議論としてメッセージリテラル(IMAP1で説明されるように)とメッセージURLのどんな組み合わせもみなすことができる(IMAP URL Scheme2仕様で説明されるように)ように、APPENDコマンドを広げています。 サーバはすべての断片とカテナートで取ります。出力メッセージへのそれら。 また、CATENATE拡張子はシングルにおける複数のメッセージが命令するAPPENDにMULTIAPPEND拡張子[3]と共存できます。

   There are some obvious uses for the CATENATE extension.  The
   motivating use case was to provide a way for a resource-constrained
   client to compose a message for subsequent submission that contains
   data that already exists in that client's IMAP store.  Because the
   client does not have to download and re-upload potentially large
   message parts, bandwidth and processing limitations do not have as
   much impact.  In addition, since the client can create a message in
   its own IMAP store, the command also addresses the desire of the
   client to archive a copy of a sent message without having to upload
   the message twice.  (Mechanisms for sending the message are outside
   the scope of this document.)

CATENATE拡張子へのいくつかの明白な用途があります。 使用がケースに入れる動機はリソースで強制的なクライアントがそのクライアントのIMAP店に既に存在するデータを含むその後の服従のためにメッセージを作成する方法を提供することでした。 クライアントが潜在的にかなりのメッセージ部分をダウンロードして、再アップロードする必要はないので、帯域幅と処理制限には、同じくらい多くの影響力がありません。 さらに、また、クライアントがそれ自身のIMAP店でメッセージを作成できるので、コマンドはクライアントが二度メッセージをアップロードする必要はなくて送信されたメッセージのコピーを格納する願望を扱います。 (このドキュメントの範囲の外にメッセージを送るためのメカニズムがあります。)

   The extended APPEND command can also be used to copy parts of a
   message to another mailbox for archival purposes while getting rid of
   undesired parts.  In environments where server storage is limited, a
   client could get rid of large message parts by copying over only the
   necessary parts and then deleting the original message.  The
   mechanism could also be used to add data to a message (such as
   prepending message header fields) or to include other data by making
   a copy of the original and catenating the new data.

また、保存目的のために望まれない部品を取り除いている間、別のメールボックスにメッセージの部分をコピーするのに拡張APPENDコマンドを使用できます。 サーバストレージが限られている環境で、クライアントは、必要な部分だけの上にコピーして、次に、オリジナルのメッセージを削除することによって、かなりのメッセージ部分を取り除くことができるでしょう。 また、メッセージ(メッセージヘッダーフィールドをprependingなどなどの)にデータを追加するか、または謄本を作って、新しいデータをcatenatingすることによって他のデータを含めるのにメカニズムを使用できました。

2.  The CATENATE Capability

2. カテナート能力

   A server that supports this extension returns "CATENATE" as one of
   the responses to the CAPABILITY command.

この拡大をサポートするサーバは能力コマンドへの応答の1つとして「カテナート」を返します。

Resnick                     Standards Track                     [Page 2]

RFC 4469                IMAP CATENATE Extension               April 2006

レズニックStandardsはIMAPカテナート拡大2006年4月にRFC4469を追跡します[2ページ]。

3.  The APPEND Command

3. 追加コマンド

   Arguments:  mailbox name
               (The following can be repeated in the presence of the
               MULTIAPPEND extension [3])
               OPTIONAL flag parenthesized list
               OPTIONAL date/time string
               a single message literal or one or more message parts to
               catenate, specified as:
                           message literal
                           or
                           message (or message part) URL

議論: メールボックス名、(MULTIAPPEND拡大[3])OPTIONAL旗があるとき繰り返されて、parenthesizedリストOPTIONAL日付/時間がただ一つのメッセージリテラルか1つ以上のメッセージ部分をカテナートに結ぶということであり、指定された以下の缶: メッセージリテラルかメッセージ(または、メッセージ部分)URL

   Responses:  OPTIONAL NO responses: BADURL, TOOBIG

応答: OPTIONAL NO応答: BADURL、TOOBIG

   Result:     OK -  append completed
               NO -  append error: can't append to that mailbox, error
                     in flags or date/time or message text, or can't
                     fetch that data
               BAD - command unknown or arguments invalid

結果: OK--完成したノーを追加してください--誤りを追加してください: メールボックス、旗、日付/時間またはメッセージ・テキストにおける誤りをそれに追加できないか、またはそのデータBADをとって来ることができません--未知か議論病人を命令してください。

   The APPEND command concatenates all the message parts and appends
   them as a new message to the end of the specified mailbox.  The
   parenthesized flag list and date/time string set the flags and the
   internal date, respectively, as described in IMAP [1].  The
   subsequent command parameters specify the message parts that are
   appended sequentially to the output message.

APPENDコマンドは、指定されたメールボックスの端にすべてのメッセージの部品を連結して、新しいメッセージとしてそれらを追加します。 parenthesized現役将官名簿と日付/時間ストリングはIMAP[1]で説明されるようにそれぞれ旗と内部の期日を決めます。 その後のコマンドパラメタは出力メッセージに連続して追加されるメッセージの部品を指定します。

   If the original form of APPEND is used, a message literal follows the
   optional flag list and date/time string, which is appended as
   described in IMAP [1].  If the extended form is used, "CATENATE" and
   a parenthesized list of message literals and message URLs follows,
   each of which is appended to the new message.  If a message literal
   is specified (indicated by "TEXT"), the octets following the count
   are appended.  If a message URL is specified (indicated by "URL"),
   the octets of the body part pointed to by that URL are appended, as
   if the literal returned in a FETCH BODY response were put in place of
   the message part specifier.  The APPEND command does not cause the
   \Seen flag to be set for any catenated body part.  The APPEND command
   does not change the selected mailbox.

APPENDの原型が使用されているなら、メッセージリテラルは任意の現役将官名簿と日付/時間ストリングに続きます。(それは、IMAP[1]で説明されるように追加されます)。 拡張型が使用されているなら、「カテナート」とメッセージリテラルとメッセージURLのparenthesizedリストはどれが新しいメッセージに追加されるかにそれぞれ従います。 メッセージリテラルを指定するなら(「テキスト」で、示されます)、カウントに続く八重奏を追加します。 メッセージURLを指定するなら(「URL」で、示されます)、そのURLによって示された身体の部分の八重奏を追加します、まるでフェッチボディー応答で返されたリテラルがメッセージ部分特許説明書の作成書に代わって置かれるかのように。 APPENDコマンドで、どんなcatenated身体の部分にもSeenが旗を揚げさせる\を設定しません。 APPENDコマンドは選択されたメールボックスを変えません。

   In the extended APPEND command, the string following "URL" is an IMAP
   URL [2] and is interpreted according to the rules of [2].  The
   present document only describes the behavior of the command using
   IMAP URLs that refer to specific messages or message parts on the
   current IMAP server from the current authenticated IMAP session.
   Because of that, only relative IMAP message or message part URLs
   (i.e., those having no scheme or <iserver>) are used.  The base URL

拡張APPENDコマンドでは、「URL」に続くストリングは、IMAP URL[2]であり、[2]の規則に従って、解釈されます。 現在のドキュメントは、現在のIMAPサーバに現在の認証されたIMAPセッションから特定のメッセージかメッセージの部品を示すIMAP URLを使用することでコマンドの振舞いについて説明するだけです。 それのために、相対的なIMAPメッセージかメッセージ部分URL(すなわち、体系を全く持っていないものか<iserver>)だけが使用されています。 ベースURL

Resnick                     Standards Track                     [Page 3]

RFC 4469                IMAP CATENATE Extension               April 2006

レズニックStandardsはIMAPカテナート拡大2006年4月にRFC4469を追跡します[3ページ]。

   for evaluating the relative URL is considered "imap://user@server/",
   where "user" is the user name of the currently authenticated user and
   "server" is the domain name of the current server.  When in the
   selected state, the base URL is considered
   "imap://user@server/mailbox", where "mailbox" is the encoded name of
   the currently selected mailbox.  Additionally, since the APPEND
   command is valid in the authenticated state of an IMAP session, no
   further LOGIN or AUTHENTICATE command is performed for URLs specified
   in the extended APPEND command.

評価において、相対的なURLは「imap: //user@server/ 」であると考えられて、「ユーザ」がどこの現在認証されたユーザと「サーバ」のユーザ名であるかは現在のサーバのドメイン名です。選択された状態にあるとき、ベースURLは「imap: //user@server/mailbox 」であると考えられます。そこでは、「メールボックス」が現在選択されたメールボックスのコード化された名前です。 さらに、APPENDコマンドがIMAPセッションの認証された状態で有効であるので、どんな一層のLOGINもAUTHENTICATEコマンドも拡張APPENDコマンドで指定されたURLのために実行されません。

      Note: Use of an absolute IMAP URL or any URL that refers to
      anything other than a message or message part from the current
      authenticated IMAP session is outside the scope of this document
      and would require an extension to this specification, and a server
      implementing only this specification would return NO to such a
      request.

以下に注意してください。 メッセージ以外の何か現在の認証されたIMAPセッションからのメッセージ部分についてでも言及する絶対IMAP URLかどんなURLの使用も、このドキュメントの範囲の外にあって、この仕様に拡大を必要とするでしょう、そして、この仕様だけを履行するサーバはそのような要求にいいえを返すでしょう。

   The client is responsible for making sure that the catenated message
   is in the format of an Internet Message Format (RFC 2822) [4] or
   Multipurpose Internet Mail Extension (MIME) [5] message.  In
   particular, when a URL is catenated, the server copies octets,
   unchanged, from the indicated message or message part to the
   catenated message.  It does no data conversion (e.g., MIME transfer
   encodings) nor any verification that the data is appropriate for the
   MIME part of the message into which it is inserted.  The client is
   also responsible for inserting appropriate MIME boundaries between
   body parts, and writing MIME Content-Type and Content-Transfer-
   Encoding lines as needed in the appropriate places.

インターネットMessage Format(RFC2822)[4]かマルチパーパスインターネットメールエクステンション(MIME)[5]メッセージの形式にはcatenatedメッセージがあるのを確実にするのにクライアントは責任があります。 URLがcatenatedされると、特に、サーバは八重奏をコピーします、変わりがありません、示されたメッセージかメッセージ部分からcatenatedメッセージまで。 それは、(例えば、MIME転送encodings)をどんなデータ変換にもしないで、それが挿入されるメッセージのMIME部分をデータが適切であるどんな検証にもします。 また、クライアントも必要に応じて適切な場所に身体の部分の間の適切なMIME限界を挿入して、MIMEコンテントタイプとContent-転送コード化に系列を書くのに責任があります。

   Responses behave just as the original APPEND command described in
   IMAP [1].  If the server implements the IMAP UIDPLUS extension [6],
   it will also return an APPENDUID response code in the tagged OK
   response.  Two response codes are provided in Section 4 that can be
   used in the tagged NO response if the APPEND command fails.

ちょうどオリジナルのAPPENDコマンドがIMAP[1]で説明したように応答は振る舞います。 また、サーバが、IMAP UIDPLUSが拡大[6]であると実装すると、それはタグ付けをされたOK応答におけるAPPENDUID応答コードを返すでしょう。 APPENDコマンドが失敗するならタグ付けをされたいいえ応答に使用できるセクション4に2つの応答コードを提供します。

4.  Response Codes

4. 応答コード

   When a APPEND command fails, it may return a response code that
   describes a reason for the failure.

APPENDコマンドが失敗すると、それは失敗の理由について説明する応答コードを返すかもしれません。

4.1.  BADURL Response

4.1. BADURL応答

   The BADURL response code is returned if the APPEND fails to process
   one of the specified URLs.  Possible reasons for this are bad URL
   syntax, unrecognized URL schema, invalid message UID, or invalid body
   part.  The BADURL response code contains the first URL specified as a
   parameter to the APPEND command that has caused the operation to
   fail.

APPENDが指定されたURLの1つを処理しないなら、BADURL応答コードは返されます。 この可能な理由は、悪いURL構文、認識されていないURL図式、無効のメッセージUID、または無効の身体の部分です。 BADURL応答コードはパラメタとして操作が失敗されたAPPENDコマンドに指定された最初のURLを含んでいます。

Resnick                     Standards Track                     [Page 4]

RFC 4469                IMAP CATENATE Extension               April 2006

レズニックStandardsはIMAPカテナート拡大2006年4月にRFC4469を追跡します[4ページ]。

4.2.  TOOBIG Response

4.2. TOOBIG応答

   The TOOBIG response code is returned if the resulting message will
   exceed the 4-GB IMAP message limit.  This might happen, for example,
   if the client specifies 3 URLs for 2-GB messages.  Note that even if
   the server doesn't return TOOBIG, it still has to be defensive
   against misbehaving or malicious clients that try to construct a
   message over the 4-GB limit.  The server may also wish to return the
   TOOBIG response code if the resulting message exceeds a server-
   specific message size limit.

結果として起こるメッセージが4GB IMAPのメッセージ限界を超えるなら、TOOBIG応答コードは返されます。 例えば、クライアントが2GBのメッセージに3つのURLを指定するなら、これは起こるかもしれません。 サーバがTOOBIGを返さないでも、まだ4GBの限界の上でメッセージを構成しようとするふらちな事するか悪意があるクライアントに対して防衛的でなければならないことに注意してください。 また、結果として起こるメッセージがサーバの特定のメッセージサイズ限界を超えているなら、サーバはTOOBIG応答コードを返したがっているかもしれません。

5.  Formal Syntax

5. 正式な構文

   The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) [7] notation.  Elements not defined here can be found in
   the formal syntax of the ABNF [7], IMAP [1], and IMAP ABNF extensions
   [8] specifications.  Note that capability and resp-text-code are
   extended from the IMAP [1] specification and append-data is extended
   from the IMAP ABNF extensions [8] specification.

以下の構文仕様はAugmented BN記法(ABNF)[7]記法を使用します。 ABNF[7]、IMAP[1]、およびIMAP ABNF拡大[8]仕様の正式な構文でここで定義されなかった要素は見つけることができます。 能力とrespテキストコードがIMAP[1]仕様から広げられるのとデータを追加するというメモはIMAP ABNF拡大[8]仕様から広げられます。

   append-data =/ "CATENATE" SP "(" cat-part *(SP cat-part) ")"

「(「猫部分*(SP猫部分)」)」というデータを追加している=/「カテナート」SP

   cat-part = text-literal / url

猫部分はテキストリテラル/urlと等しいです。

   text-literal = "TEXT" SP literal

テキストリテラル=「テキスト」SPリテラル

   url = "URL" SP astring

urlは「URL」SP astringと等しいです。

   resp-text-code =/ toobig-response-code / badurl-response-code

badurl応答respテキストコードtoobig応答=/コード/コード

   toobig-response-code = "TOOBIG"

toobig応答コードは"TOOBIG"と等しいです。

   badurl-response-code = "BADURL" SP url-resp-text

badurl応答コードは"BADURL"というSP url-resp-テキストと等しいです。

   url-resp-text = 1*(%x01-09 /
                      %x0B-0C /
                      %x0E-5B /
                      %x5D-FE) ; Any TEXT-CHAR except "]"

url-resp-テキスト=1*(x0B-0C/%の%x01-09/%x0E-5B/%x5D-FE)。 「どんなテキスト炭も除く」]、」

   capability =/ "CATENATE"

能力=/「カテナート」

   The astring in the definition of url and the url-resp-text in the
   definition of badurl-response-code each contain an imapurl as defined
   by [2].

badurl応答コードの定義におけるurlの定義におけるastringとurl-resp-テキストは[2]によって定義されるようにそれぞれimapurlを含んでいます。

Resnick                     Standards Track                     [Page 5]

RFC 4469                IMAP CATENATE Extension               April 2006

レズニックStandardsはIMAPカテナート拡大2006年4月にRFC4469を追跡します[5ページ]。

6.  Acknowledgements

6. 承認

   Thanks to the members of the LEMONADE working group for their input.
   Special thanks to Alexey Melnikov for the examples.

彼らの入力をLEMONADEワーキンググループのメンバーをありがとうございます。 例のためのAlexeyメリニコフのおかげで、特別です。

7.  Security Considerations

7. セキュリティ問題

   The CATENATE extension does not raise any security considerations
   that are not present for the base protocol or in the use of IMAP
   URLs, and these issues are discussed in the IMAP [1] and IMAP URL [2]
   documents.

CATENATE拡張子はどんなベースプロトコルかIMAP URLの使用で存在していないセキュリティ問題も提起しません、そして、IMAP[1]とIMAP URL[2]ドキュメントでこれらの問題について議論します。

8.  IANA Considerations

8. IANA問題

   IMAP4 capabilities are registered by publishing a standards track or
   IESG approved experimental RFC.  The registry is currently located at
   <http://www.iana.org/assignments/imap4-capabilities>.  This document
   defines the CATENATE IMAP capability.  The IANA has added this
   capability to the registry.

IMAP4能力が標準化過程を発行することによって、登録されたか、またはIESGは実験的なRFCを承認しました。 登録は現在、<imap4http://www.iana.org/課題/能力>に位置しています。 このドキュメントはCATENATE IMAP能力を定義します。 IANAは登録へのこの能力を加えました。

Resnick                     Standards Track                     [Page 6]

RFC 4469                IMAP CATENATE Extension               April 2006

レズニックStandardsはIMAPカテナート拡大2006年4月にRFC4469を追跡します[6ページ]。

Appendix A.  Examples

付録A.の例

   Lines not starting with "C: " or "S: " are continuations of the
   previous lines.

始めでないのを裏打ちする、「C:」 または、「「S:」 「前の系列が続刊があります」?

   The original message in examples 1 and 2 below (UID = 20) has the
   following structure:

(UID=20)の下の例1と2のオリジナルのメッセージには、以下の構造があります:

      multipart/mixed MIME message with two body parts:

2つの身体の部分がある複合の、または、複雑なMIMEメッセージ:

      1.  text/plain

1. テキスト/平野

      2.  application/x-zip-compressed

2. 圧縮されたxアプリケーション/ファスナ

   Example 1: The following example demonstrates how a CATENATE client
   can replace an attachment in a draft message, without the need to
   download it to the client and upload it back.

例1: 以下の例はCATENATEクライアントがどう草稿メッセージでの付属を取り替えることができるかを示します、それをクライアントにダウンロードして、それをアップロードし返す必要性なしで。

   C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
    (URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=HEADER"
    TEXT {42}
   S: + Ready for literal data
   C:
   C: --------------030308070208000400050907
   C:  URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1.MIME"
    URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;section=1" TEXT {42}
   S: + Ready for literal data
   C:
   C: --------------030308070208000400050907
   C:  URL "/Drafts;UIDVALIDITY=385759045/;UID=30" TEXT {44}
   S: + Ready for literal data
   C:
   C: --------------030308070208000400050907--
   C: )
   S: A003 OK catenate append completed

C: A003は草稿(\見られた\草稿$MDNSent)カテナートを追加します; 完成されて、A003 OKカテナートは追加します。

Resnick                     Standards Track                     [Page 7]

RFC 4469                IMAP CATENATE Extension               April 2006

レズニックStandardsはIMAPカテナート拡大2006年4月にRFC4469を追跡します[7ページ]。

   Example 2: The following example demonstrates how the CATENATE
   extension can be used to replace edited text in a draft message, as
   well as header fields for the top level message part (e.g., Subject
   has changed).  The previous version of the draft is marked as
   \Deleted.  Note that the server also supports the UIDPLUS extension,
   so the APPENDUID response code is returned in the successful OK
   response to the APPEND command.

例2: 以下の例は草稿メッセージの編集されたテキストを置き換えるのにどうCATENATE拡張子を使用できるかを示します、最高平らなメッセージ部分へのヘッダーフィールドと同様に(例えば、Subjectは変化しました)。 草稿の旧バージョンは\Deletedとしてマークされます。 APPENDUID応答コードがAPPENDコマンドへのうまくいっているOK応答で返されるためにまた、サーバが、UIDPLUSが拡大であるとサポートすることに注意してください。

   C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE (TEXT {738}
   S: + Ready for literal data
   C: Return-Path: <bar@example.org>
   C: Received: from [127.0.0.2]
   C:           by rufus.example.org via TCP (internal) with ESMTPA;
   C:           Thu, 11 Nov 2004 16:57:07 +0000
   C: Message-ID: <419399E1.6000505@example.org>
   C: Date: Thu, 12 Nov 2004 16:57:05 +0000
   C: From: Bob Ar <bar@example.org>
   C: X-Accept-Language: en-us, en
   C: MIME-Version: 1.0
   C: To: foo@example.net
   C: Subject: About our holiday trip
   C: Content-Type: multipart/mixed;
   C:               boundary="------------030308070208000400050907"
   C:
   C: --------------030308070208000400050907
   C: Content-Type: text/plain; charset=us-ascii; format=flowed
   C: Content-Transfer-Encoding: 7bit
   C:
   C: Our travel agent has sent the updated schedule.
   C:
   C: Cheers,
   C: Bob
   C: --------------030308070208000400050907
   C:  URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2.MIME"
    URL "/Drafts;UIDVALIDITY=385759045/;UID=20/;Section=2" TEXT {44}
   S: + Ready for literal data
   C:
   C: --------------030308070208000400050907--
   C: )
   S: A003 OK [APPENDUID 385759045 45] append Completed
   C: A004 UID STORE 20 +FLAGS.SILENT (\Deleted)
   S: A004 OK STORE completed

C: A003は草稿(\見られた\草稿$MDNSent)カテナートを追加します。(テキスト738S: +は文字通りのデータのためにCを準備します: リターンパス: <バー@example.org>C: 受け取られている: [127.0 .0 .2]C: ESMTPAとTCP(内部の)を通したrufus.example.org。 C: 木曜日、2004年11月11日の16:57: 07 +0000C: Message ID: <419399E1.6000505@example.org>C: 日付: 木曜日、2004年11月12日の16:57: 05 +0000C: From: ボブ Ar <bar@example.org 、gt;、C: Xは言語を受け入れます: アン、-、私たち、アンC: MIMEバージョン: 1.0C: To: foo@example.net C: Subject: 私たちの休日旅行Cに関して: コンテントタイプ: 複合か混ぜられる。 C: 「境界=」------------「030308070208000400050907」C: C: --------------030308070208000400050907C: コンテントタイプ: テキスト/平野。 charsetが私たちと等しい、-、ASCII。 形式=が流れた、C: 満足している転送コード化: 7はCに噛み付きました: C: 私たちの旅行代理店はアップデートされたスケジュールを送りました。 C: C: 乾杯、C: ボブC: --------------030308070208000400050907C: セクションは2.MIMEと等しいです。「URL」/草稿; UIDVALIDITY=385759045/; UID=20/; 」 」 /が作成するURL; UIDVALIDITY=385759045/; UID=20/; セクションは2インチのテキスト44Sと等しいです: +は文字通りのデータのためにCを準備します: C: --------------030308070208000400050907 --C、: ) S: A003 OK[APPENDUID385759045 45]はCompleted Cを追加します: A004 UIDは20+FLAGS.SILENT(削除された\)Sを保存します: 完成したA004 OK STORE

Resnick                     Standards Track                     [Page 8]

RFC 4469                IMAP CATENATE Extension               April 2006

レズニックStandardsはIMAPカテナート拡大2006年4月にRFC4469を追跡します[8ページ]。

   Example 3: The following example demonstrates how the CATENATE
   extension can be used to strip attachments.  Below, a PowerPoint
   attachment was replaced by a small text part explaining that the
   attachment was stripped.

例3: 以下の例は付属を剥取るのにどうCATENATE拡張子を使用できるかを示します。 以下では、パワーポイント付属を付属が剥取られたのがわかる小さいテキスト部分に取り替えました。

   C: A003 APPEND Drafts (\Seen \Draft $MDNSent) CATENATE
    (URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=HEADER"
    TEXT {42}
   S: + Ready for literal data
   C:
   C: --------------030308070208000400050903
   C:  URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1.MIME"
    URL "/Drafts;UIDVALIDITY=385759045/;UID=21/;section=1" TEXT {255}
   S: + Ready for literal data
   C:
   C: --------------030308070208000400050903
   C: Content-type: text/plain; charset="us-ascii"
   C: Content-transfer-encoding: 7bit
   C:
   C: This body part contained a Power Point presentation that was
   C: deleted upon your request.
   C: --------------030308070208000400050903--
   C: )
   S: A003 OK append Completed

C: A003は草稿(\見られた\草稿$MDNSent)カテナートを追加します。(「」 /が作成するURL; UIDVALIDITY=385759045/; UID=21/; セクションはヘッダーと等しい」というテキスト42S: +は文字通りのデータのためにCを準備します: C: --------------030308070208000400050903C: セクションは1.MIMEと等しいです。「URL」/草稿; UIDVALIDITY=385759045/; UID=21/; 」 」 /が作成するURL; UIDVALIDITY=385759045/; UID=21/; セクションは1インチのテキスト255Sと等しいです: +は文字通りのデータのためにCを準備します: C: --------------030308070208000400050903C: 文書内容: テキスト/平野。 charsetが等しい、「私たち、-、ASCII、」 C: 満足している転送コード化: 7はCに噛み付きました: C: この身体の部分はCであったPowerPointプレゼンテーションを含みました: あなたの要求に削除されます。 C: --------------030308070208000400050903 --C、: ) S: A003 OKはCompletedを追加します。

Resnick                     Standards Track                     [Page 9]

RFC 4469                IMAP CATENATE Extension               April 2006

レズニックStandardsはIMAPカテナート拡大2006年4月にRFC4469を追跡します[9ページ]。

   Example 4: The following example demonstrates a failed APPEND
   command.  The server returns the BADURL response code to indicate
   that one of the provided URLs is invalid.  This example also
   demonstrates how the CATENATE extension can be used to construct a
   digest of several messages.

例4: 以下の例は失敗したAPPENDコマンドを示します。 サーバは、提供されたURLの1つが無効であることを示すためにBADURL応答コードを返します。 また、この例はいくつかのメッセージのダイジェストを構成するのにどうCATENATE拡張子を使用できるかを示します。

   C: A003 APPEND Sent (\Seen $MDNSent) CATENATE (TEXT {541}
   S: + Ready for literal data
   C: Return-Path: <foo@example.org>
   C: Received: from [127.0.0.2]
   C:           by rufus.example.org via TCP (internal) with ESMTPA;
   C:           Thu, 11 Nov 2004 16:57:07 +0000
   C: Message-ID: <419399E1.6000505@example.org>
   C: Date: Thu, 21 Nov 2004 16:57:05 +0000
   C: From: Farren Oo <foo@example.org>
   C: X-Accept-Language: en-us, en
   C: MIME-Version: 1.0
   C: To: bar@example.org
   C: Subject: Digest of the mailing list for today
   C: Content-Type: multipart/digest;
   C:               boundary="------------030308070208000400050904"
   C:
   C: --------------030308070208000400050904
   C:  URL "/INBOX;UIDVALIDITY=785799047/;UID=11467" TEXT {42}
   S: + Ready for literal data
   C:
   C: --------------030308070208000400050904
   C:  URL "/INBOX;UIDVALIDITY=785799047/;UID=113330/;section=1.5.9"
    TEXT {42}
   S: + Ready for literal data
   C:
   C: --------------030308070208000400050904
   C:  URL "/INBOX;UIDVALIDITY=785799047/;UID=11916" TEXT {44}
   S: + Ready for literal data
   C:
   C: --------------030308070208000400050904--
   C: )
   S: A003 NO [BADURL "/INBOX;UIDVALIDITY=785799047/;UID=113330;
   section=1.5.9"] CATENATE append has failed, one message expunged

C: A003 APPEND Sent(\Seen$MDNSent)CATENATE、(TEXT541S: 文字通りのデータC: リターン経路: <foo@example.org の準備ができる+、gt;、C: 受け取られている:、127.0 .0 .2C:、ESMTPAとTCP(内部の)を通したrufus.example.org; C: 木曜日、2004年11月11日の16:57:07+0000C: Message ID; <419399E1.6000505@example.org>C: 日付: 木曜日、2004年11月21日の16:57:05+0000C: From: ファレン Oo <foo@example.org 、gt;、C: Xは言語を受け入れます:、アン、-、私たち、アンC: MIMEバージョン: 1.0C; 「To: bar@example.org C: Subject: 今日Cのメーリングリストのダイジェスト: コンテントタイプ: 複合/ダイジェスト; C: 境界=」、-、-、-、-、-、-、-、-、-、-、--030308070208000400050904 」 C: C:、-、-、-、-、-、-、-、-、-、-、-、-、--030308070208000400050904C; URL..受信トレイ..テキスト..準備ができる..文字通り..データ..URL..受信トレイ..セクション..0.9インチ..テキスト..準備..文字通り..データ..URL..受信トレイ..テキスト..準備ができる..文字通り..データ50904 --C、:、)、S: 「A003 NO、[BADURL、」 /受信トレイ; UIDVALIDITY=785799047/; UID=113330; =を区分してください、1.5、0.9インチ、]、CATENATEが追加する、失敗されていて、人は梢消されていた状態で通信します。

   Note that the server could have validated the URLs as they were
   received and therefore could have returned the tagged NO response
   with BADURL response-code in place of any continuation request after
   the URL was received.

サーバがそれらを受け取ったようにURLを有効にして、URLを受け取った後にしたがって、どんな継続要求に代わってBADURL応答コードによるタグ付けをされたいいえ応答を返したかもしれないことに注意してください。

Resnick                     Standards Track                    [Page 10]

RFC 4469                IMAP CATENATE Extension               April 2006

レズニックStandardsはIMAPカテナート拡大2006年4月にRFC4469を追跡します[10ページ]。

9.  Normative References

9. 引用規格

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

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

   [2]  Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.

[2] ニューマン、C.、「IMAP URL体系」、RFC2192、1997年9月。

   [3]  Crispin, M., "Internet Message Access Protocol (IMAP) -
        MULTIAPPEND Extension", RFC 3502, March 2003.

[3] クリスピン、M.、「インターネットはアクセス・プロトコル(IMAP)を通信させます--MULTIAPPEND拡張子」、RFC3502、3月2003日

   [4]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.

[4] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。

   [5]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies",
        RFC 2045, November 1996.

解放された[5]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。

   [6]  Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS
        extension", RFC 4315, December 2005.

[6] クリスピン、M.、「インターネットMessage Accessプロトコル(IMAP)--、UIDPLUS拡張子、」、RFC4315、12月2005日

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

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

   [8]  Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF",
        RFC 4466, April 2006.

[8] メリニコフとA.とC.Daboo、「IMAP4 ABNFへの集まっている拡大」、RFC4466、2006年4月。

Resnick                     Standards Track                    [Page 11]

RFC 4469                IMAP CATENATE Extension               April 2006

レズニックStandardsはIMAPカテナート拡大2006年4月にRFC4469を追跡します[11ページ]。

Author's Address

作者のアドレス

   Peter W. Resnick
   QUALCOMM Incorporated
   5775 Morehouse Drive
   San Diego, CA  92121-1714
   US

ピーター・W.レズニック・クアルコムの法人組織の5775モアハウス・Driveカリフォルニア92121-1714サンディエゴ(米国)

   Phone: +1 858 651 4478
   EMail: presnick@qualcomm.com
   URI:   http://www.qualcomm.com/~presnick/

以下に電話をしてください。 +1 4478年の858 651メール: presnick@qualcomm.com ユリ: http://www.qualcomm.com/~presnick/

Resnick                     Standards Track                    [Page 12]

RFC 4469                IMAP CATENATE Extension               April 2006

レズニックStandardsはIMAPカテナート拡大2006年4月にRFC4469を追跡します[12ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

   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 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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

Acknowledgement

承認

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Resnick                     Standards Track                    [Page 13]

レズニック標準化過程[13ページ]