[要約] RFC 4469は、IMAPのCATENATE拡張機能に関する仕様です。この拡張機能の目的は、複数のメッセージを1つのメッセージとして結合することを可能にすることです。
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
インターネットメッセージアクセスプロトコル（IMAP）Catenate Extension
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
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.
インターネットメッセージアクセスプロトコル（IMAP）へのCatenateの拡張機能は、追加のコマンドを拡張して、クライアントがIMAPサーバー上にメッセージを作成できるようにします。この拡張機能を使用して、クライアントは、最初にデータをダウンロードしてからサーバーにアップロードすることなく、既存のメッセージの一部を新しいメッセージにカテン化できます。
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.
インターネットメッセージアクセスプロトコル（IMAP）[1]へのCatenateの拡張機能により、クライアントは、サーバーに既に存在するメッセージ（またはメッセージの一部）のテキストをフェッチせずに存在するメッセージ（またはメッセージの一部）を含めることができるメッセージをサーバー上に作成できます。それらをサーバーに戻します。Catenate拡張子は、1つのメッセージリテラルの代わりに、コマンドがメッセージリテラルの組み合わせ（IMAP [1]に記載されている）とメッセージURL（IMAP URLスキームで説明されているように[2で説明されている）の任意の組み合わせ[2に引数として取得できるように、追加]コマンドを拡張します。] 仕様）。サーバーはすべてのピースを撮影し、それらを出力メッセージに変換します。Catenate Extensionは、MultiaPend Extension [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ストアでメッセージを作成できるため、コマンドは、メッセージを2回アップロードせずに送信されたメッセージのコピーをアーカイブするというクライアントの欲求に対応します。（メッセージを送信するためのメカニズムは、このドキュメントの範囲外です。）
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.
拡張された追加コマンドを使用して、望ましくない部品を取り除く間、アーカイブの目的でメッセージの部分を別のメールボックスにコピーすることもできます。サーバーストレージが制限されている環境では、クライアントは必要な部品のみをコピーして元のメッセージを削除することにより、大きなメッセージパーツを取り除くことができます。メカニズムを使用して、メッセージ（メッセージヘッダーフィールドの準備など）にデータを追加したり、元のコピーを作成したり、新しいデータをカテン化して他のデータを含めることもできます。
A server that supports this extension returns "CATENATE" as one of the responses to the CAPABILITY command.
この拡張機能をサポートするサーバーは、機能コマンドへの応答の1つとして「Catenate」を返します。
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
引数：メールボックス名（MultiaPend Extension [3]の存在下で以下を繰り返すことができます）オプションのフラグ括弧LISTオプションの日付/時刻文字（またはメッセージ部分）url
Responses: OPTIONAL NO responses: BADURL, TOOBIG
応答：オプションの応答なし：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-追加完了したno -appendエラー：そのメールボックスに追加できない、フラグまたは日付/時刻またはメッセージテキストのエラー、またはそのデータが悪い - コマンド不明または引数が無効になるかどうかを取得できない
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.
追加のコマンドは、すべてのメッセージパーツを連結し、指定されたメールボックスの最後まで新しいメッセージとして追加します。括弧付きフラグリストと日付/時刻文字列は、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.
付録の元の形式が使用される場合、メッセージリテラルはオプションのフラグリストと日付/時刻文字列に続きます。これはIMAP [1]で説明されているとおりです。拡張フォームが使用されている場合、「Catenate」とメッセージリテラルとメッセージURLの括弧付きリストが続き、それぞれが新しいメッセージに追加されます。メッセージリテラルが指定されている場合（「テキスト」で示されています）、カウントに続くオクテットが追加されます。メッセージURLが指定されている場合（「URL」で示されています）、そのURLによって指摘されたボディパーツのオクテットが追加されます。追加のコマンドは、\ sewフラグを任意のカテン付きのボディパーツに設定しません。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 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 URL [2]であり、[2]のルールに従って解釈されます。現在のドキュメントでは、現在の認証されたIMAPセッションから現在のIMAPサーバー上の特定のメッセージまたはメッセージパーツを参照するIMAP URLを使用したコマンドの動作のみを説明します。そのため、相対的なIMAPメッセージまたはメッセージパーツURL（つまり、スキームまたは<iserver>を持っていないもの）のみが使用されます。相対URLを評価するためのベースURLは「IMAP：// user@server/」と見なされます。ここで、「ユーザー」は現在認証されているユーザーのユーザー名であり、「サーバー」は現在のサーバーのドメイン名です。選択した状態では、ベースURLは「IMAP：// user@server/mailbox」と見なされます。ここで、「メールボックス」は現在選択されているメールボックスのエンコード名です。さらに、AppendコマンドはIMAPセッションの認証された状態で有効であるため、拡張された追加コマンドで指定された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 URLまたは現在の認証されたIMAPセッションのメッセージまたはメッセージパーツ以外のものを参照する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.
クライアントは、Catenatedメッセージがインターネットメッセージ形式（RFC 2822）[4]または多目的インターネットメールエクステンション（MIME）[5]メッセージの形式であることを確認する責任があります。特に、URLがカテン化されている場合、サーバーは、指定されたメッセージまたはメッセージの部分からCatenatedメッセージまで、オクテットを変更せずにコピーします。データ変換（MIME転送エンコーディングなど）も、データが挿入されたメッセージのMIME部分に適しているという確認もありません。また、クライアントは、適切な場所で必要に応じて、体の部分の間に適切なMIME境界を挿入したり、MIMEコンテンツタイプとコンテンツ転送エンコードラインを作成したりする責任があります。
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]で説明されている元の追加コマンドと同じように動作します。サーバーがIMAP uidplus拡張[6]を実装する場合、タグ付きOK応答のappenduid応答コードも返します。Appendコマンドが失敗した場合、タグ付きNO応答で使用できる2つの応答コードがセクション4に提供されています。
When a APPEND command fails, it may return a response code that describes a reason for the failure.
追加のコマンドが失敗すると、障害の理由を説明する応答コードを返す場合があります。
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.
付録が指定されたURLの1つを処理できない場合、BADURL応答コードが返されます。この理由の考えられる理由は、URL構文が悪い、認識されていないURLスキーマ、無効なメッセージUID、または無効なボディの部分です。BADURL応答コードには、操作が失敗した原因となったコマンドへのパラメーターとして指定された最初のURLが含まれています。
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.
結果のメッセージが4 GBのIMAPメッセージの制限を超える場合、TOBIG応答コードが返されます。これは、たとえば、クライアントが2 GBのメッセージに3つのURLを指定した場合に発生する可能性があります。サーバーがあまりにもビッグを返さない場合でも、4 GBの制限を超えてメッセージを作成しようとする不正行為または悪意のあるクライアントに対して防御的でなければならないことに注意してください。サーバーは、結果のメッセージがサーバー固有のメッセージサイズの制限を超えている場合、Toobig応答コードを返すこともできます。
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.
次の構文仕様では、拡張されたBackus-Naurフォーム（ABNF）[7]表記を使用します。ここで定義されていない要素は、ABNF [7]、IMAP [1]、およびIMAP ABNF拡張[8]仕様の正式な構文にあります。能力と応答コードはIMAP [1]仕様から拡張されており、append-dataはIMAP ABNF拡張[8]仕様から拡張されていることに注意してください。
append-data =/ "CATENATE" SP "(" cat-part *(SP cat-part) ")"
cat-part = text-literal / url
text-literal = "TEXT" SP literal
text-literal = "text" spリテラル
url = "URL" SP astring
url = "url" sp astring
resp-text-code =/ toobig-response-code / badurl-response-code
resp-text-code = / toobig-response-code / badurl-response-code
toobig-response-code = "TOOBIG"
badurl-response-code = "BADURL" SP url-resp-text
badurl-response-code = "badurl" sp url-resp-text
url-resp-text = 1*(%x01-09 /
%x0B-0C /
%x0E-5B /
%x5D-FE) ; Any TEXT-CHAR except "]"
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-response-Codeの定義におけるURLの定義とURL Resp-Textの耐上響は、それぞれ[2]で定義されているImapurlを含んでいます。
Thanks to the members of the LEMONADE working group for their input. Special thanks to Alexey Melnikov for the examples.
レモネードワーキンググループのメンバーの入力に感謝します。例については、Alexey Melnikovに感謝します。
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 Extensionは、ベースプロトコルやIMAP URLの使用に存在しないセキュリティ上の考慮事項を提起するものではなく、これらの問題はIMAP [1]およびIMAP URL [2]ドキュメントで説明されています。
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-capability>にあります。このドキュメントでは、Catenate IMAP機能を定義します。IANAは、この機能をレジストリに追加しました。
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つの体の部分を持つマルチパート/ミックスマイムメッセージ：
1. text/plain
1. テキスト/プレーン
2. application/x-zip-compressed
2. アプリケーション/x-zip圧縮
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.
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.
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.
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を検証した可能性があり、したがって、URLを受信した後、継続要求の代わりにBADURL応答コードを使用してタグ付けされた応答を返した可能性があることに注意してください。
[1] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[1] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[2] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
[2] ニューマン、C。、「IMAP URLスキーム」、RFC 2192、1997年9月。
[3] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, March 2003.
[3] Crispin、M。、「インターネットメッセージアクセスプロトコル（IMAP） - マルチアドペンド拡張機能」、RFC 3502、2003年3月。
[4] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[4] Resnick、P。、「インターネットメッセージフォーマット」、RFC 2822、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] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[6] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005.
[6] Crispin、M。、「インターネットメッセージアクセスプロトコル（IMAP） - uidplus拡張機能」、RFC 4315、2005年12月。
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[7] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[8] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[8] Melnikov、A。およびC. Daboo、「拡張機能をIMAP4 ABNFに収集しました」、RFC 4466、2006年4月。
Author's Address
著者の連絡先
Peter W. Resnick QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-1714 US
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).
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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78および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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。