計算機の世界 Top 新規 編集

IMAP CATENATE拡張 (RFC4469 日本語訳)

 
 

2006年4月に公開された、RFC4469 [Internet Message Access Protocol (IMAP) CATENATE Extension] (IMAP CATENATE拡張) の日本語訳です。謝辞と文献の箇所は原文のままです。

CATENATEは、IMAP4サーバに置かれたメールを、「事前にダウンロードすることなく」編集するための拡張コマンドです。例えば、携帯電話のようなリソースが限られたデバイスから、下書きメールにデータを追記するような場合に便利です。

原文は、http://www.ietf.org/rfc/rfc4469.txt をご参照下さい。邦訳の誤りにお気づきの場合、ページ最下部のメールアドレスまでご連絡いただければ幸いです。

なお、可読性向上のため、ページのヘッダ・フッタを省略し、原文には無い改行を、適宜挿入しております。ご了承下さい。


 Network Working Group                                         P. Resnick
 Request for Comments: 4469                         QUALCOMM Incorporated
 Updates: 3501, 3502                                           April 2006
 Category: Standards Track
     Internet Message Access Protocol (IMAP) CATENATE Extension

Internet Message Access Protocol (IMAP) CATENATE (連結) 拡張

このメモの位置づけ (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.

この文書は、インターネットコミュニティに向けて、インターネットの標準規格プロトコルを規定し、改良のための議論と提案を求めるものである。本プロトコルの標準化の進捗、および位置づけは、"Internet Official Protocol Standards" (STD 1)の最新版を参照されたい。このメモの配布に制限はない。

著作権表示 (Copyright Notice)

 Copyright (C) The Internet Society (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.

Internet Message Access Protocol (IMAP) CATENATE拡張は、APPENDコマンドを拡張し、IMAPサーバ上の既存メッセージの一部(または全部)と、新規データを組み合わせたメッセージを、クライアントがIMAPサーバ上に生成できるようにする。

クライアントは、この拡張を用い、あらかじめデータをダウンロード/アップロードすることなく、既存のメッセージの一部を、新規メッセージに付加できる。

1. はじめに (Introduction)

 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.

Internet Message Access Protocol (IMAP) [1](RFC 3501)のCATENATE拡張により、クライアントは、IMAPサーバ上の既存メッセージのテキスト(またはメッセージの一部)を含むメッセージを、事前のFETCH・サーバへの再APPENDなしに、IMAPサーバ上に生成できる。

CATENATE拡張は、コマンドが、単一のメッセージリテラルの代わりに、複数のメッセージリテラル (IMAP[1](RFC 3501)に記述あり) とURL (IMAP URLスキーマ[2](RFC 2192)に記述あり) を含むことができるように、APPENDコマンドを拡張する。サーバは、それらの部品すべてを受け入れ、出力メッセージに連結する。

CATENATE拡張は、一回のコマンドで複数のメッセージをAPPENDするために、MULTIAPPEND拡張[3](RFC 3502)と共存することができる。

 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コマンドは、メッセージの一部を、保管用として別メールボックスにコピーすることもでき、これは一方で、不要な部分の除去に使える。

サーバのストレージ容量が限られた環境において、クライアントは、メッセージの必要な部分だけを複製し、オリジナルを削除することで、巨大なメッセージの不要部分を削除できる。

このメカニズムは、メッセージへのデータ追加(メッセージヘッダの追加)や、元データのコピーと、データ連結による、既存外部データの追加にも使用できる。

2. CATENATEの可否 (The CATENATE Capability)

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

この拡張をサポートするサーバは、CAPABILITYコマンドの応答のひとつに、"CATENATE"を返す。

3. APPENDコマンド (The APPEND Command)

引数 (Arguments)

 mailbox name
 (The following can be repeated in the presence of the
 MULTIAPPEND extension [3])

(MULTIAPPEND拡張[3](RFC 3502)が存在する場合、以下は繰り返してもよい)

 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

応答 (Responses)

 OPTIONAL NO responses: BADURL, TOOBIG

結果 (Result)

 OK -  append completed

OK - 追加完了

 NO -  append error: can't append to that mailbox, error
                   in flags or date/time or message text, or can't
                   fetch that data

NO - 追加エラー: 当該メールボックスへの追加に失敗。フラグ、日付/時刻、メッセージテキストに問題がある。または、データの取得に失敗。

 BAD - command unknown or arguments invalid

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コマンドは、全メッセージパートを連結し、メールボックスの最後に、新規メッセージとして追加する。

カッコで囲まれたフラグのリストと、日付/時刻文字列によって、IMAP [1](RFC 3501)の記述のとおり、それぞれフラグと内部時刻をセットする。

その次のコマンドパラメータは、出力メッセージに連続的に追加されるメッセージパートを指定する。

 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](RFC 3501)にあるとおり追加された、オプションのフラグリストと、日付/時刻文字列を伴う。

拡張形式が使用される場合、"CATENATE"、およびカッコで囲まれたメッセージリテラルとURLのリスト(訳注1)を伴い、これらは新規メッセージに追加される。メッセージリテラル("TEXT"で示される)が指定された場合、リテラルを数えたオクテット数が追加される(訳注2)。メッセージのURL("URL"で示される)が指定された場合、そのURLが指すボディ部のオクテット数が、さも、「FETCH BODYで返されたリテラルがメッセージ部指定子 (message part specifier) の位置にある」かのごとく、追加される。

APPENDコマンドは、連結されたボディ部にセットされる\Seenフラグの原因とはならない。APPENDコマンドは、選択されたメールボックスを変更しない。

訳注1

"follows"なので、「カッコで囲まれた」は、"URLs"でなく、全体を修飾していると考えました。どうでしょう。

訳注2

「オクテット数」は、{}で囲まれた数字列で、次にクライアントが送るコマンドの直前までのオクテット数を指します。オペレーションの区切りの改行 (CR + LF = 2オクテット) も含めて数えます。

判りにくかったら、[付録A. サンプル集]の、C: で始まる行を、上から順に追ってみて下さい。例えば、TEXT {40}と書かれていたら、「その次の"C: "で始まる行」の先頭から40オクテットが、メッセージリテラルです。多分。

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

拡張されたAPPENDコマンドでは、"URL"に続く文字列は、IMAP URL[2](RFC 2192)であり、[2]の規則に従って解釈される。この文書は、『「現在認証済みのIMAPセッションが」「現在使用中のIMAPサーバ上で参照している」「メッセージまたはメッセージの一部」を指すIMAP URL』を使用するコマンドの挙動についてのみ述べる。

そのため、使用できるのは「メッセージまたはメッセージ」の相対URL(スキーマの無いものや、<iserver>等)のみとする。相対URLを評価するためのベースURLは、"imap://user@server/"である。ここで"user"は、現在認証済みのユーザ名、"server"は、現在使用中のサーバのドメイン名とする。

ある条件下では、ベースURLは、"imap://user@server/mailbox"となる。"mailbox"は、エンコード済みの、現在選択されたメールボックスの名称とする。

加えて、一度APPENDコマンドがIMAPセッションで認証された状態となった以後は、更なるLOGINAUTHENTICATEコマンドは、拡張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」の使用に関しては、本文書の対象外であり、本仕様の拡張が必要である。

また、本仕様のみを実装したサーバは、このようなURLリクエストに対し、NOを返すこととなる。

 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.

クライアントは、連結したメッセージが、Internet Message形式 (RFC 2822) [4](RFC 2822)またはMultipurpose Internet Mail Extension (MIME) [5](RFC 2045)メッセージになっていることを保証する責任がある。

特に、URLを連結する場合、サーバは、指定されたメッセージまたはメッセージの一部から、オクテットを変更することなく、連結メッセージにコピーする。データ変換 (MIME trasfer encodings など) や、データが、挿入先のメッセージのMIMEパートとして適切であるかの検証等は、一切行われない。

また、クライアントは、適切なMIME boundary (区切り) をボディパーツ間に挿入し、適切な場所に必要に応じ、MIME のContent-TypeContent-Transfer-Encoding行を記載する責任も負う。

 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.

レスポンスは、IMAP[1](RFC 3501)で述べられている「元来の形式のAPPENDコマンド」と同様に動作する。

サーバが、IMAP UIDPLUS拡張[6](RFC 4315)を実装している場合、タグ付けされたOK中に、APPENDUIDレスポンスコードも返される。

4.節で述べる2つのレスポンスコードを、APPENDコマンドが失敗した際にタグ付けされたNO中で使用できる。

4. レスポンスコード (Response Codes)

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

APPENDコマンドが失敗した場合、失敗の理由を述べるレスポンスコードを返してもよい。

4.1. BADURL レスポンス (BADURL Response)

 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.

BADURLレスポンスコードは、指定されたURLの中に、APPENDが処理に失敗したものが含まれていた場合に返される。あり得る理由としては、URLの文法不正、未知のURLスキーマ、無効なメッセージUID、無効なボディ部、が挙げられる。

BADURLレスポンスコードには、APPENDコマンドにパラメータとして与えられたURLのうち、処理に失敗する原因となった、一番最初のものが含まれている。

4.2. TOOBIG レスポンス (TOOBIG Response)

 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.

TOOBIGレスポンスコードは、生成されるメッセージが、IMAPメッセージの制限である4GBを超えた場合に返される。例えばこれは、クライアントが、2GBのメッセージを指すURLを3つ指定した場合などに起こる。

サーバは、たとえTOOBIGを返さなくとも、4GB以上のメッセージを作ろうとする無作法または悪意あるクライアントから、自身を防御する必要があることに、留意しなければならない。

サーバは、メッセージサイズの上限を自分で決めて、それを越すメッセージの生成に対し、TOOBIGレスポンスコードを返してもよい。

5. 正式な文法 (Formal Syntax)

 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 Backus-Naur Form (ABNF) [7](RFC 4234)表示を使用する。

ここに定義のない要素は、ABNF [7]、IMAP [1](RFC 3501)、およびIMAP ABNF 拡張 [8](RFC 4466)を参照のこと。

 append-data =/ "CATENATE" SP "(" cat-part *(SP cat-part) ")"
 cat-part = text-literal / url
 text-literal = "TEXT" SP literal
 url = "URL" SP astring
 resp-text-code =/ toobig-response-code / badurl-response-code
 toobig-response-code = "TOOBIG"
 badurl-response-code = "BADURL" SP url-resp-text
 url-resp-text = 1*(%x01-09 /
                    %x0B-0C /
                    %x0E-5B /
                    %x5D-FE) ; Any TEXT-CHAR except "]"

"]"を除くすべてのTEXT-CHAR

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

url定義内のastring」および「badurl-response-code定義内のurl-resp-text」は、[2](RFC 2192)で定義されるimapurlを含む。

6. 謝辞 (Acknowledgements)

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

7. セキュリティについての考慮事項 (Security Considerations)

 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.

「基礎となるプロトコル」、および「IMAP URLの使用」に存在しないセキュリティ上の考慮事項は、CATENATE拡張によっても、顕著化することはない。

これら2つの考慮事項は、IMAP[1](RFC 3501)と、IMAP URL[2](RFC 2192)にて議論されている。

8. IANAについての考慮事項 (IANA Considerations)

 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によって登録される。現在のレジストリは、<http://www.iana.org/assignments/imap4-capabilities>である。本文書は、CATENATE IMAP機能を定義している。IANAは、この機能をレジストリに追加した。

付録A. サンプル集 (Appendix A. Examples)

 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:

下記、例1、2 (UID = 20) の元のメッセージは、以下の構造を持つ。

 multipart/mixed MIME message with two body parts:

以下2つのボディ部を持つ、MIMEタイプmultipart/mixedのメッセージ:

 1.  text/plain
 2.  application/x-zip-compressed
 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
 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とマークされる。サーバはUIDPLUS拡張もサポートするので、「APPENDコマンドのOKレスポンスが入るべき場所に、APPENDUIDレスポンスコードが入る」という点に留意しなければならない。

 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
 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拡張が、どのように添付ファイルを削除するか紹介する。PowerPointファイルが、「削除されました」という旨の短いテキストに置換されている。

 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
 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の一つが無効である」として、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
 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を受け取った次に来るリクエスト」があるべき場所に、「response-code BADURLの付いた、NOレスポンス」が入る可能性もある点に、注意が必要である。

9. 基準文献 (Normative References)

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

RFC 3501

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

RFC 2192

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

RFC 3502

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

RFC 2822

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

RFC 2045

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

RFC 4315

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

RFC 4234

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

RFC 4466

著者アドレス (Author's Address)

 Peter W. Resnick
 QUALCOMM Incorporated
 5775 Morehouse Drive
 San Diego, CA  92121-1714
 US
 Phone: +1 858 651 4478
 EMail: presnick@qualcomm.com
 URI:   http://www.qualcomm.com/~presnick/

著作権表示全文 (Full Copyright Statement)

 Copyright (C) The Internet Society (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.
 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.

知的財産 (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.
 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.
 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.

謝辞 (Acknowledgement)

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

RFC編集業務に対する資金は、IETF Administrative Support Activity (IASA) により提供されている。