Network Working Group D. Cridland
Request for Comments: 5524 Isode Limited
Category: Standards Track May 2009
Network Working Group D. Cridland
Request for Comments: 5524 Isode Limited
Category: Standards Track May 2009
Extended URLFETCH for Binary and Converted Parts
二进制和转换部件的扩展URLFETCH
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和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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
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].
尽管[URLAUTH]提供了一个URLFETCH命令，可用于取消引用URL并返回身体部位数据，但它是通过返回编码的表单来实现的，没有足够的元数据进行解码。这适用于邮件应用程序，如[BURL]，其中编码形式适用，但不适用于需要访问实际内容的应用程序，如[STREAMING]。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[关键词]中所述进行解释。
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在[CONVERT]中定义，并提供用于处理应用程序的元数据，如数据类型。
BINARY Provide the data without any 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八位字节，而不是由文本行构成。必须使用[BINARY]中定义的literal8语法传输包含NUL八位字节的数据。
BODY Provide the data as-is.
正文按原样提供数据。
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，元数据项不得出现一次以上，并且客户端不得同时请求二进制和正文。
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 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].
二进制二进制项提供内容，不应用任何内容传输编码。如果这是不可能的（例如，服务器不知道内容传输编码），则可能包含NIL。服务器必须理解[MIME]中定义的所有标识内容传输编码，以及转换编码“Base64”[Base64]和“Quoted Printable”[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.
请注意，与[CONVERT]不同，BODYPARTSTRUCTURE没有附加部件说明符，因为这在URL中是隐式的。
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
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八位字节；因此，使用了literal（而不是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
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
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
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
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
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].
这种形式语法使用[ABNF]中指定的ABNF，并包括[URLAUTH]、[BINARY]和[IMAP]中定义的产品。
capability =/ "URLAUTH=BINARY"
capability =/ "URLAUTH=BINARY"
; Command parameters; see Section 3.1
; 命令参数；见第3.1节
urlfetch = "URLFETCH" 1*(SP url-fetch-arg)
urlfetch=“urlfetch”1*（SP url fetch arg）
url-fetch-arg = url-fetch-simple / url-fetch-ext
url-fetch-arg = url-fetch-simple / url-fetch-ext
url-fetch-simple = url-full ; Unextended URLFETCH.
url fetch simple=url full；未扩展的URLETCH。
url-fetch-ext = "(" url-full *(SP url-fetch-param) ")" ; If no url-fetch-param present, as unextended.
url fetch ext=“（“url完整*（SP url fetch参数）”）”；如果不存在url fetch参数，则为未显示。
url-fetch-param = "BODY" / "BINARY" / "BODYPARTSTRUCTURE" / atom
url-fetch-param = "BODY" / "BINARY" / "BODYPARTSTRUCTURE" / atom
; Response; see Section 3.2
; 回答见第3.2节
urlfetch-data = "*" SP "URLFETCH"
1*(SP (urldata-simple / urldata-ext /
urldata-error))
urlfetch-data = "*" SP "URLFETCH"
1*(SP (urldata-simple / urldata-ext /
urldata-error))
urldata-error = SP url-full SP nil
urldata-error = SP url-full SP nil
urldata-simple = SP url-full SP nstring ; If client issues url-fetch-simple, server MUST respond with ; urldata-simple.
urldata simple=SP url full SP nstring；若客户端发出url fetch simple，则服务器必须以响应；urldata很简单。
urldata-ext = SP url-full url-metadata
urldata-ext = SP url-full url-metadata
url-metadata = 1*(SP "(" url-metadata-el ")")
url-metadata = 1*(SP "(" url-metadata-el ")")
url-metadata-el = url-meta-bodystruct / url-meta-body / url-meta-binary
url metadata el=url元体结构/url元体/url元二进制
url-meta-bodystruct = "BODYPARTSTRUCTURE" SP body
url meta bodystruct=“BODYPARTSTRUCTURE”SP body
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-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-meta-body = "BODY" SP nstring
url meta body=“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=二进制IMAP功能。IANA已相应地将其添加到注册表中。
Implementors are directed to the security considerations within [IMAP], [URLAUTH], and [BINARY].
实现者被引导到[IMAP]、[URLAUTH]和[BINARY]中的安全注意事项。
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指向的内容以及内容本身的元数据，这使得潜在攻击者能够发现有关内容的更多信息，包括其原始文件名和用户提供的描述。
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].
此信息对攻击者的附加价值是微乎其微的，仅适用于攻击者无法直接访问的URL，例如由[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.
Neil Cook、Philip Guenther、Alexey Melnikov、Ken Murchison和其他人对该想法和/或文件发表了评论。无论是同意还是不同意，评论都对本文件进行了改进，并以其他方式对本文件产生了影响。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[BASE64]Josefsson，S.，“Base16、Base32和BASE64数据编码”，RFC4648，2006年10月。
[BINARY] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, April 2003.
[二进制]Nerenberg，L.，“IMAP4二进制内容扩展”，RFC3516，2003年4月。
[CONVERT] Melnikov, A. and P. Coates, "Internet Message Access Protocol - CONVERT Extension", RFC 5259, July 2008.
[转换]Melnikov，A.和P.Coates，“互联网消息访问协议-转换扩展”，RFC 5259，2008年7月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[KEYWORDS] 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] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[URLAUTH]Crispin，M.，“互联网消息访问协议（IMAP）-URLAUTH扩展”，RFC 4467，2006年5月。
[BURL] Newman, C., "Message Submission BURL Extension", RFC 4468, May 2006.
[BURL]Newman，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]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年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
戴夫·克里德兰·伊索德有限公司位于米德尔塞克斯郡汉普顿车站路36号城堡商业村5号，邮编：TW12 2BX GB
EMail: dave.cridland@isode.com
EMail: dave.cridland@isode.com