Network Working Group D. Cridland
Request for Comments: 5524 Isode Limited
Category: Standards Track May 2009
Extended URLFETCH for Binary and Converted Parts
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
The URLFETCH command defined as part of URLAUTH provides a mechanism for third parties to gain access to data held within messages in a user's private store; however, this data is sent verbatim, which is not suitable for a number of applications. This memo specifies a method for obtaining data in forms suitable for non-mail applications.
URLAUTHの一部として定義されるのURLfetchコマンドは、第三者がユーザのプライベートストア内のメッセージ内に保持されたデータへのアクセスを得るための機構を提供します。しかし、このデータは、アプリケーションの数には適していませんこれは、そのまま送信されます。このメモは、メール以外の用途に適した形でデータを取得する方法を指定します。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Extended URLFETCH ...............................................2
3.1. Command Parameters .........................................3
3.2. Response Metadata ..........................................3
4. Example Exchanges ...............................................4
5. Formal Syntax ...................................................6
6. IANA Considerations .............................................7
7. Security Considerations .........................................7
8. Acknowledgements ................................................7
9. References ......................................................8
9.1. Normative References .......................................8
9.2. Informative References .....................................8
Although [URLAUTH] provides a URLFETCH command that can be used to dereference a URL and return the body-part data, it does so by returning the encoded form, without sufficient metadata to decode. This is suitable for use in mail applications such as [BURL], where the encoded form is suitable, but not where access to the actual content is required, such as in [STREAMING].
URL逆参照するために使用され、身体の部分のデータを返すことができるのURLfetchコマンドを提供する[URLAUTH]が、デコードするために十分なメタデータなしに、符号化された形式を返すことによってそうします。これは、エンコードされた形式が適切であるが、実際のコンテンツへのアクセスは、例えば、[配信]のように、必要とされない場合、このような[BURL]としてメールアプリケーション、で使用するのに適しています。
This memo specifies a mechanism that returns additional metadata about the part, such as its [MEDIATYPE] type, as well as removes any content transfer encoding that was used on the body part.
このメモは、その[MEDIATYPE]タイプとして、一部に関する追加のメタデータを返すだけでなく、身体の一部に使用された任意のコンテンツ転送エンコードを除去メカニズムを指定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [KEYWORDS]で説明されるように解釈されます。
Protocol examples are line-wrapped for clarity. Protocol strings are prefixed with C: and S: for client and server respectively, and elided data is represented by [...]. Implementors should note these notations are for editorial clarity only.
プロトコルの例は、明確にするために、ラインラップされています。プロトコル文字列はCが付いている：とS：クライアントとサーバーのそれぞれについて、そして省かデータは[...]で表されます。実装者は、これらの表記のみ編集明確にするためのものであり注意してください。
This extension is available in any IMAP server implementation that includes URLAUTH=BINARY within its capability string.
この拡張は、その機能文字列内URLAUTH = BINARYを含む任意のIMAPサーバの実装で使用可能です。
Such servers accept additional, per-URL parameters to the URLFETCH command and will provide, upon request, specific data for each URL dereferenced.
このようなサーバはUrlFetchのコマンドに追加、ごとのURLパラメータを受け入れ、要求に応じて、提供します、URLごとに固有のデータが間接参照しました。
The URLFETCH command is extended by the provision of optional parameters. The extended URLFETCH command is distinct by enclosing each URL and associated parameters in a parenthesized list. Cases where there is an absence of any parameters or where the URL is sent unenclosed cause the command to behave precisely as specified in [URLAUTH].
UrlFetchのコマンドは、オプションのパラメータを提供することによって拡張されます。拡張のURLfetchコマンドが括弧付きリスト内の各URLと関連するパラメータを囲むことによって区別されます。 URLは[URLAUTH]で指定された正確として動作するようにコマンド原因囲まれていない送信された任意のパラメータまたはの欠如があるケース。
Similarly, if the URL is invalid, the command will behave precisely as specified in [URLAUTH] and return a simple NIL.
URLが無効の場合同様に、コマンドは[URLAUTH]で指定されているように正確に動作し、簡単なNILを返します。
Available parameters are:
利用可能なパラメータは次のとおりです。
BODYPARTSTRUCTURE Provide a BODYPARTSTRUCTURE.
BODYPARTSTRUCTUREはBODYPARTSTRUCTUREを提供します。
BODYPARTSTRUCTURE is defined in [CONVERT] and provides metadata useful for processing applications, such as the type of data.
BODYPARTSTRUCTUREは、[変換]で定義されており、そのようなデータのタイプとして処理用途に有用なメタデータを提供しています。
BINARY Provide the data without any Content-Transfer-Encoding.
BINARYは、任意のContent-Transfer-Encodingをせずにデータを提供します。
In particular, this means that the data MAY contain NUL octets and not be formed from textual lines. Data containing NUL octets MUST be transferred using the literal8 syntax defined in [BINARY].
特に、これは、データはNULオクテットを含むことができ、テキストのラインから形成されていないことを意味します。 NULオクテットを含むデータは、[BINARY]で定義literal8構文を使用して転送されなければなりません。
BODY Provide the data as-is.
そのままBODYは、データを提供します。
This will provide the same data as the unextended [URLAUTH] as a metadata item.
これは、メタデータ項目として非伸長【URLAUTH]と同じデータを提供します。
Metadata items MUST NOT appear more than once per URL requested, and clients MUST NOT request both BINARY and BODY.
メタデータ項目は、要求されたURLに一回以上現れてはならない、とクライアントがBINARYと本体の両方を要求してはなりません。
In order to carry any requested metadata and provide additional information to the consumer, the URLFETCH response is similarly extended.
任意の要求されたメタデータを携帯し、消費者に追加情報を提供するために、のURLfetch応答も同様に拡張されます。
Following the URL itself, servers will include a series of parenthesized metadata elements. Defined metadata elements are as follows:
URL自体に続いて、サーバは、括弧で囲まれたメタデータ要素のシリーズがあります。次のように定義されたメタデータ要素は以下のとおりです。
BODYPARTSTRUCTURE The BODYPARTSTRUCTURE provides information about the data contained in the response, as it has been returned. It will reflect any conversions or decoding that have taken place. In particular, this will show an identity encoding if BINARY is also requested.
それが戻ってきたようBODYPARTSTRUCTUREザ・BODYPARTSTRUCTUREは、応答に含まれるデータについての情報を提供します。それは起こった任意の変換または復号化を反映します。 BINARYも要求された場合、特に、これはアイデンティティのエンコードが表示されます。
BINARY The BINARY item provides the content, without any content transfer encoding applied. If this is not possible (for example, the content transfer encoding is unknown to the server), then this MAY contain NIL. Servers MUST understand all identity content transfer encodings defined in [MIME], as well as the transformation encodings "Base64" [BASE64] and "Quoted-Printable" [MIME].
BINARY BINARY項目が適用されたコンテンツ転送エンコードせずに、コンテンツを提供します。これが不可能な場合（例えば、コンテンツ転送エンコードがサーバーに不明である）、これはNILを含むかもしれません。サーバーは、[MIME]で定義されたすべての同一のコンテンツ転送エンコーディング、ならびに変換エンコーディング「Base64で」[BASE64]及び「引用符で囲まれた印刷可能」[MIME]を理解しなければなりません。
BODY The BODY item provides the content as found in the message, with any content transfer encoding still applied. Requesting only the BODY will provide equivalent functionality to the unextended [URLAUTH], however, using the extended syntax described herein.
メッセージに見られるようBODY BODY項目はまだ適用されたコンテンツ転送符号化と、コンテンツを提供します。本体のみを要求することは、本明細書に記載の拡張構文を使用して、しかし、伸長していない[URLAUTH]と同等の機能を提供します。
Note that unlike [CONVERT], BODYPARTSTRUCTURE is not appended with the part specifier, as this is implicit in the URL.
これはURLで暗黙的であるようCONVERT]とは異なり、BODYPARTSTRUCTUREは、一部指定が付加されていないことに留意されたいです。
A client requests the data with no content transfer encoding.
クライアントは無いコンテンツ転送エンコードでデータを要求します。
C: A001 URLFETCH ("imap://joe@example.com/INBOX/;uid=20/;
section=1.2;urlauth=anonymous:internal:
91354a473744909de610943775f92038" BINARY)
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;
section=1.2;urlauth=anonymous:internal:
91354a473744909de610943775f92038" (BINARY {28}
S: Si vis pacem, para bellum.
S:
S: )
S: A001 OK URLFETCH completed
Note that the data here does not contain a NUL octet; therefore, a literal -- not literal8 -- syntax has been used.
ここでのデータはNULオクテットが含まれていないことに注意してください。そのため、リテラル - literal8ない - 構文が使用されてきました。
A client again requests data with no content transfer encoding, but this time requests the body structure.
クライアントは再びノーコンテンツ転送エンコードでデータを要求したが、今回はボディ構造を要求します。
C: A001 URLFETCH ("imap://joe@example.com/INBOX/;uid=20/;
section=1.3;urlauth=anonymous:internal:
ae354a473744909de610943775f92038" BINARY BODYPARTSTRUCTURE)
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;
section=1.3;urlauth=anonymous:internal:
ae354a473744909de610943775f92038" (BODYPARTSTRUCTURE
("IMAGE" "PNG" () NIL NIL "BINARY" 123)) (BINARY ~{123}
S: [123 octets of data, some of which is NUL])
S: A001 OK URLFETCH completed
A client requests only the body structure.
本体のみの構造クライアント要求。
C: A001 URLFETCH ("imap://joe@example.com/INBOX/;uid=20/;
section=1.3;urlauth=anonymous:internal:
ae354a473744909de610943775f92038" BODYPARTSTRUCTURE)
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;
section=1.3;urlauth=anonymous:internal:
ae354a473744909de610943775f92038" (BODYPARTSTRUCTURE
("IMAGE" "PNG" () NIL NIL "BASE64" 164))
S: A001 OK URLFETCH completed
A client requests the body structure and the original content.
クライアントは、身体の構造やオリジナルコンテンツを要求します。
C: A001 URLFETCH ("imap://joe@example.com/INBOX/;uid=20/;
section=1.3;urlauth=anonymous:internal:
ae354a473744909de610943775f92038" BODYPARTSTRUCTURE BODY)
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;
section=1.3;urlauth=anonymous:internal:
ae354a473744909de610943775f92038" (BODYPARTSTRUCTURE
("IMAGE" "PNG" () NIL NIL "BASE64" 164)) (BODY {164}
S: [164 octets of base64 encoded data])
S: A001 OK URLFETCH completed
Some parts cannot be decoded, so the server will provide the BODYPARTSTRUCTURE of the part as is and provide NIL for the binary content:
いくつかの部分は、復号化することができないので、サーバがあるとして、一部のBODYPARTSTRUCTUREを提供し、バイナリコンテンツ用のNILを提供します：
C: A001 URLFETCH ("imap://joe@example.com/INBOX/;uid=20/;
section=1.4;urlauth=anonymous:internal:
87ecbd02095b815e699503fc20d869c8" BODYPARTSTRUCTURE BINARY)
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;
section=1.4;urlauth=anonymous:internal:
87ecbd02095b815e699503fc20d869c8" (BODYPARTSTRUCTURE
("IMAGE" "PNG" () NIL NIL "X-BLURDYBLOOP" 123))
(BINARY NIL)
S: A001 OK URLFETCH completed
If a part simply doesn't exist, however, or the URI is invalid for some other reason, then NIL is returned instead of metadata:
一部は単に、しかし、存在しない場合、またはURIが他のいくつかの理由で無効である場合、NILは、メタデータの代わりに返されます。
C: A001 URLFETCH ("imap://joe@example.com/INBOX/;uid=20/;
section=200;urlauth=anonymous:internal:
88066d37e2e5410e1a6486350a8836ee" BODYPARTSTRUCTURE BODY)
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;
section=200;urlauth=anonymous:internal:
88066d37e2e5410e1a6486350a8836ee" NIL
S: A001 OK URLFETCH completed
This formal syntax uses ABNF as specified in [ABNF], and includes productions defined in [URLAUTH], [BINARY], and [IMAP].
この正式な構文は、[IMAP] [ABNF]で指定されるようにABNFを使用し、[BINARY]、[URLAUTH]で定義された作品を含み、。
capability =/ "URLAUTH=BINARY"
機能= / "URLAUTH = BINARY"
; Command parameters; see Section 3.1
;コマンドパラメータ。 3.1節を参照してください
urlfetch = "URLFETCH" 1*(SP url-fetch-arg)
UrlFetchの= "URLFetchの" 1 *（SPのUrlFetchの、引数）
url-fetch-arg = url-fetch-simple / url-fetch-ext
URLフェッチ、引数= URLフェッチ・シンプル/ URLフェッチ-EXT
url-fetch-simple = url-full ; Unextended URLFETCH.
URLフェッチ-シンプル= URL-いっぱい。未延伸のURLfetch。
url-fetch-ext = "(" url-full *(SP url-fetch-param) ")" ; If no url-fetch-param present, as unextended.
URLフェッチ-EXT = "（" URLフル*（SPのURLフェッチ-PARAM） "）"。ノーURLフェッチ-のparam存在、として伸長していない場合は。
url-fetch-param = "BODY" / "BINARY" / "BODYPARTSTRUCTURE" / atom
URLフェッチ-のparam = "BODY" / "BINARY" / "BODYPARTSTRUCTURE" /原子
; Response; see Section 3.2
;応答; 3.2節を参照してください
urlfetch-data = "*" SP "URLFETCH" 1*(SP (urldata-simple / urldata-ext / urldata-error))
UrlFetchのデータ= "*" SP "のURLfetch" 1 *（SP（urldata-シンプル/ urldata-EXT / urldata-エラー））
urldata-error = SP url-full SP nil
urldata-エラー= SPのURLフルSPはnil
urldata-simple = SP url-full SP nstring ; If client issues url-fetch-simple, server MUST respond with ; urldata-simple.
urldata-シンプル= SPのURLフルSPのnstring。クライアントの問題は、URLフェッチ - シンプルな場合は、サーバが応じなければなりません。 urldata-シンプル。
urldata-ext = SP url-full url-metadata
urldata-EXT = SPのURL-完全なURL、メタデータ
url-metadata = 1*(SP "(" url-metadata-el ")") url-metadata-el = url-meta-bodystruct / url-meta-body / url-meta-binary
URLメタデータ= 1 *（SP「（」URLメタデータ・エル「）」）、URLのメタデータ・エル= URL - メタ - bodystruct / URL - メタ - ボディ/ URL - メタ - バイナリ
url-meta-bodystruct = "BODYPARTSTRUCTURE" SP body
URL-メタbodystruct = "BODYPARTSTRUCTURE" SPボディ
url-meta-binary = "BINARY" SP ( nstring / literal8 ) ; If content contains a NUL octet, literal8 MUST be used. ; Otherwise, content SHOULD use nstring. ; On decoding error, NIL should be used.
URLメタバイナリ= "BINARY" SP（NSStringの/リテラル8）。コンテンツがNULLのオクテットが含まれている場合、リテラルを使用しなければなりません。 ;そうしないと、コンテンツがnstringを使用すべきです。 ;エラーをデコードするには、NILを使用する必要があります。
url-meta-body = "BODY" SP nstring
URLメタ - ボディ= "BODY" SPのnstring
IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Experimental RFC.
IMAP4機能は標準化過程かIESGが承認した実験的RFCを公開することにより、登録されています。
This document defines the URLFETCH=BINARY IMAP capability. IANA has added it to the registry accordingly.
この文書では、URLFetchの= BINARY IMAP機能を定義します。 IANAはそれに応じて、レジストリに追加しました。
Implementors are directed to the security considerations within [IMAP], [URLAUTH], and [BINARY].
実装者は[URLAUTH]、および[BINARY]、[IMAP]内のセキュリティ問題に向けられています。
The ability of the holder of a URL to be able to fetch metadata about the content pointed to by the URL as well as the content itself allows a potential attacker to discover more about the content than was previously possible, including its original filename and user-supplied description.
コンテンツに関するメタデータを取得することができるようにURLの所有者の能力は、URLによって指されるだけでなく、コンテンツ自体は元のファイル名とUSER-を含め、以前に可能であったよりも内容についての詳細を発見するために潜在的な攻撃者を可能に説明を付属。
The additional value of this information to an attacker is marginal, and applies only to those URLs for which the attacker does not have direct access, such as those produced by [URLAUTH]. Implementors are therefore directed to the security considerations present in [URLAUTH].
攻撃者がこの情報の追加の値が限界であり、そして唯一の攻撃者は、このような[URLAUTH]によって生成されるものなどの直接アクセスを持たないため、これらのURLに適用されます。実装者は、したがって、[URLAUTH]中に存在するセキュリティ問題に向けられています。
Comments were received on this idea and/or document from Neil Cook, Philip Guenther, Alexey Melnikov, Ken Murchison, and others. Whether in agreement or dissent, the comments have refined and otherwise influenced this document.
コメントはニール・クック、フィリップ・ギュンター、アレクセイ・メルニコフ、ケンマーチソン、そして他人からこのアイデアおよび/または文書で受信されました。契約または反対意見では、コメントは洗練され、そうでなければ、この文書に影響を与えたかどうか。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
、STD 68、RFC 5234、2008年1月： "ABNF構文仕様のための増大しているBNF" [ABNF]クロッカー、D.、およびP. Overell、。
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[BASE64] Josefsson氏、S.、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 4648、2006年10月。
[BINARY] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, April 2003.
[BINARY] Nerenberg、L.、 "IMAP4バイナリコンテンツ拡張"、RFC 3516、2003年4月。
[CONVERT] Melnikov, A. and P. Coates, "Internet Message Access Protocol - CONVERT Extension", RFC 5259, July 2008.
[CONVERT]メルニコフ、A.、およびP.コーツ、 "インターネットメッセージアクセスプロトコル - 拡張CONVERT"、RFC 5259、2008年7月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[URLAUTH]クリスピン、M.、 "インターネットメッセージアクセスプロトコル（IMAP） - URLAUTH拡張"、RFC 4467、2006年5月。
[BURL] Newman, C., "Message Submission BURL Extension", RFC 4468, May 2006.
[BURL]ニューマン、C.、 "メッセージ提出BURL拡張"、RFC 4468、2006年5月。
[MEDIATYPE] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[MEDIATYPE]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[STREAMING] Cook, N., "Streaming Internet Messaging Attachments", Work in Progress, March 2009.
[ストリーミング]クック、N.、「ストリーミングインターネットメッセージング添付ファイル」、進歩、2009年3月での作業。
Author's Address
著者のアドレス
Dave Cridland Isode Limited 5 Castle Business Village 36, Station Road Hampton, Middlesex TW12 2BX GB
デイブCridland ISODE限定5キャッスルビジネス村36、駅の道ハンプトン、ミドルTW12 2BX GB
EMail: dave.cridland@isode.com
メールアドレス：dave.cridland@isode.com