Internet Draft: CONVERT A. Melnikov (Ed.) Document: draft-ietf-lemonade-convert-06 Isode Limited Intended status: Standard Track R. Cromwell (Ed.) S. H. Maes (Ed.) Oracle Expires: October 2007 April 2007 IMAP CONVERT extension Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). 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 its settings. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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]. When describing the general syntax, some definitions are omitted as they are defined in [RFC3501]. Table of Contents Status of this Memo ....................................... 1 Copyright Notice........................................... 1 Abstract................................................... 1 Conventions used in this document.......................... 1 Table of Contents.......................................... 2 1. Introduction............................................ 3 2. Relation with other E-mail specifications............... 3 3. Scope of Conversions.................................... 4 4. Discovery with the CAPABILITY and GETMETADATA Commands.. 4 4.1. CAPABILITY......................................... 4 4.2. GETMETADATA ....................................... 4 5. CONVERT extension to BODY and BINARY FETCH data items... 5 6. CONVERT transcoding parameters.......................... 7 6.1. Mandatory Transcoding support...................... 7 6.1.1. Additional features for mobile usage.......... 8 7. FETCH response extensions............................... 8 8. Status responses, Response code extensions.............. 8 9. Formal Syntax........................................... 9 10. IANA Considerations.................................... 11 11. IANA Entry and Attribute registrations ................ 11 11.1. IANA Entry "/convert"............................. 11 11.2. IANA Attribute "types"............................ 12 11.3. IANA Attribute "params"........................... 12 Security Considerations.................................... 12 Normative References....................................... 13 Informative References..................................... 14 Version History............................................ 14 Acknowledgments............................................ 15 Authors' Addresses........................................ 15 Intellectual Property Statement........................... 16 Disclaimer of Validity.................................... 16 Copyright Statement .......................................16 1. Introduction This document defines the CONVERT extension to IMAP4 [RFC3501]. It defines additional enhancements for optimization in a mobile setting: extensions to the IMAP4Rev1 protocol [RFC3501] that allows 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 decided by the server based on its knowledge of the client capabilities, user or administrator preferences or its settings. <<These are important features required in particular to support mobile email use cases [MEMAIL], [OMA-ME-RD].>> A server that supports CONVERT can convert body parts to other formats to be viewed on a mobile device. The client can explicitly request a particular conversion. <<The server complies on a best effort basis. When not possible, the server determines based on its own strategy (e.g. based on knowledge of the client as discussed hereafter) how to convert. If the server knows the characteristics of the device or can determine them (out of scope of CONVERT), the attachments can also be optimized for the capabilities of the devices (e.g. form factor of pictures).>> 2. Relation with other E-mail specifications The CONVERT extension does not address conversion during streaming of attachments. CONVERT depends on the METADATA extension [METADATA] to support discovery of supported conversion formats. In addition, to use CONVERT, the server MUST support the IMAP Binary specification [RFC3516]. 3. 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. 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. 4. Discovery with the CAPABILITY and GETMETADATA Commands 4.1. CAPABILITY A server that supports the CONVERT extension MUST return "CONVERT", "METADATA", and "BINARY" in the CAPABILITY response. Example: A server that implements CONVERT C: a001 CAPABILITY S: * CAPABILITY IMAP4rev1 CONVERT BINARY METADATA [...] S: a001 OK CAPABILITY completed 4.2. GETMETADATA To determine which conversions are supported, server annotations are used. For each MIME format (<type>/<subtype> [MIME-IMT]) that can be converted, an annotation with the name "/convert/<type>/<subtype>/types" SHOULD exist. Such annotation would contain a "value.shared" attribute, which is a semicolon separated list of output formats. For each source MIME type that the client is interested in, it SHOULD determine which target conversions are supported by reading the "value.shared" attribute. Note that a special annotation named "/convert/<type>/@/types" can be used to reference any subtype of <type> media type. A client that doesn't find an "/convert/<type>/<subtype>/types" annotation SHOULD check the value of the "/convert/<type>/@/types" annotation. Note that names of server annotations are case-sensitive (see [METADATA]). In order to guaranty interoperability, clients and servers MUST use the lowercases version of <type> and <subtype> when constructing an annotation name described above. Example: Discover all image conversions C: a GETMETADATA "/convert/image/@/types" types.shared S: * METADATA "/convert/image/jpeg" (types.shared "image/jpeg;image/png;image/gif;image/wbmp") S: a OK GETMETADATA complete The above example shows that the server supports one kind of input image transcoding, from image/jpeg to four different outputs: JPEG, PNG, GIF, and WBMP. For a given conversion, optional transcoding parameters MAY be present. These are mapped into the "value.shared" attribute in the "/convert/sourcetype/destinationtype/params" annotation. A client wishing to use a conversion parameter SHOULD check if the server will accept it by reading the "value.shared" attribute. Example: Discover optional parameters for image/jpeg -> image/gif. C: a GETMETADATA /convert/image/jpeg/image/gif/params "value.shared" S: * METADATA /convert/image/jpeg/image/gif/params ("value.shared" "width;height;depth;interlaced") S: a OK GETMETADATA complete The above example shows that to convert from image/jpeg to image/gif, the transcoding supports the following types of option parameters: width, height, depth, and interlaced. A client MAY use these values to check whether or not a desired conversion is possible, or it may present the parameters as a GUI preferences pane for the user to customize. A baseline set of register transcoding parameter names should be standardized (see [OMA-STI]) in the future, and it is beyond the scope of this spec to allow the client to discover the underlying legal values that these parameters may take. 5. CONVERT extension to BODY and BINARY FETCH data items The CONVERT extension defines a FETCH extension used to transcode the media type of a MIME part into another media type, and/or the same media type, with different encoding parameters. It adds new options to the section-spec part of the BODY data item, a new FETCH response data item BODYPARTSTRUCTURE, and new response codes. It is also expected to work with IMAP BINARY data item extension, whose grammar is modified as well. The response to a CONVERT request always includes a BODYPARTSTRUCTURE. Each request for BODY or BINARY FETCH data item that contains CONVERT MUST result in a FETCH response containing BODY/BINARY and BODYPARTSTRUCTURE data items containing the same section specifier (including the CONVERT keyword and its parameters). This is needed so that the client can match the requested data items with the received ones. This also allows the client to request multiple conversions of the same body part in a single request. 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 can 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 the server makes such choice. Note that support for such "default conversion" request is OPTIONAL in servers. CONVERT's syntax is modeled after the HEADER.FIELDS syntax in [RFC3501], and is generally structured as: BODY[section-part.CONVERT[.STRICT] ("media type/subtype" (parameters))] BODY.PEEK[section-part.CONVERT[.STRICT] ("media type/subtype" (parameters))]<partial> BINARY[section-part.CONVERT[.STRICT] ("media type/subtype" (parameters))]<partial> BINARY.PEEK[section-part.CONVERT[.STRICT] ("media type/subtype" (parameters))]<partial> BINARY.SIZE[section-part.CONVERT[.STRICT] ("media type/subtype" (parameters))]<partial> 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 FETCH 2 BODY[3.CONVERT ("APPLICATION/PDF")] S: * 2 FETCH (BODYPARTSTRUCTURE[3.CONVERT ("APPLICATION/PDF")] ("APPLICATION" "PDF" () NIL NIL "Base64" 2135 NIL NIL NIL) BODY[3.CONVERT ("APPLICATION/PDF")] {2135} <the document in .pdf format> ) S: a001 OK FETCH COMPLETED <<Example: The client requests for conversion of a text/html section as text/plain and asks for a charset of us-ascii. The server cannot respect the charset request because there are non-us-ascii characters in the html code. Thus, in the untagged response, the server returns the charset of UTF-8 and utilizes a content transfer encoding capable of representing the full 8-bit range, along with the converted text.>> C: b001 FETCH 2 BODY[3.CONVERT ("text/plain" ("charset" "us-ascii"))] S: * 2 FETCH (BODYPARTSTRUCTURE[3.CONVERT ("text/plain" ("charset" "us-ascii"))] ("TEXT" "PLAIN" ("charset" "utf-8") NIL NIL "Base64" 2135 181 NIL NIL NIL) BODY [3.CONVERT ("text/plain" ("charset" "us-ascii"))] {2135} <the document in text/plain format with utf-8 character set> ) S: b001 OK FETCH COMPLETED <<Need to at least register that charset conversion parameter?>> Example: The client requests for conversion of a text/html section as text/plain, but only wants 1000 bytes, starting from byte 2001. C: c001 FETCH 2 BODY[3.CONVERT ("TEXT/PLAIN" ("CHARSET" "us-ascii"))]<2001.1000> S: * 2 FETCH (BODYPARTSTRUCTURE[3.CONVERT ("TEXT/PLAIN" ("CHARSET" "us-ascii"))] ("TEXT" "PLAIN" ("charset" "us-ascii") NIL NIL "7bit" 2135 181 NIL NIL NIL) BODY[3.CONVERT ("TEXT/PLAIN" ("CHARSET" "us-ascii"))]<2001> {135} <bytes 2001 - 2135 of the document in text/plain format> ) S: c001 OK FETCH COMPLETED The server is REQUIRED to respect the target MIME type specified by the client in the transcoding request, whether the STRICT qualifier is specified or not. The server is NOT REQUIRED to respect other transcoding request parameters unless the STRICT qualifier is used, although it MAY try to make a best effort to fulfill that request if the STRICT qualifier is omitted. <<Indeed, the server may know a priori information about the client obtained through a different mechanism outside the scope of CONVERT (e.g. dynamically through device description mechanisms or when the device was associated to the account). These preferences may be used to predefine what conversions are possible. Ideally the client should request the same conversions. In addition, this information may also allow attachment adaptation (e.g. picture form factor) instead of solely format conversion.>> 6. CONVERT transcoding parameters IMAP servers which support CONVERT MAY support additional transcoding parameters for each media type. All such servers MUST minally support recognition of charset for text/* MIME types, although they may decline to honor some requests. For media types other than text, it is beyond the scope of this document to define conversion parameters. In general however, CONVERT compliant servers MAY choose to support additional parameters, and if so, they SHOULD follow the OMA STI 1.0 spec [OMA-STI] adopting the same parameter names as defined in section 5.2.4 and above for the most popular image/*, video/*, and audio/* codecs As an example, in section 5.2.6.2 of [OMA-STI], the parameters "width" and "height" are defined. The following example illustrates how these OMA STI parameters are used with CONVERT. C: d001 UID FETCH 100 BINARY[2.CONVERT ("IMAGE" "JPG" ( "WIDTH" "128" "HEIGHT" "96"))] S: * 2 FETCH (UID 100 BODYPARTSTRUCTURE[2.CONVERT ("IMAGE" "JPG" ("WIDTH" "128" "HEIGHT" "96"))] ("IMAGE" "JPG" () NIL NIL "8bit" 4182 NIL NIL NIL) BINARY[2.CONVERT ("IMAGE" "JPG" ("WIDTH" "128" "HEIGHT" "96"))] ~{4182} <this part of a document is a rescaled image in JPG format with width=128, height=96.> ) S: d001 OK UID FETCH COMPLETED 6.1. Mandatory Transcoding support A server implementing CONVERT MUST support character set conversions for the text/plain MIME type, and MUST support character set 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. The server MUST list "text/plain" as an allowed destination conversion in the "/convert/text/plain/types" annotation. A request for annotation "/convert/text/plain/text/plain/params" MUST return "charset" as a supported transcoding parameter. Servers SHOULD offer additional character encoding conversions where they make sense as character conversion libraries are generally available on many platforms. If for some reason, the server cannot carry out the trancoding while preserving all the characters, the server SHOULD <<MUST?>> add an INFORMATIONLOSS response code to the response, unless STRICT is specified. If STRICT is specified, the server MUST return the BADPARAMETERS response code. 6.1.1. Additional features for mobile usage Based on the expected usage of convert in mobile environments: - Servers SHOULD support conversion of HTML and XHTML documents to text/plain in ways that preserve at the minimum the document structure and tables. - Server SHOULD support image conversions among the types image/gif, image/jpeg and image/png for at least the following parameters: o Size limit (i.e. reduce quality), o width, o height, o resize directive (crop, stretch, aspect ratio) The support for "depth" may also be of interest. Audio conversion is of significant interest but the relevant formats depend significantly on the usage context. Support of other formats like proprietary document formats and video can also be described as MIME types with STI parameters. Their support depends on the usage context. 7. FETCH response extensions The BODYPARTSTRUCTURE data item is introduced when using the CONVERT extension. Its data follows the exact syntax specified in the [RFC3501] BODYSTRUCTURE data item, but contains information for only 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. The client must respect the return values and not assume the conversion request succeeds exactly as requested unless the STRICT qualifier is used. <<What happens if the client didn't specify STRICT and the server returns image/jpeg instead of image/png? What should be specified in the BODYPARTSTRUCTURE response item tag?>> 8. Status responses, Response code extensions Some transcodings may require parameters. If a transcoding request is sent for a format which requires parameters, the server can reply with a NO response. Likewise, malformed MIME types may also generate NO responses. If the server is unable to perform the requested conversion because a resource is unavailable (e.g. internal error, transcoding service down) then a NO response should be returned. If a request is denied because of an operational error, such as lack of disk space, or because the requested conversion for some reason cannot be performed, and there is no fallback for this particular device (such as the case where a proprietary document format has no existing transcoding implementation, and the server recognizes that the client has no default viewer for it), the server MUST return a NO response. Otherwise, the server should return an OK response. The client in general can tell from the BODYPARTSTRUCTURE response whether or not its request was honored exactly, but may not know the reasons why. The following extension response codes are provided for OK and NO responses to disambiguate those situations, or warn about possible important data loss: INFORMATIONLOSS the conversion was satisfied for conversion request, but it may have resulted in the loss of important data (primarily of use for loss of text data, since rich media is often compressed with loss) BADPARAMETERS "(" convert-params ")" the listed parameters were not understood, or could not be honored for the reasons noted in section-text. In particular, a CONVERT.STRICT request may be failed because the server has no way to honor it. SERVEROVERRIDE the server overrode the request parameters because it determined it could substitute better ones based on preferences, device capability knowledge, or server policy. If CONVERT.STRICT is used, the server MUST NOT return SERVEROVERRIDE, it MUST either honor the request, or fail. <<Do we need this response code? How can the client discover what the overriden parameters are? (Note that all responses must include the requested parameters, so that the client can do proper matching of responses with requests. This is still true for the SERVEROVERRIDE case.) Does it need to know?>> 9. Formal Syntax 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. This syntax augments the grammar specified in [RFC3501] and [RFC3516]. Non-terminals not defined in this document can be found in [RFC3501], [RFC3516] and [MIME-MTSRP]. In the ABNF section-msgtext grammar in section 9 of [RFC3501], Section-msgtext is hereby amended to read: section-convert = "CONVERT" [".STRICT"] SP convert-params section-msgtext =/ section-convert convert-params = "(" (quoted-to-mime-type / default-conversion) [SP "(" transcoding-params ")"] ")" quoted-to-mime-type = DQUOTE to-mime-type DQUOTE transcoding-params = transcoding-param-name SP transcoding-param-value *(SP transcoding-param-name SP transcoding-param-value) transcoding-param-name = astring transcoding-param-value = astring default-conversion = "NIL" In the ABNF syntax "section-binary" of [RFC3516], is amended to: section-binary = "[" [section-binary-spec] "]" section-binary-spec = section-part ["." section-convert] / section-convert ; Note that conversion of a top level ; multipart/* is allowed. In the ABNF syntax "msg-att-static" of [RFC3501], is amended to: msg-att-static =/ "BODYPARTSTRUCTURE" section SP "(" body-type-1part ")" <<Should we just use "body" instead of '"(" body-type-1part ")"'? This would allow for conversion to non-leaf body parts, but this might be a feature, not a bug>> In the ABNF syntax "resp-text-code" of [RFC3501], is amended to: Resp-text-code =/ "INFORMATIONLOSS" / "SERVEROVERRIDE" / "BADPARAMETERS" SP "(" bad-param-list ")" bad-param-list = transcoding-params In addition, the following ABNF describes the syntax of the GETMETADATA entries in Section 4.2 convert-entry-req = available-conversions / available-transcoding-parameters available-conversions = "/convert/" from-mime-type "/types" any-mime-type = "@" from-mime-type = (type-name "/" any-mime-type) / concrete-mime-type ; "type/@" or "type/subtype" ; type-name is defined in [MIME-MTSRP]. concrete-mime-type = type-name "/" subtype-name ; i.e. "type/subtype". ; type-name and subtype-name ; are defined in [MIME-MTSRP]. <<Are '.' allowed in annotation names? Yes, as long as the name doesn't contain "priv" or "shared" component, e.g. foo.priv.bar is disallowed.>> from-concrete-mime-type = concrete-mime-type to-mime-type = concrete-mime-type available-transcoding-parameters = "/convert/" from-concrete-mime-type "/" to-mime-type "/params" ; Name of an annotation containing transcoding parameters. ; i.e. /convert/frmtype/frmsubtype/totype/tosubtype/params. The "value.shared" syntax of any "/convert/<type>/<subtype>/types" annotation has the following syntax: types-shared-value = from-concrete-mime-type *(";" from-concrete-mime-type) The "value.shared" syntax of any "/convert/<fromtype>/<fromsubtype>/ <totype>/<tosubtype>/params" annotation has the following syntax: params-shared-value = transcoding-param-name *(";" transcoding-param-name) 10. IANA Considerations IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at <http://www.iana.org/assignments/imap4-capabilities>. This document defines the CONVERT IMAP capability. This extension shall be submitted to the IANA IMAP Capability registry. 10.1. IANA Entry and Attribute registrations The following sections specify IANA registrations for entries and attributes used in this document. 10.1.1. IANA Entry "/convert" To: iana@iana.org Subject: IMAP METADATA Registration Please register the following IMAP METADATA item: [x] Entry [ ] Attribute [ ] Mailbox [x] Server Name: /convert Description: All annotations below this one are reserved for use by [this RFC] and its extensions. Content-type: text/plain; charset=utf-8 Contact person: Alexey Melnikov email: alexey.melnikov@isode.com <<Is this one needed?>> 10.1.2. IANA Entry "/convert/<type>/<subtype>/types" To: iana@iana.org Subject: IMAP METADATA Registration Please register the following IMAP METADATA item: [x] Entry [ ] Attribute [ ] Mailbox [x] Server Name: /convert/<type>/<subtype>/types Description: Defined in [this RFC], Section 4.2. Content-type: text/plain; charset=us-ascii Contact person: Alexey Melnikov email: alexey.melnikov@isode.com 10.1.3. IANA Entry "/convert/.../params" To: iana@iana.org Subject: IMAP METADATA Registration Please register the following IMAP METADATA item: [x] Entry [ ] Attribute [ ] Mailbox [x] Server Name: /convert/<fromtype>/<fromsubtype>/<totype>/ <tosubtype>/params Description: Defined in [this RFC], Section 4.2. Content-type: text/plain; charset=utf-8 Contact person: Alexey Melnikov email: alexey.melnikov@isode.com 11. Security Considerations 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 server such as requesting an image be scaled to extremely large dimensions). Clients should be careful when requesting conversions or processing transformed attachments. Servers should avoid dangerous conversions if possible. Whenever possible, servers should perform verification of the converted attachments before returning them to the client. A client can create a carefully crafted bad message with the APPEND command followed by the FETCH command to attack the server. If the server's conversion function or library has a security problem, this could result in provilege escalation or Denial of Service. On bandwidth limited mobile networks where users pay per data volumes, spam may become an important issue. It can be mitigated with appropriate filters and server-side spam prevention tools. These are of course outside the scope of CONVERT. <<Deployments that utilize object level encryption may present security challenges to be carefully considered, such as if a conversion is requested for S/MIME [SMIME] encrypted data. This is currently considered as taking place outside the scope of CONVERT.>> 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) 12. References 12.1. Normative References [METADATA] Daboo, C., "IMAP METADATA Extension", work in progress, draft-daboo-imap-annotatemore-11, 2007. [ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. http://www.ietf.org/rfc/rfc4234 [RFC2119] Brader, S. "Keywords for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol Version 4 rev1", RFC 3501, March 2003. http://www.ietf.org/rfc/rfc3501 [RFC3516] Nerenberg, L. "IMAP4 Binary Content Extension", RFC 3516, April 2003. http://www.ietf.org/rfc/rfc3516.txt [MIME-IMT] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part Two: Media Types", RFC 2046, November 1996. [MIME-MTSRP] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", RFC 4288, December 2005. 12.2. Informative References [MEMAIL] Maes, S.H., "Lemonade and Mobile e-mail", draft-maes- lemonade-mobile-email-xx.txt, (work in progress). [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document, work in progress, http://www.openmobilealliance.org/ [OMA-STI] Open Mobile Alliance, Standard Transcoding Interface Specification, version 1.0, work in progress, <http://member.openmobilealliance.org/ftp/Public_documents/BAC/STI /Permanent_documents/OMA-STI-V1_0-20050209-D.zip>. [SMIME] <<>> 13. Acknowledgments The authors want to specifically acknowledge the excellent criticism and comments received from Randall Gellens (Qualcomm), Arnt Gulbrandsen (Oryx) and Zoltan Ordogh (Nokia) which improved the quality of the CONVERT specification considerably. 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 draft: 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)), Zhao Lijun (CHINA MOBILE COMMUNICATIONS CORPORATION (CMCC)). 14. Authors' Addresses Stephane H. Maes (Editor) Oracle Corporation 500 Oracle Parkway M/S 4op634 Redwood Shores, CA 94065 USA Phone: +1-650-607-6296 Email: stephane.maes@oracle.com Ray Cromwell (Editor) Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Alexey Melnikov (Editor) Isode Limited 5 Castle Business Village, 36 Station Road, Hampton, Middlesex, TW12 2BX, UK Email: Alexey.Melnikov@isode.com Version History Note to RFC-editor: Please delete this section before publication Open Issues - Should conversion *to* non-leaf body parts be allowed? Release 06 - Allow conversion of non-leaf body parts. - Clarified that the target MIME type must be obeyed. - Changed from using new annotation attributes to standard ones - Major corrections to the ABNF section. - Disallow /convert/* annotation entry. - The * character is not allowed in annotation names, so the @ character is used instead. - Clarified handling of default conversion. - Updated examples to match ABNF. - Updated or added missing references. Release 05 - Client not mandated to support BINARY - Misc syntax and spelling fixes - New abstract contributed by Randall Gellens Release 04 - Remove compression and encryption - Update to use latest METADATA draft - Add IANA registrations Release 03 - Add mandatory character set conversions. - Add object level compression - Add object level encryption Release 02 Fixed a normative example to be informative. Added formal syntax for BODYPARTSTUCTURE, response text codes, and formal structure of composite GETANNOTATE values. Release 01 Corrected some grammatical mistakes. Clarified meaning of GETTANNOTATION response properties. Changed CONVERT grammar to merge media type and subtype into a single parameter instead of two parameters. Clarified that BODYSTRUCTURERESPONSE is always returned for CONVERT requests. Moved transcoding parameter discussion to main body from appendix. Release 00 Initial release published in October 2005 based on draft-maes- lemonade-lconvert-00 and the comments received at the London face to face meeting end of September 2005. 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. 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. 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. Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.
Datatracker
Report a datatracker bug
draft-ietf-lemonade-convert-06
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 5259.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |