RFC5259 日本語訳
5259 Internet Message Access Protocol - CONVERT Extension. A.Melnikov, Ed., P. Coates, Ed.. July 2008. (Format: TXT=63831 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Melnikov, Ed.
Request for Comments: 5259 Isode Ltd
Category: Standards Track P. Coates, Ed.
Sun Microsystems
July 2008
Network Working Group A. Melnikov, Ed. Request for Comments: 5259 Isode Ltd Category: Standards Track P. Coates, Ed. Sun Microsystems July 2008
Internet Message Access Protocol - CONVERT Extension
Internet Message Access Protocol - CONVERT Extension
Status of This Memo
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.
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.
Abstract
Abstract
CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences, or on server settings.
CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences, or on server settings.
Melnikov & Coates Standards Track [Page 1] RFC 5259 IMAP CONVERT extension July 2008
Melnikov & Coates Standards Track [Page 1] RFC 5259 IMAP CONVERT extension July 2008
Table of Contents
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Relation with Other IMAP Specifications . . . . . . . . . . . 4
3.1. CAPABILITY Response . . . . . . . . . . . . . . . . . . . 4
4. Scope of Conversions . . . . . . . . . . . . . . . . . . . . . 4
5. Discovery of Available Conversions . . . . . . . . . . . . . . 4
5.1. CONVERSIONS Command . . . . . . . . . . . . . . . . . . . 4
5.2. CONVERSION Response . . . . . . . . . . . . . . . . . . . 6
6. CONVERT and UID CONVERT Commands . . . . . . . . . . . . . . . 6
7. CONVERT Conversion Parameters . . . . . . . . . . . . . . . . 12
7.1. Mandatory-to-Implement Conversions and Conversion
Parameters . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Additional Features for Mobile Usage . . . . . . . . . . . 13
8. Request/Response Data Items to CONVERT/UID CONVERT Commands . 14
8.1. CONVERTED Untagged Response . . . . . . . . . . . . . . . 14
8.2. BODYPARTSTRUCTURE CONVERT Request and Response Item . . . 14
8.3. BINARY.SIZE CONVERT Request and Response Item . . . . . . 15
8.4. AVAILABLECONVERSIONS CONVERT Request and Response Item . . 16
8.5. Implementation Considerations . . . . . . . . . . . . . . 17
9. Status Responses and Response Code Extensions . . . . . . . . 17
10. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Manageability Considerations . . . . . . . . . . . . . . . . . 24
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12.1. Registration of unknown-character-replacement Media
Type Parameter . . . . . . . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 26
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
15.1. Normative References . . . . . . . . . . . . . . . . . . . 28
15.2. Informative References . . . . . . . . . . . . . . . . . . 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Relation with Other IMAP Specifications . . . . . . . . . . . 4 3.1. CAPABILITY Response . . . . . . . . . . . . . . . . . . . 4 4. Scope of Conversions . . . . . . . . . . . . . . . . . . . . . 4 5. Discovery of Available Conversions . . . . . . . . . . . . . . 4 5.1. CONVERSIONS Command . . . . . . . . . . . . . . . . . . . 4 5.2. CONVERSION Response . . . . . . . . . . . . . . . . . . . 6 6. CONVERT and UID CONVERT Commands . . . . . . . . . . . . . . . 6 7. CONVERT Conversion Parameters . . . . . . . . . . . . . . . . 12 7.1. Mandatory-to-Implement Conversions and Conversion Parameters . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Additional Features for Mobile Usage . . . . . . . . . . . 13 8. Request/Response Data Items to CONVERT/UID CONVERT Commands . 14 8.1. CONVERTED Untagged Response . . . . . . . . . . . . . . . 14 8.2. BODYPARTSTRUCTURE CONVERT Request and Response Item . . . 14 8.3. BINARY.SIZE CONVERT Request and Response Item . . . . . . 15 8.4. AVAILABLECONVERSIONS CONVERT Request and Response Item . . 16 8.5. Implementation Considerations . . . . . . . . . . . . . . 17 9. Status Responses and Response Code Extensions . . . . . . . . 17 10. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 20 11. Manageability Considerations . . . . . . . . . . . . . . . . . 24 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 12.1. Registration of unknown-character-replacement Media Type Parameter . . . . . . . . . . . . . . . . . . . . . . 25 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 15.1. Normative References . . . . . . . . . . . . . . . . . . . 28 15.2. Informative References . . . . . . . . . . . . . . . . . . 29
Melnikov & Coates Standards Track [Page 2] RFC 5259 IMAP CONVERT extension July 2008
Melnikov & Coates Standards Track [Page 2] RFC 5259 IMAP CONVERT extension July 2008
1. Introduction
1. Introduction
This document defines the CONVERT extension to IMAP4 [RFC3501]. CONVERT provides adaptation and transcoding of body parts as needed by the client. Conversion (adaptation, transcoding) may be requested by the client and performed by the server on a best effort basis or, when requested by the client, decided by the server based on the server's knowledge of the client capabilities, user or administrator preferences, or server settings.
This document defines the CONVERT extension to IMAP4 [RFC3501]. CONVERT provides adaptation and transcoding of body parts as needed by the client. Conversion (adaptation, transcoding) may be requested by the client and performed by the server on a best effort basis or, when requested by the client, decided by the server based on the server's knowledge of the client capabilities, user or administrator preferences, or server settings.
This extension is primarily intended to be useful to mobile clients. It satisfies requirements specified in [OMA-ME-RD].
This extension is primarily intended to be useful to mobile clients. It satisfies requirements specified in [OMA-ME-RD].
A server that supports CONVERT can convert body parts to other formats to be viewed (for example) on a mobile device. The client can explicitly request a particular conversion or ask the server to select the best available conversion. When allowed by the client, the server determines how to convert based on its own strategy (e.g., based on knowledge of the client as discussed hereafter). If the server knows the characteristics of the device (out of scope for CONVERT) or can determine them (for example, using a conversion parameter containing device type), converted body parts can also be optimized for capabilities of the device (e.g., form factor of pictures). The client is able to control conversions using optional conversion (also referred to as "transcoding" in this document) parameters.
A server that supports CONVERT can convert body parts to other formats to be viewed (for example) on a mobile device. The client can explicitly request a particular conversion or ask the server to select the best available conversion. When allowed by the client, the server determines how to convert based on its own strategy (e.g., based on knowledge of the client as discussed hereafter). If the server knows the characteristics of the device (out of scope for CONVERT) or can determine them (for example, using a conversion parameter containing device type), converted body parts can also be optimized for capabilities of the device (e.g., form factor of pictures). The client is able to control conversions using optional conversion (also referred to as "transcoding" in this document) parameters.
This document relies on the registry of conversion parameters established by [MEDIAFEAT-REG]. The registry can be used to discover the underlying legal values that these parameters can take. Additional conversion parameters, such as those defined by [OMA-STI], are expected to be registered in the future.
This document relies on the registry of conversion parameters established by [MEDIAFEAT-REG]. The registry can be used to discover the underlying legal values that these parameters can take. Additional conversion parameters, such as those defined by [OMA-STI], are expected to be registered in the future.
2. Conventions Used in This Document
2. Conventions Used in This Document
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 [RFC2119].
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 [RFC2119].
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange. The five characters [...] mean that something has been elided.
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange. The five characters [...] mean that something has been elided.
Melnikov & Coates Standards Track [Page 3] RFC 5259 IMAP CONVERT extension July 2008
Melnikov & Coates Standards Track [Page 3] RFC 5259 IMAP CONVERT extension July 2008
When describing the general syntax, some definitions are omitted as they are defined in [RFC3501]. In particular, the term "session" is used in this document as defined in Section 1.2 of [RFC3501].
When describing the general syntax, some definitions are omitted as they are defined in [RFC3501]. In particular, the term "session" is used in this document as defined in Section 1.2 of [RFC3501].
3. Relation with Other IMAP Specifications
3. Relation with Other IMAP Specifications
Conversion of attachments during streaming is out of scope for the CONVERT extension and is described in a separate Lemonade WG document [LEM-STREAMING].
Conversion of attachments during streaming is out of scope for the CONVERT extension and is described in a separate Lemonade WG document [LEM-STREAMING].
A server claiming compliance with this specification MUST support the IMAP Binary specification [RFC3516].
A server claiming compliance with this specification MUST support the IMAP Binary specification [RFC3516].
3.1. CAPABILITY Response
3.1. CAPABILITY Response
A server that supports the CONVERT extension MUST return "CONVERT" and "BINARY" in the CAPABILITY response or response code. (Client and server authors are reminded that the order of tokens returned in the CAPABILITY response or response code is arbitrary.)
A server that supports the CONVERT extension MUST return "CONVERT" and "BINARY" in the CAPABILITY response or response code. (Client and server authors are reminded that the order of tokens returned in the CAPABILITY response or response code is arbitrary.)
Example: A server that implements CONVERT.
Example: A server that implements CONVERT.
C: a000 CAPABILITY
S: * CAPABILITY IMAP4rev1 CONVERT BINARY [...]
S: a000 OK CAPABILITY completed
C: a000 CAPABILITY S: * CAPABILITY IMAP4rev1 CONVERT BINARY [...] S: a000 OK CAPABILITY completed
4. Scope of Conversions
4. Scope of Conversions
Conversions only affect what is sent to the client; the original data in the message store MUST NOT be altered. This document does not specify how the server performs conversions.
Conversions only affect what is sent to the client; the original data in the message store MUST NOT be altered. This document does not specify how the server performs conversions.
Note: The requirement that original data be unaltered allows such data to remain accessible by other clients, permits replies or forwards of the original documents, permits signature verification (the converted body parts are not likely to contain any signatures), and preserves BODYSTRUCTURE and related information.
Note: The requirement that original data be unaltered allows such data to remain accessible by other clients, permits replies or forwards of the original documents, permits signature verification (the converted body parts are not likely to contain any signatures), and preserves BODYSTRUCTURE and related information.
5. Discovery of Available Conversions
5. Discovery of Available Conversions
5.1. CONVERSIONS Command
5.1. CONVERSIONS Command
Arguments: source MIME type
target MIME type
Arguments: source MIME type target MIME type
Responses: untagged responses: CONVERSION
Responses: untagged responses: CONVERSION
Melnikov & Coates Standards Track [Page 4] RFC 5259 IMAP CONVERT extension July 2008
Melnikov & Coates Standards Track [Page 4] RFC 5259 IMAP CONVERT extension July 2008
Result: OK - CONVERSIONS command completed
BAD - unrecognized syntax of an argument, unexpected extra
argument, missing argument, etc.
Result: OK - CONVERSIONS command completed BAD - unrecognized syntax of an argument, unexpected extra argument, missing argument, etc.
The CONVERSIONS command is allowed in Authenticated and Selected IMAP states.
The CONVERSIONS command is allowed in Authenticated and Selected IMAP states.
The first parameter to the CONVERSIONS command is a source MIME type,
the second parameter is the target MIME type. Both parameters are
partially (e.g., "text/*") or completely ("*") wildcardable.
The first parameter to the CONVERSIONS command is a source MIME type, the second parameter is the target MIME type. Both parameters are partially (e.g., "text/*") or completely ("*") wildcardable.
Conversions matching the source/target pair and their associated conversion parameters are returned in untagged CONVERSION responses. If source/target doesn't match any conversion supported by the server, no CONVERSION response is returned.
Conversions matching the source/target pair and their associated conversion parameters are returned in untagged CONVERSION responses. If source/target doesn't match any conversion supported by the server, no CONVERSION response is returned.
Examples:
Examples:
For conversion information from GIF to JPEG image format (no untagged CONVERSION response would be returned if no conversion is possible):
For conversion information from GIF to JPEG image format (no untagged CONVERSION response would be returned if no conversion is possible):
C: a CONVERSIONS "image/gif" "image/jpeg"
S: * CONVERSION "image/gif" "image/jpeg" ("pix-y" "pix-x"
"image-interleave")
S: a OK CONVERSIONS completed
C: a CONVERSIONS "image/gif" "image/jpeg" S: * CONVERSION "image/gif" "image/jpeg" ("pix-y" "pix-x" "image-interleave") S: a OK CONVERSIONS completed
For conversion information from GIF image format to anything:
For conversion information from GIF image format to anything:
C: b CONVERSIONS "image/gif" "*"
S: * CONVERSION "image/gif" "image/jpeg" ("pix-y" "pix-x"
"image-interleave")
S: * CONVERSION "image/gif" "image/png" ([...])
[...]
S: b OK CONVERSIONS completed
C: b CONVERSIONS "image/gif" "*" S: * CONVERSION "image/gif" "image/jpeg" ("pix-y" "pix-x" "image-interleave") S: * CONVERSION "image/gif" "image/png" ([...]) [...] S: b OK CONVERSIONS completed
For conversion of anything to JPEG:
For conversion of anything to JPEG:
C: c CONVERSIONS "*" "image/jpeg"
S: * CONVERSION "image/gif" "image/jpeg" ("pix-y" "pix-x"
"image-interleave")
S: * CONVERSION "image/png" "image/jpeg" (...)
[...]
S: c OK CONVERSIONS completed
C: c CONVERSIONS "*" "image/jpeg" S: * CONVERSION "image/gif" "image/jpeg" ("pix-y" "pix-x" "image-interleave") S: * CONVERSION "image/png" "image/jpeg" (...) [...] S: c OK CONVERSIONS completed
For conversions from all image formats to all text formats, the client can issue the following command:
For conversions from all image formats to all text formats, the client can issue the following command:
C: d CONVERSIONS "image/*" "text/*"
C: d CONVERSIONS "image/*" "text/*"
Melnikov & Coates Standards Track [Page 5] RFC 5259 IMAP CONVERT extension July 2008
Melnikov & Coates Standards Track [Page 5] RFC 5259 IMAP CONVERT extension July 2008
5.2. CONVERSION Response
5.2. CONVERSION Response
Contents: source MIME type
target MIME type
optional list of supported conversion parameters
Contents: source MIME type target MIME type optional list of supported conversion parameters
As a result of executing a CONVERSIONS command, the server can return one or more CONVERSION responses. Each CONVERSION response specifies which source MIME type can be converted to the target MIME type, and also lists supported conversion parameters.
As a result of executing a CONVERSIONS command, the server can return one or more CONVERSION responses. Each CONVERSION response specifies which source MIME type can be converted to the target MIME type, and also lists supported conversion parameters.
6. CONVERT and UID CONVERT Commands
6. CONVERT and UID CONVERT Commands
Arguments: sequence set
conversion parameters
CONVERT data item names
Arguments: sequence set conversion parameters CONVERT data item names
Responses: untagged responses: CONVERTED
Responses: untagged responses: CONVERTED
Result: OK - convert completed
NO - convert error: can't fetch and/or convert that data
BAD - unrecognized syntax of an argument, unexpected extra
argument, missing argument, etc.
Result: OK - convert completed NO - convert error: can't fetch and/or convert that data BAD - unrecognized syntax of an argument, unexpected extra argument, missing argument, etc.
The CONVERT extension defines CONVERT and UID CONVERT commands that are used to transcode the media type of a MIME part into another media type, and/or the same media type with different encoding parameters. These commands are structured and behave similarly to FETCH/UID FETCH commands as extended by [RFC3516]:
The CONVERT extension defines CONVERT and UID CONVERT commands that are used to transcode the media type of a MIME part into another media type, and/or the same media type with different encoding parameters. These commands are structured and behave similarly to FETCH/UID FETCH commands as extended by [RFC3516]:
o A successful CONVERT/UID CONVERT command results in one or more
untagged CONVERTED responses (one per message). They are similar
to the untagged FETCH responses. Note that a single CONVERT/ UID
CONVERT command can only perform a single type of conversion as
defined by the conversion parameters. A client that needs to
perform multiple different conversions needs to issue multiple
CONVERT/UID CONVERT commands. Such a client MAY pipeline them.
o A successful CONVERT/UID CONVERT command results in one or more untagged CONVERTED responses (one per message). They are similar to the untagged FETCH responses. Note that a single CONVERT/ UID CONVERT command can only perform a single type of conversion as defined by the conversion parameters. A client that needs to perform multiple different conversions needs to issue multiple CONVERT/UID CONVERT commands. Such a client MAY pipeline them.
o BINARY[...] data item requests conversion of a body part or of the
whole message according to conversion parameters and requests that
the converted message/body part be returned as binary.
o BINARY[...] data item requests conversion of a body part or of the whole message according to conversion parameters and requests that the converted message/body part be returned as binary.
o BINARY.SIZE data item is similar to RFC822.SIZE, but it requests
size of a converted body part/message.
o BINARY.SIZE data item is similar to RFC822.SIZE, but it requests size of a converted body part/message.
o BODYPARTSTRUCTURE data item is similar to BODYSTRUCTURE FETCH data
item, but it returns the MIME structure of the converted body
part.
o BODYPARTSTRUCTURE data item is similar to BODYSTRUCTURE FETCH data item, but it returns the MIME structure of the converted body part.
Melnikov & Coates Standards Track [Page 6] RFC 5259 IMAP CONVERT extension July 2008
Melnikov & Coates Standards Track [Page 6] RFC 5259 IMAP CONVERT extension July 2008
o BODY[...HEADER] encoded words in the requested headers are
converted to the specified charset. The CHARSET parameter is
REQUIRED for this conversion.
o BODY[...HEADER] encoded words in the requested headers are converted to the specified charset. The CHARSET parameter is REQUIRED for this conversion.
o BODY[...MIME] encoded words in the requested headers are converted
to the specified charset. The CHARSET parameter is REQUIRED for
this conversion.
o BODY[...MIME] encoded words in the requested headers are converted to the specified charset. The CHARSET parameter is REQUIRED for this conversion.
o AVAILABLECONVERSIONS data item requests the list of target MIME
types the specified body part (or the whole message) can be
converted to.
o AVAILABLECONVERSIONS data item requests the list of target MIME types the specified body part (or the whole message) can be converted to.
The CONVERT extension also adds one new response code. See Section 9 for more details.
The CONVERT extension also adds one new response code. See Section 9 for more details.
Typically clients will request conversion of leaf body parts. In addition to support of leaf body part conversion, servers MAY offer conversion of non-leaf body parts (e.g., conversion from multipart/ related).
Typically clients will request conversion of leaf body parts. In addition to support of leaf body part conversion, servers MAY offer conversion of non-leaf body parts (e.g., conversion from multipart/ related).
Instead of specifying the exact target MIME media type the client wants to convert to, the client MAY use a special marker NIL (also known as "default conversion") to request the server to pick a suitable target media type. This document doesn't describe how exactly the server makes such a choice; however, some basic guidelines are described in this paragraph. If the server knows characteristics of the device using an in-band (such as device type specified in a conversion parameter) or an out-of-band mechanism, then it should convert the request body part to a media type the device is likely to support and display/play successfully. Unless specifically overridden by a conversion parameter, the server MAY also remove any unnecessary detail that exceeds the capabilities of the device (e.g., scaling images to just fit on the device's screen). In the absence of any in-band or out-of-band mechanism for determining device characteristics, the server should convert the request body part to the most standard or widely deployed media type available in that media category, for example, to convert to text/ plain, image/jpeg. In such case, the server should minimize quality loss. Servers are REQUIRED to support "default conversion" requests. Server implementations that support conversions to multiple target MIME types SHOULD make the default conversion configurable. Clients SHOULD avoid using the default conversion unless they provided a way (in-band or out-band) to signal their capabilities to the server, as there is no guaranty that the server would guess their capability correctly. Client implementors should consider using AVAILABLECONVERSIONS CONVERT data item or CONVERSIONS command instead of the default conversion.
Instead of specifying the exact target MIME media type the client wants to convert to, the client MAY use a special marker NIL (also known as "default conversion") to request the server to pick a suitable target media type. This document doesn't describe how exactly the server makes such a choice; however, some basic guidelines are described in this paragraph. If the server knows characteristics of the device using an in-band (such as device type specified in a conversion parameter) or an out-of-band mechanism, then it should convert the request body part to a media type the device is likely to support and display/play successfully. Unless specifically overridden by a conversion parameter, the server MAY also remove any unnecessary detail that exceeds the capabilities of the device (e.g., scaling images to just fit on the device's screen). In the absence of any in-band or out-of-band mechanism for determining device characteristics, the server should convert the request body part to the most standard or widely deployed media type available in that media category, for example, to convert to text/ plain, image/jpeg. In such case, the server should minimize quality loss. Servers are REQUIRED to support "default conversion" requests. Server implementations that support conversions to multiple target MIME types SHOULD make the default conversion configurable. Clients SHOULD avoid using the default conversion unless they provided a way (in-band or out-band) to signal their capabilities to the server, as there is no guaranty that the server would guess their capability correctly. Client implementors should consider using AVAILABLECONVERSIONS CONVERT data item or CONVERSIONS command instead of the default conversion.
Melnikov & Coates Standards Track [Page 7] RFC 5259 IMAP CONVERT extension July 2008
Melnikov & Coates Standards Track [Page 7] RFC 5259 IMAP CONVERT extension July 2008
CONVERT's command syntax is modeled after the FETCH command syntax in [RFC3501], as extended by [RFC3516]. CONVERT data items are generally structured as:
CONVERT's command syntax is modeled after the FETCH command syntax in [RFC3501], as extended by [RFC3516]. CONVERT data items are generally structured as:
BINARY[section-part]<partial>
BINARY[section-part]<partial>
BINARY.SIZE[section-part]
BINARY.SIZE[section-part]
BODYPARTSTRUCTURE[section-part]
BODYPARTSTRUCTURE[section-part]
BODY[HEADER]
BODY[HEADER]
BODY[section-part.HEADER]
BODY[section-part.HEADER]
BODY[section-part.MIME]
BODY[section-part.MIME]
AVAILABLECONVERSIONS[section-part]
AVAILABLECONVERSIONS[section-part]
The semantics of a partial CONVERT BINARY[...] command is the same as for a partial FETCH BODY[...] command, with the exception that the <partial> arguments refer to the TRANSCODED and DECODED section data.
The semantics of a partial CONVERT BINARY[...] command is the same as for a partial FETCH BODY[...] command, with the exception that the <partial> arguments refer to the TRANSCODED and DECODED section data.
Note that unlike the FETCH command, the CONVERT command never sets the \Seen flag on converted messages. A client wishing to mark a message with the \Seen flag would need to issue a STORE command (possibly pipelined with the CONVERT request) to do that.
Note that unlike the FETCH command, the CONVERT command never sets the \Seen flag on converted messages. A client wishing to mark a message with the \Seen flag would need to issue a STORE command (possibly pipelined with the CONVERT request) to do that.
The UID CONVERT command is different from the CONVERT command in the same way as the UID FETCH command is different from the FETCH command:
The UID CONVERT command is different from the CONVERT command in the same way as the UID FETCH command is different from the FETCH command:
o UID CONVERT takes as a parameter a sequence of UIDs instead of a
sequence of message numbers.
o UID CONVERT takes as a parameter a sequence of UIDs instead of a sequence of message numbers.
o UID CONVERT command MUST result in the UID data item in a
corresponding CONVERTED response.
o UID CONVERT command MUST result in the UID data item in a corresponding CONVERTED response.
o An EXPUNGE response MUST NOT be sent while responding to a CONVERT
command. This rule is necessary to prevent a loss of
synchronization of message sequence numbers between client and
server. Note that an EXPUNGE response MAY be sent during a UID
CONVERT command.
o An EXPUNGE response MUST NOT be sent while responding to a CONVERT command. This rule is necessary to prevent a loss of synchronization of message sequence numbers between client and server. Note that an EXPUNGE response MAY be sent during a UID CONVERT command.
Melnikov & Coates Standards Track [Page 8] RFC 5259 IMAP CONVERT extension July 2008
Melnikov & Coates Standards Track [Page 8] RFC 5259 IMAP CONVERT extension July 2008
Example: The client fetches body part section 3 in the message with the message sequence number of 2 and asks to have that attachment converted to pdf format.
Example: The client fetches body part section 3 in the message with the message sequence number of 2 and asks to have that attachment converted to pdf format.
C: a001 CONVERT 2 ("APPLICATION/PDF") BINARY[3]
S: * 2 CONVERTED (TAG "a001") (BINARY[3] {2135}
<the document in .pdf format>
)
S: a001 OK CONVERT COMPLETED
C: a001 CONVERT 2 ("APPLICATION/PDF") BINARY[3] S: * 2 CONVERTED (TAG "a001") (BINARY[3] {2135} <the document in .pdf format> ) S: a001 OK CONVERT COMPLETED
Example: The client requests for conversion of a text/html body part to text/plain and asks for a charset of us-ascii. The server cannot respect the charset conversion request because there are non-us-ascii characters in the text/html body part, so it fails the request by returning an ERROR phrase in place of the converted data (see Section 9).
Example: The client requests for conversion of a text/html body part to text/plain and asks for a charset of us-ascii. The server cannot respect the charset conversion request because there are non-us-ascii characters in the text/html body part, so it fails the request by returning an ERROR phrase in place of the converted data (see Section 9).
C: b001 CONVERT 2 ("text/plain" ("charset" "us-ascii")) BINARY[3]
S: * 2 CONVERTED (tag "b001") (BINARY[3]
(ERROR "Source text has non us-ascii" BADPARAMETERS
"text/html" "text/plain" ("charset" "us-ascii")))
S: b001 NO All conversions failed
C: b001 CONVERT 2 ("text/plain" ("charset" "us-ascii")) BINARY[3] S: * 2 CONVERTED (tag "b001") (BINARY[3] (ERROR "Source text has non us-ascii" BADPARAMETERS "text/html" "text/plain" ("charset" "us-ascii"))) S: b001 NO All conversions failed
If the client also specified the "unknown-character-replacement" conversion parameter (see Section 12.1), the same example can look like this:
If the client also specified the "unknown-character-replacement" conversion parameter (see Section 12.1), the same example can look like this:
C: b001 CONVERT 2 ("text/plain" ("charset" "us-ascii"
"unknown-character-replacement" "?")) BINARY[3]
S: * 2 CONVERTED (TAG "b001") (BINARY[3] {2135}
<the document in text/plain format with us-ascii
charset>
)
S: b001 OK CONVERT COMPLETED
C: b001 CONVERT 2 ("text/plain" ("charset" "us-ascii" "unknown-character-replacement" "?")) BINARY[3] S: * 2 CONVERTED (TAG "b001") (BINARY[3] {2135} <the document in text/plain format with us-ascii charset> ) S: b001 OK CONVERT COMPLETED
The server replaced non-us-ascii characters with a us-ascii character such as "?".
The server replaced non-us-ascii characters with a us-ascii character such as "?".
Example: The client first requests the converted size of a text/html body part converted to text/plain:
Example: The client first requests the converted size of a text/html body part converted to text/plain:
C: c000 CONVERT 2 ("TEXT/PLAIN" ("CHARSET" "us-ascii"))
BINARY.SIZE[4]
S: * 2 CONVERTED (TAG "c000") (BINARY.SIZE[4] 3135)
S: c000 OK CONVERT COMPLETED
C: c000 CONVERT 2 ("TEXT/PLAIN" ("CHARSET" "us-ascii")) BINARY.SIZE[4] S: * 2 CONVERTED (TAG "c000") (BINARY.SIZE[4] 3135) S: c000 OK CONVERT COMPLETED
Melnikov & Coates Standards Track [Page 9] RFC 5259 IMAP CONVERT extension July 2008
Melnikov & Coates Standards Track [Page 9] RFC 5259 IMAP CONVERT extension July 2008
Later on, the client requests 1000 bytes from the converted body part, starting from byte 2001:
Later on, the client requests 1000 bytes from the converted body part, starting from byte 2001:
C: c001 CONVERT 2 ("TEXT/PLAIN" ("CHARSET" "us-ascii"))
BINARY[4]<2001.1000>
S: * 2 CONVERTED (TAG "c001") (BINARY[4]<2001> {135}
<bytes 2001 - 2135 of the document in text/plain format>
)
S: c001 OK CONVERT COMPLETED
C: c001 CONVERT 2 ("TEXT/PLAIN" ("CHARSET" "us-ascii")) BINARY[4]<2001.1000> S: * 2 CONVERTED (TAG "c001") (BINARY[4]<2001> {135} <bytes 2001 - 2135 of the document in text/plain format> ) S: c001 OK CONVERT COMPLETED
The server MUST respect the target MIME type and conversion parameters specified by the client in the transcoding request. Note that some conversion parameters can restrict what kind of conversion is possible, while others can remove some restrictions.
The server MUST respect the target MIME type and conversion parameters specified by the client in the transcoding request. Note that some conversion parameters can restrict what kind of conversion is possible, while others can remove some restrictions.
It is legal for a client to request conversion of a non-leaf body part, for example, to request conversion of a multipart/* into a PDF document. However, servers implementing this extension are not required to support such conversions. Servers that support such conversions MUST return one or more CONVERSION responses in response to a 'CONVERSIONS "multipart/*" "*"' command. See Section 5.1 for more details.
It is legal for a client to request conversion of a non-leaf body part, for example, to request conversion of a multipart/* into a PDF document. However, servers implementing this extension are not required to support such conversions. Servers that support such conversions MUST return one or more CONVERSION responses in response to a 'CONVERSIONS "multipart/*" "*"' command. See Section 5.1 for more details.
The client can request header conversions using the BODY[...HEADER] CONVERT request, for example
The client can request header conversions using the BODY[...HEADER] CONVERT request, for example
C: D001 FETCH 2 BODY[HEADER]
S: * 2 FETCH (BODY[HEADER] {158}
S: Date: Mon, 20 Apr 2007 20:05:43 +0200
S: From: Peter <peter@siroe.example.com>
S: To: Alexey <alexey@siroe.example.com>
S: Subject: =?KOI8-R?Q?why encode this?=
S:
S: )
S: D001 OK
C: D002 CONVERT 2 (NIL ("CHARSET" "utf-8")) BODY[HEADER]
S: * 2 CONVERTED (TAG "d002") (BODY[HEADER] {157}
S: Date: Mon, 20 Apr 2007 20:05:43 +0200
S: From: Peter <peter@siroe.example.com>
S: To: Alexey <alexey@siroe.example.com>
S: Subject: =?UTF-8?Q?why encode this?=
S:
S: )
S: D002 OK
C: D001 FETCH 2 BODY[HEADER] S: * 2 FETCH (BODY[HEADER] {158} S: Date: Mon, 20 Apr 2007 20:05:43 +0200 S: From: Peter <peter@siroe.example.com> S: To: Alexey <alexey@siroe.example.com> S: Subject: =?KOI8-R?Q?why encode this?= S: S: ) S: D001 OK C: D002 CONVERT 2 (NIL ("CHARSET" "utf-8")) BODY[HEADER] S: * 2 CONVERTED (TAG "d002") (BODY[HEADER] {157} S: Date: Mon, 20 Apr 2007 20:05:43 +0200 S: From: Peter <peter@siroe.example.com> S: To: Alexey <alexey@siroe.example.com> S: Subject: =?UTF-8?Q?why encode this?= S: S: ) S: D002 OK
Any such request MUST include the CHARSET parameter. Upon receipt of the request, the server MUST decode any encoded words (as described in [RFC2047]) in headers and return them re-encoded in the specified
Any such request MUST include the CHARSET parameter. Upon receipt of the request, the server MUST decode any encoded words (as described in [RFC2047]) in headers and return them re-encoded in the specified
Melnikov & Coates Standards Track [Page 10] RFC 5259 IMAP CONVERT extension July 2008
Melnikov & Coates Standards Track [Page 10] RFC 5259 IMAP CONVERT extension July 2008
charset. (Note that encoded-words might not be needed if the result can be represented entirely in US-ASCII, so the server MAY replace the resulting encoded-words with their pure US-ASCII representation.) If the server can't decode any particular encoded word, for example, if the charset or encoding is not recognized, it MUST leave them as is. Servers SHOULD also support decoding of any parameters as described in [RFC2231]. Support for RFC 2231 parameters might require reformatting of header fields during conversion. Consider the following
charset. (Note that encoded-words might not be needed if the result can be represented entirely in US-ASCII, so the server MAY replace the resulting encoded-words with their pure US-ASCII representation.) If the server can't decode any particular encoded word, for example, if the charset or encoding is not recognized, it MUST leave them as is. Servers SHOULD also support decoding of any parameters as described in [RFC2231]. Support for RFC 2231 parameters might require reformatting of header fields during conversion. Consider the following
C: D011 FETCH 3 BODY[1.MIME]
S: * 3 FETCH (BODY[1.MIME] {118}
S: Content-Type: text/plain; charset=utf-8;
S: foo*0*=utf-8'fr'tr%c0;
S: foo*1*(very)=%03s_m%c0;
S: foo*2*=(nasty)%09chant
S:
S: D011 OK
C: D011 FETCH 3 BODY[1.MIME] S: * 3 FETCH (BODY[1.MIME] {118} S: Content-Type: text/plain; charset=utf-8; S: foo*0*=utf-8'fr'tr%c0; S: foo*1*(very)=%03s_m%c0; S: foo*2*=(nasty)%09chant S: S: D011 OK
The server should preserve the headers during the conversion as much as possible. In case the characters are split (legally!) between fragments of an encoded parameter, the server MUST consolidate the parameter fragments, and convert, emit, and re-fragment them as necessary in order to keep the line length less than 78. Comments embedded like this SHOULD be preserved during conversion, but clients MUST gracefully handle the situation where comments are removed entirely. If the comments are preserved, they MAY be moved after the parameter. For example (continuing the previous example):
The server should preserve the headers during the conversion as much as possible. In case the characters are split (legally!) between fragments of an encoded parameter, the server MUST consolidate the parameter fragments, and convert, emit, and re-fragment them as necessary in order to keep the line length less than 78. Comments embedded like this SHOULD be preserved during conversion, but clients MUST gracefully handle the situation where comments are removed entirely. If the comments are preserved, they MAY be moved after the parameter. For example (continuing the previous example):
C: D012 CONVERT 3 (NIL) BODY[1.MIME]
S: * 3 CONVERTED (TAG "D012") (BODY[1.MIME] {109}
S: Content-Type: text/plain; charset=utf-8;
S: foo*0*=utf-8'fr'tr%c0%03s_;
S: foo*1*=%m%c0%09chant (very)(nasty)
S:
S: D012 OK
C: D012 CONVERT 3 (NIL) BODY[1.MIME] S: * 3 CONVERTED (TAG "D012") (BODY[1.MIME] {109} S: Content-Type: text/plain; charset=utf-8; S: foo*0*=utf-8'fr'tr%c0%03s_; S: foo*1*=%m%c0%09chant (very)(nasty) S: S: D012 OK
No destination MIME type MUST be specified with BODY[HEADER], BODY[section.HEADER], or BODY[section.MIME]. That is, BODY[HEADER], BODY[section.HEADER], or BODY[section.MIME] can only be used with the "default conversion". When performing these conversions, the server SHOULD leave encoded words as encoded words. A failure to do so may alter the semantics of structured headers.
No destination MIME type MUST be specified with BODY[HEADER], BODY[section.HEADER], or BODY[section.MIME]. That is, BODY[HEADER], BODY[section.HEADER], or BODY[section.MIME] can only be used with the "default conversion". When performing these conversions, the server SHOULD leave encoded words as encoded words. A failure to do so may alter the semantics of structured headers.
Melnikov & Coates Standards Track [Page 11] RFC 5259 IMAP CONVERT extension July 2008
Melnikov & Coates Standards Track [Page 11] RFC 5259 IMAP CONVERT extension July 2008
7. CONVERT Conversion Parameters
7. CONVERT Conversion Parameters
The registry established by [MEDIAFEAT-REG] defines names of conversion parameters that can be used in the CONVERT command. Support for some conversion parameters is mandatory, as described in Section 7.1.
The registry established by [MEDIAFEAT-REG] defines names of conversion parameters that can be used in the CONVERT command. Support for some conversion parameters is mandatory, as described in Section 7.1.
According to [MEDIAFEAT-REG], conversion parameter names are case- insensitive.
According to [MEDIAFEAT-REG], conversion parameter names are case- insensitive.
The following example illustrates how target picture dimensions can be specified in a CONVERT request using the PIX-X and PIX-Y parameters defined in [DISP-FEATURES].
The following example illustrates how target picture dimensions can be specified in a CONVERT request using the PIX-X and PIX-Y parameters defined in [DISP-FEATURES].
C: e001 UID CONVERT 100 ("IMAGE/JPEG" ("PIX-X" "128"
"PIX-Y" "96")) BINARY[2]
S: * 2 CONVERTED (TAG "e001") (UID 100 BINARY[2] ~{4182}
<this part of a document is a rescaled image in
JPEG format with width=128, height=96.>
)
S: e001 OK UID CONVERT COMPLETED
C: e001 UID CONVERT100、(「イメージ/JPEG」、(「写真X」「128」「写真Y」、「96インチ) 2進の[2]S:、」 * 2CONVERTED、(TAG、「e001") (96.高さ=>) ドキュメントのこの部分のUID100BINARY[2]~4182<は幅=128があるJPEG形式において再スケーリングされたイメージです、S:、」 e001OK UID CONVERT COMPLETED
7.1. Mandatory-to-Implement Conversions and Conversion Parameters
7.1. 実装するために義務的な変換と変換パラメタ
A server implementing CONVERT MUST support charset conversions for the text/plain MIME type, and MUST support charset conversions from iso-8859-1, iso-8859-2, iso-8859-3, iso-8859-4, iso-8859-5, iso-8859-6, iso-8859-7, iso-8859-8, and iso-8859-15 to utf-8.
サーバは、CONVERT MUSTサポートがテキスト/明瞭なMIMEの種類のためのcharset変換であると実装して、iso-8859-1、iso-8859-2、iso-8859-3、iso-8859-4、iso-8859-5、iso-8859-6、iso-8859-7、iso-8859-8、およびiso-8859-15からutf-8までのサポートcharset変換を実装しなければなりません。
The server MUST list "text/plain" as an allowed destination conversion from "text/plain" MIME type (see Section 5.1). A command 'CONVERSIONS "text/plain" "text/plain"' MUST also return "charset" and "unknown-character-replacement" (see Section 12.1) as supported conversion parameters in the corresponding CONVERSION response.
サーバは「テキスト/平野」について「テキスト/明瞭な」MIMEの種類から許容目的地変換に記載しなければなりません(セクション5.1を見てください)。 また、対応するCONVERSION応答における変換パラメタであるとサポートされるようにコマンド'CONVERSIONS「テキスト/平野」「テキスト/平野」'は"charset"と「未知のキャラクタ交換」(セクション12.1を見る)を返さなければなりません。
IMAP servers implementing the CONVERT extension MUST support recognition of the "charset" [CHARSET-REG] parameter for text/plain, text/html, text/css, text/csv, text/enriched, and text/xml MIME types. Note, a server implementation is not required to support any conversion from the text MIME subtypes specified above, except for the mandatory-to-implement conversion described above. That is, a server implementation MUST support the "charset" parameter for text/ csv, only if it supports any conversion from text/csv.
CONVERT拡張子を実装するIMAPサーバは、テキスト/平野のための"charset"[CHARSET-REG]パラメタの認識、テキスト/htmlにテキスト/css、テキスト/豊かにされたテキスト/csvをサポートして、テキスト/xmlにMIMEの種類をサポートしなければなりません。 注意、サーバ実装は上で指定されたテキストMIME血液型亜型からどんな変換もサポートするのに必要ではありません、上で説明された実装するために義務的な変換を除いて。 すなわち、サーバ実装はテキスト/csvのための"charset"パラメタをサポートしなければなりません、テキスト/csvから何か変換をサポートする場合にだけ。
The server MUST support decoding of [RFC2047] headers and their conversion to UTF-8 as long as the encoded words are in one of the supported charsets.
コード化された単語がサポートしているcharsetsの1つにある限り、サーバは、[RFC2047]の解読がヘッダーと彼らの変換であるとUTF-8にサポートしなければなりません。
Melnikov & Coates Standards Track [Page 12] RFC 5259 IMAP CONVERT extension July 2008
メリニコフとコーツStandards Track[12ページ]RFC5259IMAP CONVERT拡張子2008年7月
Servers SHOULD offer additional character encoding conversions where they make sense, as character conversion libraries are generally available on many platforms.
サーバSHOULDは変換をコード化する添字をそれらが理解できるところに提供します、キャラクタ変換ライブラリが多くのプラットホームで一般に利用可能であるときに。
If the server cannot carry out the charset conversion while preserving all the characters (i.e., a source character can't be represented in the target charset), and the "unknown-character- replacement" conversion parameter is not specified, then the server MUST fail the conversion and MUST return the untagged ERROR BADPARAMETERS response (see Section 9). If the value specified in the "unknown-character-replacement" conversion itself can't be represented in the target charset, then the server MUST also fail the conversion and MUST return the untagged ERROR BADPARAMETERS response (see Section 9).
サーバがすべてのキャラクタを保持している間、charset変換を行うことができないで(目標charsetですなわち、ソースキャラクタの代理をされることができません)、「未知のキャラクタの交換」の変換パラメタが指定されないなら、サーバは、変換に失敗しなければならなくて、untagged ERROR BADPARAMETERS応答を返さなければなりません(セクション9を見てください)。 目標charsetに「未知のキャラクタ交換」変換自体で指定された値を表すことができないなら、サーバは、また、変換に失敗しなければならなくて、untagged ERROR BADPARAMETERS応答を返さなければなりません(セクション9を見てください)。
7.2. Additional Features for Mobile Usage
7.2. モバイル用法のための付加的な機能
This section is informative.
このセクションは有益です。
Based on the expected usage of CONVERT in mobile environments, server implementors should consider support for the following conversions:
モバイル環境におけるCONVERTの予想された使用法に基づいて、サーバ作成者は以下の変換のサポートを考えるべきです:
o Conversion of HTML and XHTML documents to text/plain in ways that
preserve at the minimum the document structure and tables.
o 最小限でドキュメント構造とテーブルを保存する方法でテキスト/平野へのHTMLとXHTMLドキュメントの変換。
o Image conversions among the types image/gif, image/jpeg, and
image/png for at least the following parameters:
o 少なくとも以下のパラメタのためのタイプのイメージ/gif、イメージ/jpeg、およびイメージ/pngの中の画像変換:
* size limit (i.e., reduce quality)
* サイズ限界(すなわち、品質を減少させます)
* width ("pix-x" parameter)
* 幅(「写真x」パラメタ)
* height ("pix-y" parameter)
* 高さ(「写真y」パラメタ)
* resize directive (crop, stretch, aspect ratio)
* リサイズ指示(作物、伸び、アスペクトレシオ)
The support for "depth" may also be of interest.
また、「深さ」のサポートも興味があるかもしれません。
Audio conversion is also of interest but the relevant formats depend significantly on the usage context.
また、オーディオ変換も興味がありますが、関連形式は用法文脈にかなり依存します。
Melnikov & Coates Standards Track [Page 13] RFC 5259 IMAP CONVERT extension July 2008
メリニコフとコーツStandards Track[13ページ]RFC5259IMAP CONVERT拡張子2008年7月
8. Request/Response Data Items to CONVERT/UID CONVERT Commands
8. 転向者/UID変換コマンドへの要求/応答データ項目
8.1. CONVERTED Untagged Response
8.1. 変換されたUntagged応答
Contents: convert correlator
CONVERTED return data items
コンテンツ: 相関器CONVERTEDリターンデータ項目を変換してください。
The CONVERTED response may be sent as a result of a successful, partially successful, or unsuccessful CONVERT or UID CONVERT command specified in Section 6.
セクション6で指定されたうまくいっているか、部分的にうまくいっているか、失敗のCONVERTかUID CONVERTコマンドの結果、CONVERTED応答を送るかもしれません。
The CONVERTED response starts with a message number, followed by the "CONVERTED" label. The label is followed by a convert correlator, which contains the tag of the command that caused the response to be returned. This can be used by a client to match a CONVERTED response against a corresponding CONVERT/UID CONVERT command.
CONVERTED応答はメッセージ番号から始まります、続いて、「変換された」ラベルから始まります。 転向者相関器はラベルのあとに続いています。(それは、応答を返したコマンドのタグを含みます)。 クライアントは、対応するCONVERT/UID CONVERTコマンドに対してCONVERTED応答に合うのにこれを使用できます。
The convert correlator is followed by a list of one or more CONVERT return data items. If the UID data item is returned, it MUST be returned as the first data item in the CONVERTED response. This requirement is to simplify client implementations. See Section 10 and the remainder of Section 8 for more details.
1つ以上のCONVERTリターンデータ項目のリストは転向者相関器のあとに続いています。UIDデータ項目を返すなら、CONVERTED応答における最初のデータ項目としてそれを返さなければなりません。 この要件はクライアント実装を簡素化することです。 その他の詳細に関してセクション8のセクション10と残りを見てください。
8.2. BODYPARTSTRUCTURE CONVERT Request and Response Item
8.2. BODYPARTSTRUCTUREは要求と応答項目を変換します。
BODYPARTSTRUCTURE[section-part]
BODYPARTSTRUCTURE[セクション一部]
The CONVERT extension defines the BODYPARTSTRUCTURE CONVERT data item. Data contained in the BODYPARTSTRUCTURE return data item follows the exact syntax specified in the [RFC3501] BODYSTRUCTURE data item, but only contains information for the converted part. All information contained in BODYPARTSTRUCTURE pertains to the state of the part after it is converted, such as the converted MIME type, sub- type, size, or charset. Note that the client can expect the returned MIME type to match the one it requested (as the server is required to obey the requested MIME type) and can treat mismatch as an error.
CONVERT拡張子はBODYPARTSTRUCTURE CONVERTデータ項目を定義します。 BODYPARTSTRUCTUREリターンデータ項目に含まれたデータは、[RFC3501]BODYSTRUCTUREデータ項目で指定された正確な構文に従いますが、変換された部分のための情報を含むだけです。 それが変換された後にBODYPARTSTRUCTUREに含まれたすべての情報が部分の状態に関係します、変換されたMIMEの種類、サブタイプ、サイズ、またはcharsetなどのように。 クライアントが返されたMIMEの種類がそれが要求した(サーバが要求されたMIMEの種類に従うのに必要であるときに)ものに合っていると予想できて、誤りとしてミスマッチを扱うことができることに注意してください。
The returned BODYPARTSTRUCTURE data MUST match the BINARY data returned for exactly the same conversion in the same IMAP "session". This requirement allows a client to request BODYPARTSTRUCTURE and BINARY data in separate commands in the same IMAP session.
返されたBODYPARTSTRUCTUREデータは同じIMAP「セッション」におけるまさに同じ変換のために返されたBINARYデータに合わなければなりません。 この要件で、クライアントは同じIMAPセッションにおける別々のコマンドにおけるBODYPARTSTRUCTUREとBINARYデータを要求できます。
If the client lists a BODYPARTSTRUCTURE data item for a section-part before a BINARY data item for the same section-part, then, in the CONVERTED response, the server MUST return the BODYPARTSTRUCTURE data prior to the corresponding BINARY data. Also, any BODYSTRUCTURE data
クライアントがBINARYデータ項目の前に同じセクション一部のためにBODYPARTSTRUCTUREデータ項目をセクション一部に記載するなら、CONVERTED応答では、サーバは対応するBINARYデータの前にBODYPARTSTRUCTUREデータを返さなければなりません。 どんなBODYSTRUCTUREデータも
Melnikov & Coates Standards Track [Page 14] RFC 5259 IMAP CONVERT extension July 2008
メリニコフとコーツStandards Track[14ページ]RFC5259IMAP CONVERT拡張子2008年7月
items MUST be after the UID data item if the UID data item is present. Both requirements are to simplify handling of converted data in clients.
UIDデータ項目が存在しているなら、UIDデータ項目の後に、項目があるに違いありません。 両方の要件はクライアントの変換されたデータの取り扱いを簡素化することです。
Example:
C: e002 CONVERT 2 (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY[2]
BODYPARTSTRUCTURE[2])
S: * 2 CONVERTED (TAG "e002") (BODYPARTSTRUCTURE[2] ("IMAGE"
"JPEG" () NIL NIL "8bit" 4182 NIL NIL NIL) BINARY[2]
~{4182}
<this part of a document is a rescaled image in
JPEG format with width=128, height=96.>
)
S: e002 OK CONVERT COMPLETED
例: C: e002 CONVERT2、(NIL、(「写真X」「128」「写真Y」、「96インチ) (バイナリー[2]BODYPARTSTRUCTURE[2]) S:、」 * 2CONVERTED、(TAG、「e002") (96.高さ=>) ドキュメントのこの部分のBODYPARTSTRUCTURE[2](「イメージ」「8ビット」4182の無い無い無無"JPEG"()無)バイナリー[2]~4182<は幅=128があるJPEG形式において再スケーリングされたイメージです、S:、」 e002OK CONVERT COMPLETED
8.3. BINARY.SIZE CONVERT Request and Response Item
8.3. BINARY.SIZEは要求と応答項目を変換します。
BINARY.SIZE[section-part]
BINARY.SIZE[セクション一部]
This item requests the converted size of the section (i.e., the size to expect in a response to the corresponding CONVERT BINARY request). The returned value MUST be exact and MUST NOT change during a duration of an IMAP "session", unless the message is expunged in another session (see below). This allows a client to download a converted part in chunks (using "<partial>"). This requirement means that in most cases the server needs to perform conversion of the requested body part before returning its size.
この項目はセクション(すなわち、対応するCONVERT BINARY要求への応答で予想するサイズ)の変換されたサイズを要求します。 戻り値は、正確でなければならなく、IMAP「セッション」の持続時間の間、変化してはいけません、メッセージが別のセッションのときに梢消されない場合(以下を見てください)。 これで、クライアントは塊で変換された部分をダウンロードできます(「<の部分的な>」を使用して)。 この要件は、多くの場合、サーバが、サイズを返す前に要求された身体の部分の変換を実行する必要を意味します。
If the message is expunged in another session, then the server MAY return the value 0 in response to the BINARY.SIZE request item later in the same session.
メッセージが別のセッションのときに梢消されるなら、サーバは後での同じセッションにおけるBINARY.SIZE要求の品目に対応して値0を返すかもしれません。
In order to allow for upgrade of server transcoding components, clients MUST NOT assume that repeating a particular body part conversion in another IMAP "session" would yield the same result as a previous conversion of the very same body part -- any characteristics of the converted body part might be different (format, size, etc.). In particular, clients MUST NOT cache sizes of converted messages/ body parts beyond duration of any IMAP "session", or use sizes obtained in one connection in another IMAP connection to the same server.
サーバコード変換コンポーネントのアップグレードを考慮するために、クライアントは、別のIMAP「セッション」における特定のボディー部分変換を繰り返すと全く同じ身体の部分の前の変換と同じ結果がもたらされると仮定してはいけません--変換された身体の部分のどんな特性も異なっているかもしれません(形式、サイズなど)。 クライアントは、特に、どんなIMAP「セッション」の持続時間を超えて変換されたメッセージ/身体の部分のサイズをキャッシュしてはいけませんし、また別のIMAP接続という1つの接続で得られたサイズを同じサーバに使用してはいけません。
Historical note: Previous experience with IMAP servers that returned estimated RFC822.SIZE value shows that this caused interoperability problems. If the server returns a value that is smaller than the actual size, this will result in data truncation if <partial>
歴史的な注意: およそRFC822.SIZE値を返したIMAPサーバの以前の経験は、これが相互運用性問題を引き起こしたのを示します。サーバが実サイズより小さい値を返すと、これは<の部分的な>であるならデータトランケーションをもたらすでしょう。
Melnikov & Coates Standards Track [Page 15] RFC 5259 IMAP CONVERT extension July 2008
メリニコフとコーツStandards Track[15ページ]RFC5259IMAP CONVERT拡張子2008年7月
download is used. If the server returns a value that is bigger than the actual size, this might mislead a client to believe that it doesn't have enough storage to download a body part.
ダウンロードは使用されています。 サーバが実サイズより大きい値を返すなら、これは、それには身体の部分をダウンロードできるくらいのストレージがないと信じるためにクライアントをミスリードするかもしれません。
Note for client implementors: client authors are cautioned that this might be an expensive operation for some server implementations. Requesting BINARY.SIZE for a large number of converted body parts or for multiple conversions of the same body part can result in slow performance and/or excessive server load and is discouraged. Client implementors should consider implementation approaches that limit this request to only the most necessary cases and are encouraged to test the performance impact of BINARY.SIZE with multiple server implementations.
クライアント作成者によって以下に注意してください。 クライアント作者はこれがいくつかのサーバ実装のための高価な操作であるかもしれないと警告されます。 多くの変換された身体の部分か同じ身体の部分の複数の変換のためにBINARY.SIZEを要求するのは、遅い性能、そして/または、過度のサーバ負荷をもたらすことができて、お勧めできないです。 クライアント作成者は、この要求を最も必要なケースだけに制限する実装アプローチを考えるべきであり、複数のサーバ実装でBINARY.SIZEの性能影響をテストするよう奨励されます。
8.4. AVAILABLECONVERSIONS CONVERT Request and Response Item
8.4. AVAILABLECONVERSIONSは要求と応答項目を変換します。
AVAILABLECONVERSIONS[section-part] allows the client to request the list of target MIME types the specified body part of a message or the whole message can be converted to. This data item is only useful when the default conversion (see Section 6) is requested.
AVAILABLECONVERSIONS[セクション一部]はメッセージか全体のメッセージの指定された身体の部分の目標MIMEの種類のリストを変えることができるようクライアントを要求させます。 デフォルト変換(セクション6を見る)が要求されているときだけ、このデータ項目は役に立ちます。
This data item MUST return a list of target MIME types that is a subset of the list returned by the CONVERSIONS command for the same source and target MIME type pairs. If specific conversion is requested, it MUST return the target MIME type as requested in the CONVERT command, or the ERROR phrase.
このデータ項目は同じソースと目標MIMEの種類組CONVERSIONSコマンドで返されたリストの部分集合である目標MIMEの種類のリストを返さなければなりません。 特定の変換が要求されるなら、それは要求された通りCONVERTコマンド、またはERROR句で目標MIMEの種類を返さなければなりません。
For both specific or default conversion requests, if conversion parameters are specified, then the server must take them into consideration when generating the list of target MIME types. For example, if one or more of the conversion parameters doesn't apply to a potential target MIME type, then such MIME type MUST be omitted from the resulting list. If the server only had a single target MIME type candidate and it was discarded due to the list of conversion parameters, then the server SHOULD return the ERROR phrase instead of the empty list of the target MIME types.
目標MIMEの種類のリストを生成するとき、ともに特定であるかデフォルト変換要求のために、変換パラメタが指定されるなら、サーバはそれらを考慮に入れなければなりません。 例えば、変換パラメタの1つ以上が仮想ターゲットMIMEの種類に適用されないなら、結果として起こるリストからそのようなMIMEの種類を省略しなければなりません。 サーバには単独の目標MIMEの種類候補がいるだけであり、それが変換パラメタのリストのため捨てられたなら、サーバSHOULDは目標MIMEの種類の空のリストの代わりにERROR句を返します。
The AVAILABLECONVERSIONS request SHOULD be processed quickly if specified by itself. Note that if a MIME type is returned in response to the AVAILABLECONVERSIONS, there is no guaranty that the corresponding BINARY/BINARY.SIZE/BODYPARTSTRUCTURE CONVERT request will not fail.
AVAILABLECONVERSIONSは、それ自体で指定されるならSHOULDがすぐに処理されるよう要求します。 AVAILABLECONVERSIONSに対応してMIMEの種類を返すなら、対応するBINARY/BINARY.SIZE/BODYPARTSTRUCTURE CONVERTが失敗しないよう要求する保証が全くないことに注意してください。
Example:
C: f001 CONVERT 2 (NIL) (AVAILABLECONVERSIONS[2])
S: * 2 CONVERTED (TAG "f001") (AVAILABLECONVERSIONS[2]
(("IMAGE/JPEG" "application/PostScript"))
S: f001 OK CONVERT COMPLETED
例: C: f001 CONVERT2(NIL)、(AVAILABLECONVERSIONS[2]) S: * 2CONVERTED、(TAG、「f001") S: (AVAILABLECONVERSIONS[2](「アプリケーション/ポストスクリプト」という「イメージ/JPEG」))f001OK転向者は完成しました」。
Melnikov & Coates Standards Track [Page 16] RFC 5259 IMAP CONVERT extension July 2008
メリニコフとコーツStandards Track[16ページ]RFC5259IMAP CONVERT拡張子2008年7月
8.5. Implementation Considerations
8.5. 実装問題
Note that this section is normative.
このセクションが規範的であることに注意してください。
Servers MAY refuse to execute conversion requests that convert multiple messages and/or body parts at once, e.g., a conversion request that specifies multiple message numbers/UIDs. If the server refuses a conversion because the request lists too many messages, the server MUST return the MAXCONVERTMESSAGES response code (see Section 9). For example:
サーバは、すぐに複数のメッセージ、そして/または、身体の部分を変換する変換要求を実行するのを拒否するかもしれません、例えば、複数のメッセージ番号/UIDsを指定する変換要求。 要求があまりに多くのメッセージをリストアップするのでサーバが変換を拒否するなら、サーバはMAXCONVERTMESSAGES応答コードを返さなければなりません(セクション9を見てください)。 例えば:
C: g001 CONVERT 1:* ("text/plain" ("charset" "us-ascii"))
BINARY[3]
S: g001 NO [MAXCONVERTMESSAGES 1]
C: g001 CONVERT1: *、(「テキスト/平野」、("charset"、「私たち、-、ASCII、」、)、BINARY[3] S: g001ノー[MAXCONVERTMESSAGES1]
If the server refuses a conversion because the request lists too many body parts, the server MUST return the MAXCONVERTPARTS response code (see Section 9). For example:
要求があまりに多くの身体の部分を記載するのでサーバが変換を拒否するなら、サーバはMAXCONVERTPARTS応答コードを返さなければなりません(セクション9を見てください)。 例えば:
C: h001 CONVERT 1 ("text/plain" ("charset" "us-ascii"))
(BINARY[1] BINARY[2])
C: h001 CONVERT1、(「テキスト/平野」、("charset"、「私たち、-、ASCII、」、)(バイナリー[1]バイナリー[2])
S: g001 NO [MAXCONVERTPARTS 1] You can only request 1 body part at
any given time
S: 与えられた何時でも1つの身体の部分ご要望だけであることができるg001ノー[MAXCONVERTPARTS1]
Note for server implementors: In order to improve performance, implementations SHOULD cache converted body parts. For example, the server may perform a body part conversion when it receives the first BINARY.SIZE[...], BODYPARTSTRUCTURE[...], or BINARY[...] request and cache it until the client requests conversion/download of another body part, a different conversion of the same body part, or until the mailbox is closed. In order to mitigate denial-of-service attacks from misbehaving or badly-written clients, a server SHOULD limit the number of converted body parts it can cache. Servers SHOULD be able to cache at least 2 conversions at any given time.
サーバ作成者によって以下に注意してください。 性能を向上させるために、SHOULDがキャッシュする実装は身体の部分を変換しました。 例えば、クライアントが別の身体の部分の変換/ダウンロード、同じ身体の部分の異なった変換を要求するか、またはメールボックスが終えられるまで、サーバは、[…]、BODYPARTSTRUCTURE[…]、またはBINARY[…]が要求する最初のBINARY.SIZEを受けるとき、ボディー部分変換を実行して、それをキャッシュするかもしれません。 ふらちな事をするのからのサービス不能攻撃かひどく書かれたクライアントを緩和するために、SHOULDが数を制限するサーバはそれがキャッシュできる身体の部分を変換しました。 サーバSHOULD、その時々で少なくとも2変換をキャッシュできてください。
9. Status Responses and Response Code Extensions
9. 状態応答と応答コード拡張
A syntactically invalid MIME media type SHOULD generate a BAD tagged response from the server. An unrecognized MIME media type generates a NO tagged response.
SHOULDがBADを生成するシンタクス上無効のMIMEメディアタイプはサーバから応答にタグ付けをしました。認識されていないMIMEメディアタイプはいいえのタグ付けをされた応答を生成します。
Some transcodings may require parameters. If a transcoding request with no parameters is sent for a format which requires parameters, the server will return an ERROR MISSINGPARAMETERS phrase in place of the data associated with the data items requested. This is analogous to the NIL response in FETCH, but with structured data associated with the failure.
いくつかのコード変換がパラメタを必要とするかもしれません。 パラメタを必要とする形式のためにパラメタのないコード変換要求を送ると、サーバは要求されているデータ項目に関連しているデータに代わってERROR MISSINGPARAMETERS句を返すでしょう。 これは、FETCHのNIL応答に類似していますが、失敗に関連している構造化されたデータで類似しています。
Melnikov & Coates Standards Track [Page 17] RFC 5259 IMAP CONVERT extension July 2008
メリニコフとコーツStandards Track[17ページ]RFC5259IMAP CONVERT拡張子2008年7月
If the server is unable to perform the requested conversion because a resource is temporary unavailable (e.g., lack of disk space, temporary internal error, transcoding service down), then the server MUST return a tagged NO response that SHOULD contain the TEMPFAIL response code (see below), or an ERROR TEMPFAIL phrase.
リソースが入手できない状態で(例えば、椎間腔の不足、一時的な内部エラー、下にコード変換サービス)一時的であるのでサーバが要求された変換を実行できないなら、サーバはTEMPFAIL応答コード(以下を見る)、またはERROR TEMPFAIL句をSHOULDが含むタグ付けをされたいいえ応答に返さなければなりません。
If the requested conversion cannot be performed because of a permanent error, for example, if a proprietary document format has no existing transcoding implementation, the server MUST return a CONVERTED response containing a ERROR BADPARAMETERS or ERROR MISSINGPARAMETERS phrase.
例えば、独占ドキュメント・フォーマットにどんな既存のコード変換実装もないなら永続エラーのために要求された変換を実行できないなら、サーバはERROR BADPARAMETERSを含むCONVERTED応答かERROR MISSINGPARAMETERS句を返さなければなりません。
The server MAY choose to return one ERROR phrase for a single conversion if several related data items are requested. For instance:
いくつかの関連するデータ項目が要求されるなら、サーバは、ただ一つの変換のための1つのERROR句を返すのを選ぶかもしれません。 例えば:
C: b002 CONVERT 2 ("text/plain" ("charset" "us-ascii"))
(BINARY[3] BODYPARTSTRUCTURE[3])
S: * 2 CONVERTED (tag "b002") (BODYPARTSTRUCTURE[3]
(ERROR "Source text has non us-ascii" BADPARAMETERS
"text/html" "text/plain" ("charset" "us-ascii")))
S: b002 NO All conversions failed
C: b002 CONVERT2、(「テキスト/平野」、("charset"、「私たち、-、ASCII、」、)、(BINARY[3] BODYPARTSTRUCTURE[3]) S: * 2CONVERTED、(タグ、「b002")、(BODYPARTSTRUCTURE[3]、(「原始テキストには、非私たちのASCIIがあり」BADPARAMETERSというERRORの「テキスト/htmlである」「テキスト/平野」、("charset"、「私たち、-、ASCII、」、)、S:、」 b002いいえAll変換は失敗しました。
If at least one conversion succeeds, the server MUST return an OK response. If all conversions fail, the server MAY return OK or NO. For instance:
少なくとも1であるなら、変換は成功して、サーバはOK応答を返さなければなりません。 すべての変換が失敗するなら、サーバ5月のリターンOKかNO.です。 例えば:
C: b002 CONVERT 2 ("text/plain" ("charset" "us-ascii"))
(BINARY[3] BODYPARTSTRUCTURE[3] BINARY[4]
BODYPARTSTRUCTURE[4])
S: * 2 CONVERTED (tag "b002") (BODYPARTSTRUCTURE[3]
(ERROR "Source text has non us-ascii" BADPARAMETERS
"text/html" "text/plain" ("charset" "us-ascii"))
BODYSTRUCTURE[4] ("TEXT" "PLAIN" (CHARSET US-ASCII)
NIL NIL "8bit" 4182 NIL NIL NIL) BINARY[4] {4182}
<body in text plain>
)
S: b002 OK Some conversions failed
C: b002 CONVERT2、(「テキスト/平野」、("charset"、「私たち、-、ASCII、」、)、(BINARY[3] BODYPARTSTRUCTURE[3] BINARY[4] BODYPARTSTRUCTURE[4]) S: * 2CONVERTED、(タグ、「b002")、(BODYPARTSTRUCTURE[3]、(「原始テキストには、非私たちのASCIIがあり」BADPARAMETERSというERRORの「テキスト/htmlである」「テキスト/平野」、("charset"、「私たち、-、ASCII、」、)、BODYSTRUCTURE[4]、(「8はテキストの明瞭な>) Sで」 4182年の無い無い無) 2進の[4]4182<ボディーに噛み付いた」「テキスト」「明瞭な」(CHARSET米国-ASCII)無い無 b002OK Some変換は失敗しました。
In general, the client can tell from the BODYPARTSTRUCTURE response whether or not its request was honored exactly, but may not know the reasons why.
一般に、クライアントは、BODYPARTSTRUCTURE応答から要求がまさに光栄に思っていたかどうか言うことができますが、理由を知らないかもしれません。
This document defines the following response codes that can be returned in the tagged NO response code.
このドキュメントはタグ付けをされたいいえ応答コードで返すことができる以下の応答コードを定義します。
TEMPFAIL - The transcoding request failed temporarily. It might
succeed later, so the client MAY retry.
TEMPFAIL--コード変換要求は一時失敗しました。 それが後で成功するかもしれないので、クライアントは再試行するかもしれません。
Melnikov & Coates Standards Track [Page 18] RFC 5259 IMAP CONVERT extension July 2008
メリニコフとコーツStandards Track[18ページ]RFC5259IMAP CONVERT拡張子2008年7月
MAXCONVERTMESSAGES <number> - The server is unable or unwilling to
convert more than <number> messages in any given CONVERT/UID
CONVERT request.
MAXCONVERTMESSAGES<番号>--サーバは、どんな与えられたCONVERT/UID CONVERTの>メッセージも要求する<番号ほど変換したがっていません。
MAXCONVERTPARTS <number> - The server is unable or unwilling to
convert more than <number> body parts of a message at once in
any given CONVERT/UID CONVERT request.
MAXCONVERTPARTS<番号>--サーバは、すぐにどんな与えられたCONVERT/UID CONVERTのメッセージの>身体の部分も要求する<番号ほど変換したがっていません。
The word ERROR is always followed by an informal human-readable descriptive text, which is followed by the convert-error-code. The convert-error-code MUST be one of the following:
非公式の人間読み込み可能な説明文はいつもERRORという単語のあとに続いています。(転向者エラーコードはそれのあとに続きます)。 転向者エラーコードは以下の1つでなければなりません:
TEMPFAIL mm - The transcoding request failed temporarily. It might
succeed later, so the client MAY retry. The client SHOULD wait
for at least mm minutes before retrying.
TEMPFAIL mm--コード変換要求は一時失敗しました。 それが後で成功するかもしれないので、クライアントは再試行するかもしれません。 クライアントSHOULDは少なくとも再試行する数分前のmmを待っています。
BADPARAMETERS from-concrete-mime-type to-mime-type
"(" transcoding-params ")" -
The listed parameters were not understood, not valid for the
source/destination MIME type pair, had invalid values or could
not be honored for another reason noted in the human-readable
text that was specified after the ERROR label. The
transcoding-params can be omitted, in which case, it means that
the conversion from the from-concrete-mime-type to the to-mime-
type is not possible. If the from-concrete-mime-type is NIL,
this means that the specified body part doesn't exist. All
unrecognized or irrelevant parameters MUST be listed in the
transcoding-params. It is not legal behavior to ignore
irrelevant parameters.
「(「コード変換-params」)」という具体的なパントマイムからパントマイムタイプにタイプしているBADPARAMETERS--記載されたパラメタは、ソース/目的地MIMEの種類組に有効であるのではなく、理解していなかったか、無効の値を持っていないか、誤りラベルの後に指定された人間読み込み可能なテキストに述べられた別の理由で光栄に思うことができません。 コード変換-paramsを省略できて、その場合、それを意味する、コンクリートパントマイムタイプからの変換、-パントマイムタイプは可能ではありません。 具体的なパントマイムタイプがNILであるなら、これは、指定された身体の部分が存在しないことを意味します。 コード変換-paramsにすべての認識されていないか無関係のパラメタをリストアップしなければなりません。無関係のパラメタを無視するのは、法的な振舞いではありません。
Note that if the client requested the "default conversion" (see
Section 6), the to-mime-type contains the destination MIME type
chosen by the server.
クライアントが「デフォルト変換」を要求したなら(セクション6を見てください)、パントマイムタイプがサーバによって選ばれた目的地MIMEの種類を含むことに注意してください。
MISSINGPARAMETERS from-concrete-mime-type to-mime-type
"(" transcoding-params ")" -
The listed parameters are required for conversion of the
specified source MIME type to the destination MIME type, but
were not seen in the request. Note that if the client
requested the "default conversion" (see Section 6), the to-
mime-type contains the destination MIME type chosen by the
server.
「(「コード変換-params」)」という具体的なパントマイムからパントマイムタイプにタイプしているMISSINGPARAMETERS--記載されたパラメタは、指定されたソースMIMEの種類の変換に目的地MIMEの種類に必要でしたが、要求で見られませんでした。 クライアントが「デフォルト変換」を要求したなら(セクション6を見てください)それに注意してください、-、パントマイムタイプはサーバによって選ばれた目的地MIMEの種類を含んでいます。
Melnikov & Coates Standards Track [Page 19] RFC 5259 IMAP CONVERT extension July 2008
メリニコフとコーツStandards Track[19ページ]RFC5259IMAP CONVERT拡張子2008年7月
Examples:
例:
C: b002 CONVERT 2 ("APPLICATION/PDF") BINARY[3]
S: b002 NO [TEMPFAIL] All conversions failed
C: b002 CONVERT2(「アプリケーション/PDF」)バイナリー[3]S: すべての変換が失敗したb002ノー[TEMPFAIL]
C: b003 CONVERT 2 ("TEXT/PLAIN") BINARY[3]
S: * 2 CONVERTED (tag "b003") (BINARY[3]
(ERROR "CHARSET must be specified for text conversions"
MISSINGPARAMETERS (CHARSET)))
S: b003 NO All conversions failed
C: b003 CONVERT2(「テキスト/明瞭な」)バイナリー[3]S: * 「2CONVERTED、(タグ、「b003")、(BINARY[3]、(ERROR、」 」 テキスト変換MISSINGPARAMETERS(CHARSET)SにCHARSETを指定しなければなりません: b003いいえAll変換は失敗しました。
C: b005 CONVERT 2 ("TEXT/PLAIN" (CHARSET "US-ASCII"
UNKNOWN-CHARACTER-REPLACEMENT "<badchar>")) BINARY[3]
S: * 2 CONVERTED (tag "b005") (BINARY[3]
(ERROR "UNKNOWN-CHARACTER-REPLACEMENT limited to 4
bytes" BADPARAMETERS (UNKNOWN-CHARACTER-REPLACEMENT
"<badchar>")))
S: b005 NO All conversions failed
C: b005 CONVERT2(「テキスト/明瞭な」(CHARSET「米国-ASCII」未知のキャラクタ交換「<badchar>」))バイナリー[3]S: * 「2CONVERTED、(タグ、「b005") (BINARY[3](」 ERROR」 4に制限されたUNKNOWNキャラクターREPLACEMENTバイトBADPARAMETERS(UNKNOWNキャラクターREPLACEMENT「<badchar>」))S: b005いいえAll変換は失敗しました。
10. Formal Syntax
10. 正式な構文
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]で使用されるように増大しているBN記法(ABNF)記法を使用して、参照でそのドキュメントで定義されたコア規則を取り入れます。
This syntax augments the grammar specified in [RFC3501] and [RFC3516]. Non-terminals not defined in this document can be found in [RFC3501], [RFC3516], [IMAPABNF], [MIME-MTSRP], and [MEDIAFEAT-REG].
この構文は[RFC3501]と[RFC3516]で指定された文法を増大させます。 [RFC3501]、[RFC3516]、[IMAPABNF]、[MIME-MTSRP]、および[MEDIAFEAT-REG]で本書では定義されなかった非端末は見つけることができます。
command-select =/ convert
コマンド選んだ=/転向者
uid =/ "UID" SP convert
; Unique identifiers used instead of message
; sequence numbers
uid=/"UID"SPは変換します。 メッセージの代わりに使用されるユニークな識別子。 一連番号
convert = "CONVERT" SP sequence-set SP convert-params SP
( convert-att /
"(" convert-att *(SP convert-att) ")" )
=「転向者」SPシーケンスセットSP転向者-params SPを変換してください。(「(「転向者-att*(SP転向者-att)」)」という転向者-att/)
convert-att = "UID" /
"BODYPARTSTRUCTURE" section-convert /
"BINARY" section-convert [partial] /
"BINARY.SIZE" section-convert /
"BODY[HEADER]" /
"BODY[" section-part ".HEADER]" /
"BODY[" section-part ".MIME]" /
"AVAILABLECONVERSIONS" section-convert
-attに"BINARY.SIZE"セクション="BODYPARTSTRUCTURE"セクション"UID"/転向者/「バイナリー」セクション転向者[部分的な]/転向者/「ボディー[ヘッダー]」/を変換してください、「ボディー、[「「.HEADER]」 /をセクションで分けてください、「ボディー、[「セクション一部「.MIME]」 /「AVAILABLECONVERSIONS」セクション転向者」
Melnikov & Coates Standards Track [Page 20] RFC 5259 IMAP CONVERT extension July 2008
メリニコフとコーツStandards Track[20ページ]RFC5259IMAP CONVERT拡張子2008年7月
; <partial> is defined in [RFC3516].
; <section-part> is defined in [RFC3501].
; <の部分的な>は[RFC3516]で定義されます。 ; <部パート>は[RFC3501]で定義されます。
convert-params = "(" (quoted-to-mime-type / default-conversion)
[SP "(" transcoding-params ")"] ")"
転向者-paramsは「(「(パントマイムタイプに引用された/デフォルト変換)[「(「コード変換-params」)」というSP]」)」と等しいです。
quoted-to-mime-type = DQUOTE to-mime-type DQUOTE
タイプをまねているパントマイムタイプに引用された=DQUOTE DQUOTE
transcoding-params = transcoding-param
*(SP transcoding-param)
コード変換-paramsはコード変換-param*と等しいです。(SPコード変換-param)
transcoding-param-names = transcoding-param-name
*(SP transcoding-param-name)
コード変換param名はコード変換param名の*と等しいです。(SPコード変換param名)
transcoding-param = transcoding-param-name SP
transcoding-param-value
コード変換-paramはコード変換param名のSPコード変換param価値と等しいです。
transcoding-param-name = astring
; <transcod-param-name-nq> represented as a quoted,
; literal or atom. Note that
; <transcod-param-name-nq> allows for "%", which is
; not allowed in atoms. Such values must be
; represented as quoted or literal.
コード変換param名はastringと等しいです。 aが引用したように表された<transcod-param名前nqな>。 リテラルか原子。 それに注意してください。 >が「%」許容する<transcod-param名前-nq、どれがあるか。 原子そのようなものに許容されないで、値はそうでなければなりません。 引用されるか文字通りとして、表されます。
transcod-param-name-nq = Feature-tag
; <Feature-tag> is defined in [MEDIAFEAT-REG].
transcod-param名前nqは特徴タグと等しいです。 <の特徴タグ>は[MEDIAFEAT-REG]で定義されます。
transcoding-param-value = astring
コード変換param価値はastringと等しいです。
default-conversion = "NIL"
デフォルト変換=「無」
message-data =/ nz-number SP "CONVERTED" SP convert-correlator
SP convert-msg-attrs
メッセージデータnz=/番号SPはSP転向者相関器SP転向者-msg-attrsを「変換しました」。
convert-correlator = "(" "TAG" SP tag-string ")"
「(「「タグ」SPタグストリング」)」という転向者相関器=
tag-string = string
; tag of the command that caused
; the CONVERTED response, sent as
; a string.
タグストリングはストリングと等しいです。 それが引き起こしたコマンドのタグ。 CONVERTED応答であって、送られる、。 ストリング。
convert-msg-attrs = "(" convert-msg-att *(SP convert-msg-att) ")"
; "UID" MUST be the first data item, if present.
転向者-msg-attrsは「(「転向者-msg-att*(SP転向者-msg-att)」)」と等しいです。 存在しているなら、"UID"は最初のデータ項目であるに違いありません。
convert-msg-att = msg-att-semistat / msg-att-conv-static
転向者-msg-attはmsg-att-semistat / msg-att-conv-静電気と等しいです。
msg-att-conv-static = "UID" SP uniqueid
; MUST NOT change for a message
msg-att-conv-静電気は"UID"SP uniqueidと等しいです。 aのための変化は通信してはいけませんか?
Melnikov & Coates Standards Track [Page 21] RFC 5259 IMAP CONVERT extension July 2008
メリニコフとコーツStandards Track[21ページ]RFC5259IMAP CONVERT拡張子2008年7月
msg-att-semistat =
( "BINARY" section-convert ["<" number ">"] SP
(nstring / literal8 / converterror-phrase) ) /
( "BINARY.SIZE" section-convert SP
(number / converterror-phrase) ) /
( "BODYPARTSTRUCTURE" section-convert SP
(body / converterror-phrase) ) /
( "AVAILABLECONVERSIONS" section-convert SP
(mimetype-list / converterror-phrase) )
; MUST NOT change during an IMAP "session",
; but not necessarily static in the long term.
msg-att-semistatは/("BINARY.SIZE"セクション転向者SP(converterror数/句))/("BODYPARTSTRUCTURE"セクション転向者SP(converterrorボディー/句))/(「AVAILABLECONVERSIONS」セクション転向者SP(converterror mimetype-リスト/句))と等しいです(「2進」のセクション転向者["<"番号">"]SP(converterror nstring/literal8/句))。 IMAP「セッション」の間、変化してはいけません。 しかし、長期に必ず静的であるというわけではありません。
section-convert = section-binary
; <section-binary> is defined in [RFC3516].
;
; Note that unlike [RFC3516], conversion
; of a top level multipart/* is allowed.
セクション転向者はセクションバイナリーと等しいです。 <部2進の>は[RFC3516]で定義されます。 ; ; [RFC3516]、変換と異なってそれに注意してください。 トップレベルでは、複合/*は許容されています。
resp-text-code =/ "TEMPFAIL" /
"MAXCONVERTMESSAGES" SP nz-number /
"MAXCONVERTPARTS" SP nz-number
; <resp-text-code> is defined in [RFC3501].
respテキストコード=/"TEMPFAIL"/「MAXCONVERTMESSAGES」SP nz-番号/「MAXCONVERTPARTS」SP nz-番号。 <resp-テキストコード>は[RFC3501]で定義されます。
mimetype-and-params = quoted-to-mime-type
[SP "(" transcoding-params ")"]
; always includes a specific MIME type
パントマイムタイプに引用されたmimetypeとparams=[「(「コード変換-params」)」というSP]。 いつも特定のMIMEの種類を含んでいます。
mimetype-list = "(" "(" [quoted-to-mime-type
*(SP quoted-to-mime-type)] ")" ")"
; Unordered list of MIME types. It can be empty.
;
; Two levels of parenthesis is needed to distinguish this
; data from <converterror-phrase>.
mimetype-リスト=、「(「「(「[*(パントマイムタイプに引用されたSP)をパントマイムタイプに引用します]」)、」、」、)、」、。 MIMEの種類の順不同のリスト。 それは空である場合があります。 ; ; 2つのレベルの挿入句がこれを区別するのに必要です。 <からのデータは>をconverterror言葉で表します。
converterror-phrase = "(" "ERROR" SP
convert-err-descript SP convert-error-code ")"
converterror-句の=、「(「「誤り」SP、転向者が間違える、descript SP、転向者エラーコード、」、)、」
convert-error-code = "TEMPFAIL" [SP nz-number]
/ bad-params
/ missing-params
なくなった悪い転向者エラーコード="TEMPFAIL"[SP nz-数]/params/params
convert-err-descript = string
; Human-readable text explaining the conversion error.
; The default charset is US-ASCII, unless
; the LANGUAGE command [IMAP-I18N] is called, when
; the charset changes to UTF-8.
転向者がdescriptに間違えている=ストリング。 変換誤りがわかる人間読み込み可能なテキスト。 ; デフォルトcharsetが米国-ASCIIである、。 LANGUAGEコマンド[IMAP-I18N]はいつ呼ばれるか。 charsetはUTF-8に変化します。
quoted-from-mime-type = DQUOTE from-concrete-mime-type DQUOTE
具体的なパントマイムからタイプしているパントマイムタイプから引用された=DQUOTE DQUOTE
Melnikov & Coates Standards Track [Page 22] RFC 5259 IMAP CONVERT extension July 2008
メリニコフとコーツStandards Track[22ページ]RFC5259IMAP CONVERT拡張子2008年7月
bad-params = "BADPARAMETERS"
1*(SP (quoted-from-mime-type / nil)
SP mimetype-and-params)
; nil is only returned when the body part doesn't exist.
悪いparamsが「BADPARAMETERS」1*と等しい、(SP(パントマイムタイプから引用された/無) SP mimetypeとparams)。 身体の部分が存在しないときだけ、無を返します。
missing-params = "MISSINGPARAMETERS"
1*(SP quoted-from-mime-type SP
mimetype-and-missing-params)
なくなったparamsは「MISSINGPARAMETERS」1*と等しいです。(SPはパントマイムタイプからSP mimetypeとなくなったparamsを引用しました)
mimetype-and-missing-params = quoted-to-mime-type
"(" transcoding-param-names ")"
; always includes a specific MIME type
「(「コード変換param名」)」というパントマイムタイプに引用されたmimetypeとなくなったparams=。 いつも特定のMIMEの種類を含んでいます。
concrete-mime-type = type-name "/" subtype-name
; i.e., "type/subtype".
; type-name and subtype-name
; are defined in [MIME-MTSRP].
「=が」 /とタイプで命名する具体的なパントマイムタイプ」「副-タイプ」-名。 すなわち、「タイプ/「副-タイプ」。」 ; 型名と「副-タイプ」-名前。 [MIME-MTSRP]では、定義されます。
from-concrete-mime-type = concrete-mime-type
具体的なパントマイムタイプから、具体的なパントマイムタイプと等しいです。
to-mime-type = concrete-mime-type
タイプをまねている=具体的なパントマイムタイプ
command-auth =/ conversions-cmd
コマンド-auth変換=/cmd
conversions-cmd = "CONVERSIONS" SP from-mime-type-req SP
to-mime-type-req
変換-cmdはパントマイムタイプreq SPからのパントマイムタイプreqの「変換」SPと等しいです。
from-mime-type-req = astring
; "mime-type-req" represented as IMAP <atom>,
; <quoted> or <literal>
パントマイムタイプreqから、astringと等しいです。 「パントマイムタイプreq」はIMAP<原子として>を表しました。 <は>か<の文字通りの>を引用しました。
to-mime-type-req = astring
; <mime-type-req> represented as IMAP <atom>,
; <quoted> or <literal>.
; Note that <mime-type-req> allows for "*",
; which is not allowed in <atom>. Such values must
; be represented as <quoted> or <literal>.
タイプreqをまねている=astring。 >がIMAP<原子>として表した<パントマイムタイプ-req。 <は>か<の文字通りの>を引用しました。 ; >が「*」のために許容するその<パントマイムタイプ-reqに注意してください。 <原子>で、許容されていません。 そのような値はそうしなければなりません。 <が>か<の文字通りの>を引用したので、表されてください。
any-mime-type = "*"
どんなパントマイムタイプも「*」と等しいです。
mime-type-req = any-mime-type /
(type-name "/" any-mime-type) /
concrete-mime-type
; '*', 'type/*' or 'type/subtype'.
; type-name is defined in [MIME-MTSRP].
パントマイムタイプreqはどんなパントマイムタイプ/とも等しいです。「(」 どんなパントマイムタイプも) /具体的なパントマイムタイプと」 /をタイプで命名してください。 '*'、'タイプ/*'または'タイプ/「副-タイプ」'。 ; 型名は[MIME-MTSRP]で定義されます。
response-payload =/ conversion-data
応答ペイロード変換=/データ
Melnikov & Coates Standards Track [Page 23] RFC 5259 IMAP CONVERT extension July 2008
メリニコフとコーツStandards Track[23ページ]RFC5259IMAP CONVERT拡張子2008年7月
conversion-data = "CONVERSION" SP quoted-from-mime-type SP
quoted-to-mime-type
[SP "(" transcoding-param-name
*(SP transcoding-param-name) ")"]
変換データはパントマイムタイプに引用された「変換」SPのパントマイムタイプから引用されたSPと等しいです。[「(「コード変換param名の*(SPコード変換param名)」)」というSP]
11. Manageability Considerations
11. 管理可能性問題
The monitoring of CONVERT operation is similar to monitoring of the IMAP FETCH operation.
CONVERT操作のモニターはIMAP FETCH操作のモニターと同様です。
At the time of writing this document, there is no standard IMAP MIB defined. Similarly, a standard MIB for monitoring CONVERT operations and their failures does not exist. However, the authors believe that in the absence of such a MIB, server implementations SHOULD provide operators with tools to report the following information:
このドキュメントを書く時点で、IMAP MIBが定義した規格が全くありません。 同様に、モニターしているCONVERT操作とそれらの失敗のための標準のMIBは存在していません。 しかしながら、作者は、そのようなMIBが不在のときサーバ実装SHOULDが以下の情報を報告するためにツールをオペレータに提供すると信じています:
o which conversions (source and target MIME types and possibly
conversion parameters used) are invoked more frequently and how
long they take,
o どの変換(ソース、目標MIMEの種類、およびことによるとパラメタが使用した変換)が、より頻繁に呼び出されるか、そして、それらはどれくらいかかりますか?
o information about conversion errors and which error condition
caused them (see Section 9), and
o そして変換誤りの情報とどのエラー条件がそれら(セクション9を見る)を引き起こしたか。
o information about users which invoke conversion operation.
o 変換操作を呼び出すユーザの情報。
This information can help operators to detect client abuse of this extension and scalability issues that might arise from its use.
この情報は、オペレータが使用から起こるかもしれないこの拡大とスケーラビリティ問題のクライアント虐待を検出するのを助けることができます。
Standardizing these tools may be the subject of future work.
これらのツールを標準化するのは、今後の活動の対象であるかもしれません。
12. IANA Considerations
12. IANA問題
IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Experimental RFC. This document defines the CONVERT IMAP capability. IANA has added this extension to the IANA IMAP Capability registry.
IMAP4能力は、Standards TrackかIESGによって承認されたExperimental RFCを発行することによって、登録されます。 このドキュメントはCONVERT IMAP能力を定義します。 IANAはIANA IMAP Capability登録にこの拡大を加えました。
IANA has performed registrations as defined in the following subsections.
IANAは以下の小区分で定義されるように登録証明書を実行しました。
Melnikov & Coates Standards Track [Page 24] RFC 5259 IMAP CONVERT extension July 2008
メリニコフとコーツStandards Track[24ページ]RFC5259IMAP CONVERT拡張子2008年7月
12.1. Registration of unknown-character-replacement Media Type
Parameter
12.1. 未知のキャラクタ交換メディアType Parameterの登録
IANA has added the following registration to the registry established by RFC 2506.
IANAはRFC2506によって確立された登録に以下の登録を加えました。
To: "Media feature tags mailing list"
<media-feature-tags@apps.ietf.org>
To: 「メディア機能がメーリングリストにタグ付けをする、「 <media-feature-tags@apps.ietf.org 、gt;、」
Subject: Registration of media feature tag
unknown-character-replacement
Subject: メディア機能の登録は未知のキャラクタ交換にタグ付けをします。
Media feature tag name:
unknown-character-replacement
メディアはタグ名を特徴とします: 未知のキャラクタ交換
ASN.1 identifier associated with feature tag:
1.3.6.1.8.1.33
特徴タグに関連しているASN.1識別子: 1.3.6.1.8.1.33
Summary of the media feature indicated by this feature tag:
Allows servers that can perform charset conversion for text/plain
text/html, text/css, text/csv, text/enriched, and text/xml MIME
types to replace characters not supported by the target charset
with a fixed string, such as "?".
This feature tag is also applicable to other conversions
to text, e.g., conversion of images using OCR (optical
character recognition).
この特徴タグによって示されたメディア機能の概要: テキスト/プレーンテキスト/htmlのためにcharset変換を実行できるサーバ、テキスト/cssにテキスト/豊かにされたテキスト/csvを許容して、“?"などの固定ひもで目標charsetによってサポートされなかったキャラクタを取り替えるテキスト/xml MIMEの種類に許容します。 また、この特徴タグもテキストへの他の変換、例えば、OCR(光学文字認識)を使用するイメージの変換に適切です。
Values appropriate for use with this feature tag:
The feature tag contains a UTF-8 string used to replace any
characters from the source media type that can't be
represented in the target media type.
この特徴タグによる使用に、適切な値: 特徴タグは目標メディアタイプで代理をされることができないソースメディアタイプからどんなキャラクタも取り替えるのに使用されるUTF-8ストリングを含んでいます。
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms:
IMAP CONVERT extension [RFC5259]
特徴タグは主として以下のアプリケーション、プロトコル、サービス、または交渉メカニズムにおける使用のために意図します: IMAP CONVERT拡張子[RFC5259]
Examples of typical use:
C: b001 CONVERT 2 BINARY[3 ("text/plain" ("charset"
"us-ascii" "unknown-character-replacement" "?"))]
典型的な使用に関する例: C: b001 CONVERT2BINARY[3、(「テキスト/平野」、("charset"、「私たち、-、ASCII、」、「未知のキャラクタ交換」“?"]
Related standards or documents:
[RFC5259]
[CHARSET-REG]
関連規格かドキュメント: [RFC5259][CHARSET-レッジ]
Considerations particular to use in individual applications,
protocols, services, or negotiation mechanisms:
None
個々のアプリケーションで使用するために特定の問題、プロトコル、サービス、または交渉メカニズム: なし
Melnikov & Coates Standards Track [Page 25] RFC 5259 IMAP CONVERT extension July 2008
メリニコフとコーツStandards Track[25ページ]RFC5259IMAP CONVERT拡張子2008年7月
Interoperability considerations: None
相互運用性問題: なし
Security considerations: None
セキュリティ問題: なし
Additional information:
This media feature only make sense for MIME types that
also support the "charset" media type parameter
[CHARSET-REG].
追加情報: このメディア機能はまた、"charset"メディアが型引数[CHARSET-REG]であるとサポートするMIMEの種類のために理解できるだけです。
Name(s) & email address(es) of person(s) to contact for further
information:
Alexey Melnikov <alexey.melnikov@isode.com>
人の(s)とEメールアドレス(es)を詳細のために連絡する(s)と命名してください: Alexey Melnikov <alexey.melnikov@isode.com 、gt。
Intended usage:
COMMON
意図している用法: 一般的
Author/Change controller:
IETF
コントローラを書くか、または変えてください: IETF
Requested IANA publication delay:
None
要求されたIANA公表遅れ: なし
Other information:
None
他の情報: なし
13. Security Considerations
13. セキュリティ問題
It is to be noted that some conversions may present security threats (e.g., converting a document to a damaging executable, exploiting a buffer overflow in a media codec/parser, or a denial-of-service attack against a client or a server such as requesting an image be scaled to extremely large dimensions). Server SHOULD refuse to execute CPU-expensive conversions. Servers should avoid dangerous conversions if possible. Whenever possible, servers should perform verification of the converted attachments before returning them to the client. Clients should be careful when requesting conversions or processing transformed attachments. Clients SHOULD use mutual Simple Authentication and Security Layer (SASL) authentication and the SASL/ TLS integrity layer, to make sure they are talking to trusted servers.
いくつかの変換が軍事的脅威(例えば、メディアコーデック/パーサでバッファオーバーフローを利用して、実行可能な破損にドキュメントを変換するか、またはイメージが非常に大きい規模に合わせて調整されるよう要求などなどのクライアントかサーバに対するサービス不能攻撃)を提示するかもしれないことに注意されることになっています。 サーバSHOULDは、CPU高価な変換を実行するのを拒否します。 できれば、サーバは危険な変換を避けるべきです。 可能であるときはいつも、それらをクライアントに返す前に、サーバは変換された付属の検証を実行するべきです。 変換か処理が付属を変えたよう要求するとき、クライアントは慎重であるはずです。 念のため彼らは、クライアントSHOULDが互いのSimple AuthenticationとSecurity Layer(SASL)認証とSASL/ TLS保全層を使用すると信じられたサーバと話しています。
When the client requests a server-side conversion of a signed body part (e.g., a part inside multipart/signed), there is no way for the client to verify that the converted content is authentic. A client not trusting the server to perform conversion of a signed body part can download the signed object, verify the signature, and perform the conversion itself.
クライアントが署名している身体の部分(例えば、複合か署名される中の部分)のサーバサイド変換を要求するとき、クライアントが変換された内容が正統であることを確かめる方法が全くありません。 署名している身体の部分の変換を実行するためにサーバを信じないクライアントは、署名しているオブジェクトをダウンロードして、署名について確かめて、変換自体を実行できます。
Melnikov & Coates Standards Track [Page 26] RFC 5259 IMAP CONVERT extension July 2008
メリニコフとコーツStandards Track[26ページ]RFC5259IMAP CONVERT拡張子2008年7月
A client can create a carefully crafted bad message with the APPEND command followed by the CONVERT command to attack the server. If the server's conversion function or library has a security problem (such as vulnerability to a buffer overflow), this could result in privilege escalation or denial of service. In order to mitigate such attacks, servers SHOULD log the client authentication identity on APPEND and/or CONVERT operations in order to facilitate tracking of abusive clients. Also server implementors SHOULD isolate the conversion function or library from the privileged mailstore, perhaps by running it within a distinct process.
サーバを攻撃するCONVERTコマンドがAPPENDコマンドのあとに続いていて、クライアントは慎重に作られた悪いメッセージを作成できます。サーバの変換機能かライブラリに警備上の問題(バッファオーバーフローへの脆弱性などの)があるなら、これはサービスの特権増大か否定をもたらすかもしれません。 そのような攻撃を緩和して、サーバSHOULDは、APPEND、そして/または、CONVERT操作のときに虐待的なクライアントに追跡するのを容易にするためにクライアント認証のアイデンティティを登録します。 また、サーバ作成者SHOULDは特権があるmailstoreから変換機能かライブラリを隔離します、恐らく特異的な過程の中でそれを実行することによって。
Deployments in which the actual transcoding is done outside the IMAP server in a separate server are recommended to keep the servers in the same trusted domain (e.g., subnet).
実際のコード変換が別々のサーバのIMAPサーバの外で行われる展開が同じ信じられたドメイン(例えば、サブネット)にサーバを保つことが勧められます。
14. Acknowledgments
14. 承認
Stephane H. Maes and Ray Cromwell from Oracle edited several earlier versions of this document. Their contribution is gratefully acknowledged.
オラクルからのステファーヌH.メースとレイ・クロムウェルはこのドキュメントのいくつかの以前のバージョンを編集しました。 彼らの貢献は感謝して承諾されます。
The authors want to specifically acknowledge the excellent criticism and comments received from Randall Gellens (Qualcomm), Arnt Gulbrandsen (Oryx), Zoltan Ordogh (Nokia), Ben Last (Emccsoft), Dan Karp (Zimbra), Pete Resnick (Qualcomm), Chris Newman (Sun), Ted Hardie (Qualcomm), Larry Masinter (Adobe), Philip Guenther (Sendmail), Greg Vaudreuil (Alcatel-Lucent), David Harrington (Comcast), Dave Cridland (Isode), Pasi Eronen (Nokia), Magnus Westerlund (Ericsson), and Jari Arkko (Ericsson), which improved the quality of this specification considerably.
作者は明確にランドルGellens(クアルコム)から受けられた素晴らしい批評とコメントを承諾したがっています、Arnt Gulbrandsen(オリックス)、ゾルタンOrdogh(ノキア)、ベンLast(Emccsoft)、ダン・カープ(Zimbra)、ピートレズニック(クアルコム)、クリス・ニューマン(Sun)、テッド・ハーディー(クアルコム); ラリーMasinter(Adobe)とフィリップ・グンサー(センドメール)とグレッグ・ボードルイ(アルカテル透明な)、デヴィッド・ハリントン(コムキャスト)とデーヴCridland(Isode)とパシEronen(ノキア)、マグヌスWesterlund(エリクソン)とヤリArkko(エリクソン)。(そのArkkoはこの仕様の品質をかなり改良しました)。
The authors would also like to specially thank Dave Cridland for the MEDIACAPS command proposal and Dan Karp for the CONVERSIONS command proposal.
特に、また、作者はCONVERSIONSコマンド提案のためにMEDIACAPSコマンド提案とダン・カープについてデーヴCridlandに感謝したがっています。
The authors also want to thank all who have contributed key insight and extensively reviewed and discussed the concepts of CONVERT and its predecessor P-IMAP. In particular, this includes the authors of the LCONVERT document: Rafiul Ahad (Oracle Corporation), Eugene Chiu (Oracle Corporation), Ray Cromwell (Oracle Corporation), Jia-der Day (Oracle Corporation), Vi Ha (Oracle Corporation), Wook-Hyun Jeong (Samsung Electronics Co. LTF), Chang Kuang (Oracle Corporation), Rodrigo Lima (Oracle Corporation), Stephane H. Maes (Oracle Corporation), Gustaf Rosell (Sony Ericsson), Jean Sini (Symbol Technologies), Sung-Mu Son (LG Electronics), Fan Xiaohui (China Mobile Communications Corporation (CMCC)), and Zhao Lijun (China Mobile Communications Corporation (CMCC)).
また、作者は手広くCONVERTとその前任者P-IMAPの概念を主要な洞察を寄付して、再検討して、議論したすべてに感謝したがっています。 特に、これはLCONVERTドキュメントの作者を含んでいます: Rafiul Ahad(オラクル株式会社)、ユージンチウ(オラクル株式会社)、レイクロムウェル(オラクル株式会社)佳-der日ハ、(オラクル株式会社)、vi(オラクル株式会社)((三星電子社のLTF)、Wook-ヒュンジュンチャンKuang(オラクル株式会社)、ロドリゴ・リマ(オラクル株式会社)・ステファーヌH); メース(オラクル株式会社)、Gustaf Rosell(ソニーエリクソン)、ジーンSini(シンボル技術)(歌われたμ息子(LG電子))はXiaohui(中国移動通信社(CMCC))、およびチャオLijun(中国移動通信社(CMCC))を扇ぎます。
Melnikov & Coates Standards Track [Page 27] RFC 5259 IMAP CONVERT extension July 2008
メリニコフとコーツStandards Track[27ページ]RFC5259IMAP CONVERT拡張子2008年7月
15. References
15. 参照
15.1. Normative References
15.1. 引用規格
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
エド[ABNF]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、STD68、RFC5234、2008年1月。
[CHARSET-REG] Hoffman, P., "Registration of Charset and Languages
Media Features Tags", RFC 2987, November 2000.
[CHARSET-REG] ホフマン、P.、「Charsetと言語メディアの登録はタグを特集する」RFC2987、2000年11月。
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to
IMAP4 ABNF", RFC 4466, April 2006.
[IMAPABNF] メリニコフとA.とC.Daboo、「IMAP4 ABNFへの集まっている拡大」、RFC4466、2006年4月。
[MEDIAFEAT-REG] Holtman, K., Mutz, A., and T. Hardie, "Media Feature
Tag Registration Procedure", BCP 31, RFC 2506,
March 1999.
[MEDIAFEAT-REG] HoltmanとK.とMutz、A.とT.ハーディー、「メディアはタグ登録手順を特徴とする」BCP31、RFC2506、1999年3月。
[MIME-MTSRP] Freed, N. and J. Klensin, "Media Type Specifications
and Registration Procedures", BCP 13, RFC 4288,
December 2005.
解放された[MIME-MTSRP]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions
for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and
Encoded Word Extensions:
Character Sets, Languages, and Continuations",
RFC 2231, November 1997.
解放された[RFC2231]、N.、およびK.ムーア、「パラメタ値とコード化されたWord拡大をまねてください」 「文字コード、言語、および続刊」、RFC2231、11月1997日
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」
[RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension",
RFC 3516, April 2003.
[RFC3516] ネーレンバーグ、L.、「IMAP4の2進の満足している拡張子」、RFC3516、2003年4月。
Melnikov & Coates Standards Track [Page 28] RFC 5259 IMAP CONVERT extension July 2008
メリニコフとコーツStandards Track[28ページ]RFC5259IMAP CONVERT拡張子2008年7月
15.2. Informative References
15.2. 有益な参照
[DISP-FEATURES] Masinter, L., Wing, D., Mutz, A., and K. Holtman,
"Media Features for Display, Print, and Fax",
RFC 2534, March 1999.
[DISP-特徴] Masinter(L.)は飛んで行きます、Mutz、A.とK.Holtman、「ディスプレイ、印刷、およびファックスのためのメディア機能」RFC2534、D.、1999年3月。
[IMAP-I18N] Newman, C., Gulbrandsen, A., and A. Melnikov,
"Internet Message Access Protocol
Internationalization", RFC 5255, June 2008.
[IMAP-I18N] ニューマンとC.とGulbrandsen、A.とA.メリニコフ、「インターネットメッセージアクセス・プロトコル国際化」、RFC5255、2008年6月。
[LEM-STREAMING] Cook, N., "Streaming Internet Messaging
Attachments", Work in Progress, June 2008.
[レムのストリーミングの] 「インターネットメッセージング付属を流し」て、クック、N.は進歩、2008年6月に働いています。
[OMA-ME-RD] OMA, "Open Mobile Alliance Mobile Email Requirement
Document", OMA 55.919 3.0.0, December 2007.
[OMA ME、第]、OMA、「開いているモバイル同盟モバイルメール要件ドキュメント」、OMA、55.919、3.0、.0、12月2007日
[OMA-STI] OMA, "Open Mobile Alliance, Standard Transcoding
Interface Specification", OMA OMA-STI-V1_0,
December 2005.
[OMA-STI]OMA、「開いているモバイル同盟、標準のコード変換インターフェース仕様」、OMA OMA-STI-V1_0、12月2005日
Authors' Addresses
作者のアドレス
Alexey Melnikov (editor) Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Alexeyメリニコフ(エディタ)Isode Ltd5城のビジネス村の36駅のRoadハンプトン、ミドルセックスTW12 2BXイギリス
EMail: Alexey.Melnikov@isode.com
メール: Alexey.Melnikov@isode.com
Peter Coates (editor) Sun Microsystems 185 Falcon Drive Whitehorse, YT Y1A 6T2 Canada
ピーターコーツ(エディタ)サン・マイクロシステムズ185ハヤブサドライブホワイトホース、YT Y1A 6T2カナダ
EMail: peter.coates@Sun.COM
メール: peter.coates@Sun.COM
Melnikov & Coates Standards Track [Page 29] RFC 5259 IMAP CONVERT extension July 2008
メリニコフとコーツStandards Track[29ページ]RFC5259IMAP CONVERT拡張子2008年7月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Melnikov & Coates Standards Track [Page 30]
メリニコフとコーツ標準化過程[30ページ]
一覧
スポンサーリンク
