[要約] RFC 3516は、IMAP4プロトコルにバイナリコンテンツのサポートを追加するための拡張です。目的は、メールサーバーとクライアント間でバイナリデータを効率的に転送することです。
Network Working Group L. Nerenberg
Request for Comments: 3516 Orthanc Systems
Category: Standards Track April 2003
IMAP4 Binary Content Extension
IMAP4バイナリコンテンツ拡張
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 (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This memo defines the Binary extension to the Internet Message Access Protocol (IMAP4). It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content-transfer-encoding.
このメモは、インターネットメッセージアクセスプロトコル（IMAP4）へのバイナリ拡張機能を定義します。IMAP4クライアントとサーバーが、MIMEコンテンツ転移エンコードを使用せずにメッセージボディデータを交換するメカニズムを提供します。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [KEYWORD].
このドキュメントの「必須」、「必要はない」、「そうでなければ」、「すべきではない」、「そうでない」、「必要はありません」は、[キーワード]で説明されているように解釈されます。
The abbreviation "CTE" means content-transfer-encoding.
略語「CTE」は、コンテンツ転移エンコードを意味します。
The MIME extensions to Internet messaging allow for the transmission of non-textual (binary) message content [MIME-IMB]. Since the traditional transports for messaging are not always capable of passing binary data transparently, MIME provides encoding schemes that allow binary content to be transmitted over transports that are not otherwise able to do so.
インターネットメッセージングへのMIME拡張により、非テキスト（バイナリ）メッセージコンテンツ[MIME-IMB]の送信が可能になります。メッセージング用の従来のトランスポートは常にバイナリデータを透過的に渡すことができるとは限らないため、MIMEは、そうでなければそうすることができないトランスポートを介してバイナリコンテンツを送信できるエンコードスキームを提供します。
The overhead of MIME-encoding this content can be considerable in some contexts (e.g., slow radio links, streaming multimedia). Reducing the overhead associated with CTE schemes such as base64 can give a noticeable reduction in resource consumption. The Binary extension lets the server perform CTE decoding prior to transmitting message data to the client.
このコンテンツをエンコードするMimeのオーバーヘッドは、一部のコンテキストでかなりの場合があります（たとえば、ラジオリンクの遅い、ストリーミングマルチメディア）。Base64などのCTEスキームに関連するオーバーヘッドを削減すると、リソース消費が顕著に減少する可能性があります。バイナリ拡張機能により、メッセージデータをクライアントに送信する前に、サーバーがCTEデコードを実行できます。
Every IMAP4 body section has a MIME content-transfer-encoding. (Those without an explicit Content-Transfer-Encoding header are implicitly labeled as "7bit" content.) In the terminology of [MIME-IMB], the CTE specifies both a decoding algorithm and the domain of the decoded data. In this memo, "decoding" refers to the CTE decoding step described in [MIME-IMB].
すべてのIMAP4ボディセクションには、MIMEコンテンツ転移エンコードがあります。（明示的なコンテンツ転移エンコードヘッダーのないものは、[MIME-IMB]の用語では、「7ビット」コンテンツと暗黙的にラベル付けされています。）CTEは、デコードアルゴリズムとデコードされたデータのドメインの両方を指定します。このメモでは、「デコード」とは、[MIME-IMB]で説明されているCTEデコードステップを指します。
Certain CTEs use an identity encoding transformation. For these CTEs there is no decoding required, however the domain of the underlying data may not be expressible in the IMAP4 protocol (e.g., MIME "binary" content containing NUL octets). To accommodate these cases the Binary extension introduces a new type of literal protocol element that is fully eight bit transparent.
特定のCTEは、変換をエンコードするIDを使用します。これらのCTEの場合、デコードは必要ありませんが、基礎となるデータのドメインはIMAP4プロトコル（例：NULオクテットを含むMIME「バイナリ」コンテンツ）で表現できない場合があります。これらのケースに対応するために、バイナリエクステンションは、完全に8ビット透明な新しいタイプのリテラルプロトコル要素を導入します。
Thus, server processing of the FETCH BINARY command involves two logical steps:
したがって、Fetch Binaryコマンドのサーバー処理には、2つの論理的な手順が含まれます。
1) perform any CTE-related decoding
1) CTE関連のデコードを実行します
2) determine the domain of the decoded data
2) デコードされたデータのドメインを決定します
Step 2 is necessary to determine which protocol element should be used to transmit the decoded data. (See FETCH Response Extensions for further details.)
ステップ2は、デコードされたデータを送信するために使用するプロトコル要素を決定するために必要です。（詳細については、Fetch Response Extensionsを参照してください。）
This memo defines the following extensions to [IMAP4rev1].
このメモは、[IMAP4REV1]への次の拡張を定義します。
IMAP4 servers that support this extension MUST include "BINARY" in the response list to the CAPABILITY command.
この拡張機能をサポートするIMAP4サーバーは、機能コマンドへの応答リストに「バイナリ」を含める必要があります。
This extension defines three new FETCH command data items.
この拡張機能は、3つの新しいFetchコマンドデータ項目を定義します。
BINARY<section-binary>[<partial>]
Requests that the specified section be transmitted after performing CTE-related decoding.
CTE関連のデコードを実行した後、指定されたセクションを送信することを要求します。
The <partial> argument, if present, requests that a subset of the data be returned. The semantics of a partial FETCH BINARY command are the same as for a partial FETCH BODY command, with the exception that the <partial> arguments refer to the DECODED section data.
<partial>引数は、存在する場合、データのサブセットを返すように要求します。部分的なFetchバイナリコマンドのセマンティクスは、<Partial>引数がデコードされたセクションデータを参照することを除いて、部分的なFetch Bodyコマンドの場合と同じです。
BINARY.PEEK<section-binary>[<partial>]
An alternate form of FETCH BINARY that does not implicitly set the \Seen flag.
\ sewフラグを暗黙的に設定しないフェッチバイナリの代替形式。
BINARY.SIZE<section-binary>
binary.size <section-binary>
Requests the decoded size of the section (i.e., the size to expect in response to the corresponding FETCH BINARY request).
セクションのデコードされたサイズ（つまり、対応するフェッチバイナリリクエストに応じて予想されるサイズ）を要求します。
Note: client authors are cautioned that this might be an expensive operation for some server implementations. Needlessly issuing this request could result in degraded performance due to servers having to calculate the value every time the request is issued.
注：クライアントの著者は、これが一部のサーバーの実装にとって高価な操作である可能性があることに注意してください。不必要にこのリクエストを発行すると、リクエストが発行されるたびに値を計算する必要があるため、パフォーマンスが低下する可能性があります。
This extension defines two new FETCH response data items.
この拡張機能は、2つの新しいフェッチ応答データ項目を定義します。
BINARY<section-binary>[<<number>>]
An <nstring> or <literal8> expressing the content of the specified section after removing any CTE-related encoding. If <number> is present it refers to the offset within the DECODED section data.
<文字列>または<リテラル8> CTE関連のエンコードを削除した後、指定されたセクションの内容を表現します。<number>が存在する場合、デコードされたセクションデータ内のオフセットを指します。
If the domain of the decoded data is "8bit" and the data does not contain the NUL octet, the server SHOULD return the data in a <string> instead of a <literal8>; this allows the client to determine if the "8bit" data contains the NUL octet without having to explicitly scan the data stream for for NULs.
デコードされたデータのドメインが「8ビット」であり、データにNUL Octetが含まれていない場合、サーバーはA <LICERAL8>の代わりに<文字列>のデータを返す必要があります。これにより、クライアントは、「8ビット」データにNULのデータストリームを明示的にスキャンすることなく、NULオクテットを含むかどうかを判断できます。
If the server does not know how to decode the section's CTE, it MUST fail the request and issue a "NO" response that contains the "UNKNOWN-CTE" extended response code.
サーバーがセクションのCTEをデコードする方法がわからない場合、リクエストに失敗し、「不明」拡張応答コードを含む「NO」応答を発行する必要があります。
BINARY.SIZE<section-binary>
binary.size <section-binary>
The size of the section after removing any CTE-related encoding. The value returned MUST match the size of the <nstring> or <literal8> that will be returned by the corresponding FETCH BINARY request.
CTE関連のエンコードを削除した後のセクションのサイズ。返される値は、対応するFetchバイナリリクエストによって返される<nstring>または<literal8>のサイズと一致する必要があります。
If the server does not know how to decode the section's CTE, it MUST fail the request and issue a "NO" response that contains the "UNKNOWN-CTE" extended response code.
サーバーがセクションのCTEをデコードする方法がわからない場合、リクエストに失敗し、「不明」拡張応答コードを含む「NO」応答を発行する必要があります。
The APPEND command is extended to allow the client to append data containing NULs by using the <literal8> syntax. The server MAY modify the CTE of the appended data, however any such transformation MUST NOT result in a loss of data.
追加コマンドは拡張されており、クライアントが<Literal8>構文を使用してNULを含むデータを追加できるようにします。サーバーは、追加されたデータのCTEを変更する場合がありますが、そのような変換はデータの損失をもたらさないはずです。
If the destination mailbox does not support the storage of binary content, the server MUST fail the request and issue a "NO" response that contains the "UNKNOWN-CTE" extended response code.
宛先メールボックスがバイナリコンテンツのストレージをサポートしていない場合、サーバーはリクエストに失敗し、「不明」拡張応答コードを含む「NO」応答を発行する必要があります。
[MIME-MHE] defines an encoding that allows for non-US-ASCII text in message headers. This encoding is not the same as the content-transfer-encoding applied to message bodies, and the decoding transformations described in this memo do not apply to [MIME-MHE] encoded header text. A server MUST NOT perform any conversion of [MIME-MHE] encoded header text in response to any binary FETCH or APPEND request.
[Mime-Mhe]は、メッセージヘッダーに非US-ASCIIテキストを可能にするエンコードを定義します。このエンコードは、メッセージ本文に適用されるコンテンツトランスファーエンコードと同じではなく、このメモに記載されているデコード変換は[MIME-MHE]エンコードヘッダーテキストには適用されません。サーバーは、バイナリフェッチまたは追加のリクエストに応じて、[MIME-MHE]エンコードヘッダーテキストの変換を実行してはなりません。
Messaging clients and servers have been notoriously lax in their adherence to the Internet CRLF convention for terminating lines of textual data in Internet protocols. When sending data using the Binary extension, servers MUST ensure that textual line-oriented sections are always transmitted using the IMAP4 CRLF line termination syntax, regardless of the underlying storage representation of the data on the server.
メッセージングクライアントとサーバーは、インターネットプロトコルのテキストデータの行を終了するために、インターネットCRLFコンベンションを順守することで有名です。バイナリ拡張機能を使用してデータを送信する場合、サーバー上のデータの基になるストレージ表現に関係なく、テキストライン指向のセクションがIMAP4 CRLFライン終端構文を使用して常に送信されるようにする必要があります。
A server may choose to store message body binary content in a non-encoded format. Regardless of the internal storage representation used, the server MUST issue BODYSTRUCTURE responses that describe the message as though the binary-encoded sections are encoded in a CTE acceptable to the IMAP4 base specification. Furthermore, the results of a FETCH BODY MUST return the message body content in the format described by the corresponding FETCH BODYSTRUCTURE response.
サーバーは、非エンコード形式でメッセージボディバイナリコンテンツを保存することを選択できます。使用される内部ストレージ表現に関係なく、サーバーは、バイナリエンコードされたセクションがIMAP4ベース仕様に許容できるCTEでエンコードされているかのように、メッセージを説明するボディ構造応答を発行する必要があります。さらに、フェッチ本体の結果は、対応するフェッチボディ構造応答で説明されている形式でメッセージ本文のコンテンツを返す必要があります。
While the server is allowed to modify the CTE of APPENDed <literal8> data, this should only be done when it is absolutely necessary. Gratuitous encoding changes will render useless most cryptographic operations that have been performed on the message.
サーバーは、Appeded <Literal8>データのCTEを変更することを許可されていますが、これは絶対に必要な場合にのみ実行する必要があります。無償のエンコード変更により、メッセージで実行されたほとんどの暗号操作が役に立たなくなります。
This extension provides an optimization that is useful in certain specific situations. It does not absolve clients from providing basic functionality (content transfer decoding) that should be available in all messaging clients. Clients supporting this extension SHOULD be prepared to perform their own CTE decoding operations.
この拡張機能は、特定の特定の状況で役立つ最適化を提供します。すべてのメッセージングクライアントで利用できるはずの基本的な機能（コンテンツ転送デコード）の提供をクライアントに免除することはできません。この拡張機能をサポートするクライアントは、独自のCTEデコード操作を実行するために準備する必要があります。
The following syntax specification uses the augmented Backus-Naur Form (ABNF) notation as used in [ABNF], and incorporates by reference the Core Rules defined in that document.
次の構文仕様は、[ABNF]で使用される拡張されたBackus-Naurフォーム（ABNF）表記を使用し、そのドキュメントで定義されているコアルールを参照することにより組み込まれます。
This syntax augments the grammar specified in [IMAP4rev1].
この構文は、[IMAP4REV1]で指定された文法を増強します。
append =/ "APPEND" SP mailbox [SP flag-list]
[SP date-time] SP literal8
fetch-att =/ "BINARY" [".PEEK"] section-binary [partial]
/ "BINARY.SIZE" section-binary
literal8 = "~{" number "}" CRLF *OCTET ; <number> represents the number of OCTETs ; in the response string.
literal8 = "〜{" number "}" crlf *octet;<number>はオクテットの数を表します。応答文字列で。
msg-att-static =/ "BINARY" section-binary SP (nstring / literal8) / "BINARY.SIZE" section-binary SP number
msg-att-static = / "binary" section-binary sp（nstring / literal8） / "binary.size" section-binary sp番号
partial = "<" number "." nz-number ">"
resp-text-code =/ "UNKNOWN-CTE"
resp-text-code =/ "不明-cte"
section-binary = "[" [section-part] "]"
section-binary = "[" [section-part] "]"
[ABNF] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF] Crocker、D.、編集者、P。
[IMAP4rev1] Crispin, M., "Internet Message Access Protocol Version 4rev1", RFC 3501, March 2003.
[IMAP4REV1] CRISPIN、M。、「インターネットメッセージアクセスプロトコルバージョン4REV1」、RFC 3501、2003年3月。
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[MIME-IMB] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[Mime-Imb] Freed、N。and N. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[MIME-MHE] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[Mime-Mhe] Moore、K。、「Mime（多目的インターネットメールエクステンション）パート3：ASCII以外のテキスト用のメッセージヘッダー拡張機能」、RFC 2047、1996年11月。
There are no known additional security issues with this extension beyond those described in the base protocol described in [IMAP4rev1].
[IMAP4REV1]に記載されている基本プロトコルに記載されているものを超えて、この拡張機能に関する追加のセキュリティの問題はありません。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
Lyndon Nerenberg Orthanc Systems 1606 - 10770 Winterburn Road Edmonton, Alberta Canada T5S 1T6
Lyndon Nerenberg Orthanc Systems 1606-10770 Winterburn Road Edmonton、Alberta Canada T5S 1T6
EMail: lyndon@orthanc.ab.ca
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
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.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
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エディター機能の資金は現在、インターネット協会によって提供されています。