Network Working Group L. Nerenberg
Request for Comments: 3516 Orthanc Systems
Category: Standards Track April 2003
IMAP4 Binary Content 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 (2003). All Rights Reserved.
著作権（C）インターネット協会（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].
[KEYWORD]に記載されているようにキーワード "MUST" は、 "MUST NOT"、 "SHOULD NOT"、および本書で解釈されるべきである、 "MAY"、 "SHOULD"。
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コンテンツ転送エンコードされています。 （明示的コンテンツ転送符号化ヘッダのないものを暗黙「7ビット」コンテンツとしてラベル付けされている。）[MIME-IMB]の用語では、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は、アイデンティティのエンコーディング変換を使用しています。これらのCTEのための復号化に必要がない、しかし、基礎となるデータのドメインは、IMAP4プロトコル（NULオクテットを含む、例えば、MIME「バイナリ」コンテンツ）で表現ではないかもしれません。これらのケースに対応するためにバイナリ拡張子が完全に8ビットの透明なリテラルプロトコル要素の新しいタイプを紹介します。
Thus, server processing of the FETCH BINARY command involves two logical steps:
したがって、FETCH BINARYコマンドのサーバ処理は、二つの論理の手順を実行します。
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を参照してください。）
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サーバは、CAPABILITYコマンドに応答リストで「BINARY」を含まなければなりません。
This extension defines three new FETCH command data items.
この拡張は3つの新しいFETCHコマンドデータ項目を定義します。
BINARY<section-binary>[<partial>]
BINARY <セクションバイナリ> [<部分>]
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.
<部分>引数が、存在する場合、データのサブセットが返されることを要求します。部分FETCH BINARYコマンドのセマンティクスは<部分>引数がデコードセクションデータを参照することを除いて、部分FETCH BODYコマンドと同じです。
BINARY.PEEK<section-binary>[<partial>]
BINARY.PEEK <セクションバイナリ> [<部分>]
An alternate form of FETCH BINARY that does not implicitly set the \Seen flag.
代替形式は、暗黙のうちに\見フラグを設定しませんBINARYをFETCH。
BINARY.SIZE<section-binary>
BINARY.SIZE <セクションバイナリ>
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>>]
BINARY <セクションバイナリ> <<数>>]
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に関連する符号化を除去した後、指定されたセクションの内容を表します。 <番号>が存在する場合には、復号化区間データ内のオフセットを指します。
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オクテットが含まれていないデータは、サーバーではなく、<literal8>の<文字列>にデータを返す必要がある場合。これは「8ビット」のデータは、明示的にNULsのためのデータ・ストリームをスキャンすることなく、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をデコードする方法がわからない場合は、要求を失敗し、「UNKNOWN-CTE」拡張応答コードが含まれている「NO」の応答を発行しなければなりません。
BINARY.SIZE<section-binary>
BINARY.SIZE <セクションバイナリ>
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をデコードする方法がわからない場合は、要求を失敗し、「UNKNOWN-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.
APPENDコマンドは、クライアントが、<literal8>構文を使用してNULsを含むデータを追加できるように拡張されます。サーバーは、しかし、どのような変換は、データが失われてはならない、追加されたデータの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.
送信先のメールボックスがバイナリコンテンツの格納をサポートしていない場合、サーバーは要求を失敗し、「UNKNOWN-CTE」拡張応答コードが含まれている「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]エンコードされたヘッダテキストに適用されません。サーバは、任意のバイナリFETCHまたはAPPEND要求に応答して、[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で符号化されたかのようにメッセージを記述BODYSTRUCTURE応答を発行しなければなりません。また、FETCH BODYの結果は、対応するFETCH BODYSTRUCTURE応答によって記述された形式でメッセージボディコンテンツを返さなければなりません。
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.
サーバーが追加のCTE <literal8>データを変更することが許可されますが、それは絶対に必要であるとき、これはのみ行われるべきです。無償エンコードの変更がメッセージに対して実行されている役に立たないほとんどの暗号化操作をレンダリングします。
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]で使用される拡張バッカス・ナウアフォーム（ABNF）表記を使用し、参照によりその文書に定義されたコア規則を組み込んでいます。
This syntax augments the grammar specified in [IMAP4rev1].
この構文は[IMAP4rev1の]で指定された文法を強化します。
append =/ "APPEND" SP mailbox [SP flag-list] [SP date-time] SP literal8
= / "APPEND" SPメールボックス[SPフラグリスト] [SP日時] SPのliteral8を追加
fetch-att =/ "BINARY" [".PEEK"] section-binary [partial] / "BINARY.SIZE" section-binary
フェッチ-ATT = / "BINARY" [ ".PEEK"]セクションバイナリ[パーシャル] / "BINARY.SIZE" セクションバイナリ
literal8 = "~{" number "}" CRLF *OCTET ; <number> represents the number of OCTETs ; in the response string.
literal8 = "〜{" 番号 "}" CRLFの*オクテット。 <番号>オクテットの数を表します。応答文字列インチ
msg-att-static =/ "BINARY" section-binary SP (nstring / literal8) / "BINARY.SIZE" section-binary SP number
MSG-ATT-静的= / "バイナリ" セクションバイナリSP（リテラルNSStringの/ 8）/ "BINARY.SIZE" セクションバイナリSP数
partial = "<" number "." nz-number ">"
部分= "<" 数 "" NZ-番号 ">"
resp-text-code =/ "UNKNOWN-CTE"
RESP-テキストコード= / "UNKNOWN-CTE"
section-binary = "[" [section-part] "]"
セクションバイナリ=「[」[セクションの部分]「]」
[ABNF] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
"構文仕様のための増大しているBNF：ABNF" [ABNF]クロッカー、D.、エディタ、およびP. Overell、RFC 2234、1997年11月。
[IMAP4rev1] Crispin, M., "Internet Message Access Protocol Version 4rev1", RFC 3501, March 2003.
[IMAP4rev1の]クリスピン、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.
[KEYWORD]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、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]ムーア、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
リンドンNerenberg Orthancシステム1606から10770 Winterburnロードエドモントン、アルバータ州カナダT5S 1T6
EMail: lyndon@orthanc.ab.ca
メールアドレス：lyndon@orthanc.ab.ca
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。