Lemonade
Internet Draft: LCONVERT S. H. Maes
Document: draft-maes-lemonade-lconvert-00 C. Kuang
R. Lima
R. Cromwell
V. Ha
E. Chiu
J. Day
R. Ahad
Oracle Corporation
Wook-Hyun Jeong
Samsung
Electronics Co.,
LTD
Gustaf Rosell
Sony Ericsson
J. Sini
Symbol
Technologies
Sung-Mu Son
LGE
Fan Xiaohui
Zhao Lijun
China Mobile
Expires: January 2006 July 2005
LCONVERT
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. 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."
Maes [Page 1]
<LCONVERT> July 2005
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
LCONVERT defines extensions to the IMAPv4 Rev1 protocol [RFC3501] for
optimization in a mobile setting, aimed at allowing adaptation and
transcoding of attachments 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.
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].
An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocol(s) it
implements. An implementation that satisfies all the MUST or REQUIRED
level and all the SHOULD level requirements for a protocol is said to
be "unconditionally compliant" to that protocol; one that satisfies
all the MUST level requirements but not all the SHOULD level
requirements is said to be "conditionally compliant." When
describing the general syntax, some definitions are omitted as they
are defined in [RFC3501].
Table of Contents
Status of this Memo ........................................... 1
Abstract....................................................... 2
Conventions used in this document.............................. 2
Table of Contents.............................................. 2
1. Introduction................................................ 3
2. Relation with other E-mail specifications................... 3
3. Interactions between the Client and Server when supporting
LCONVERT....................................................... 4
4. The CAPABILITY Command...................................... 4
5. LCONVERT & UID LCONVERT..................................... 4
Maes Expires û January 2006 [Page 2]
<LCONVERT> July 2005
Security Considerations........................................ 7
References..................................................... 7
Normative Appendices........................................... 8
A. Security Issues for Proxy-Based Implementations.......... 8
B. LCONVERT transcoding parameters.......................... 9
Future Work.................................................... 9
Version History................................................ 9
Acknowledgments................................................10
Authors Addresses..............................................10
Intellectual Property Statement................................12
Full Copyright Statement.......................................12
1. Introduction
LCONVERT is based on IMAPv4 Rev1 [RFC3501]. It defines additional
enhancements for optimization in a mobile setting: extensions to the
IMAPv4 Rev1 protocol [RFC3501] that allows adaptation and transcoding
of attachments 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 LCONVERT can convert attachments 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 LCONVERT), the
attachments can also be optimized for the capabilities of the devices
(e.g. form factor of pictures). See discussion in Appendix B. This is
a recommended server behavior.
2. Relation with other E-mail specifications
The Lemonade Profile [LEMONADEPROFILE] specifies the Lemonade Pull
Model that governs the exchanges among mail servers or between
desktop mail client and mail servers. Lemonade investigates adding
mobile optimizations for the next version of the profile.
LCONVERT should be seen as a way to address the issues of mobile
optimization and an input to the Lemonade Profile work. It addresses
the topic of attachment conversions identified by the Lemonade work
as critical for mobile email.
Maes Expires û January 2006 [Page 3]
<LCONVERT> July 2005
LCONVERT does not address conversion and streaming of media as also
identified of interest by lemonade. This has not been identified as
relevant to mobile e-mail [MEMAIL] and [OMA-ME-RD].
Clients and servers MAY support other Lemonade extensions and
behaviors.
This document assumes that clients MUST be compliant to LCONVERT when
it decides to use this command. The server that claims support of
LCONVERT MUST be compliant to LCONVERT for its exchanges with the
mobile client.
3. Interactions between the Client and Server when supporting LCONVERT
A compliant server must support all IMAPv4Rev1 commands from client
devices following the syntax defined in [RFC3501]. Thus, a client
may issue any existing IMAP commands to the server, and both the
server and client must behave as specified in [RFC3501].
4. The CAPABILITY Command
The CAPABILITY command is defined in RFC3501, section 6.1.1. The
client sends a CAPABILITY command so it can query the server to find
out what commands it supports. In RFC3501, the IMAP server is
allowed to specify additional capabilities not included in that
specification. A server that supports LCONVERT and its requirements
MUST list that it supports LCONVERT.
A server can also enumerate individually the other commands that it
supports.
capability_cmd = tag SP "CAPABILITY"
Valid States: NOT AUTHENTICATED, AUTHENTICATED, SELECTED, or LOGOUT
Responses: REQUIRED untagged response: CAPABILITY
Result: OK - capability completed
BAD - command unknown or arguments invalid
Example: A server that implements LDELIVER.
C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=LOGIN IDLE LCONVERT
S: a001 OK CAPABILITY completed
5. LCONVERT & UID LCONVERT
LCONVERT and UID LCONVERT are used for attachments conversion. The
client sends one message sequence number or UID, the body part to
retrieve, and gives the mime-type and subtype to convert the
attachment to. When specifying the body part, the client can specify
Maes Expires û January 2006 [Page 4]
<LCONVERT> July 2005
to peek only at the message and/or to return only certain bytes of
the converted part. Optionally, after the mime-type and subtype, the
client can specify additional parameters specific to the target
content type, such as CHARSET if the target content-type is
TEXT/plain and optionally content-transfer-encoding. See Appendix B
for a description of LCONVERT parameters.
The server is not required to respect those parameters. Indeed, the
server may know a priori information about the client obtained
through a different mechanism outside the scope of LCONVERT (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.
As a response to an LCONVERT command, the server gives an untagged
LCONVERT response which has syntax similar to an untagged FETCH
response. The LCONVERT response includes a BODY[] data item, a
BODYPARTSTRUCTURE data item, and a UID data item if the command is
UID LCONVERT. The BODYPARTSTRUCTURE data item is introduced by the
LCONVERT command. It follows the exact syntax specified in
BODYSTRUCTURE, 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 any values in
this BODYPARTSTRUCTURE, meaning if it specifies a different content-
transfer-encoding value, the client must decode the response based on
that encoding. It must also respect the required parameter values
pertaining to the specific target content-type (for example, CHARSET
if target content-type is TEXT/plain).
lconvert_cmd = tag SP "LCONVERT" message-sequence-number SP
"BODY" [".PEEK"] "[" part-id "]" ["<" byte-start
"." max-bytes ">"]SP "as" SP mime-type "/"
subtype [parameter-list]
parameter-list= ";" parameter "=" parameter-value [parameter-list]
Valid States: SELECTED
Responses: untagged responses: LCONVERT
Untagged LCONVERT response = "*" SP message-sequence-number SP
"LCONVERT" SP "(" "BODYPARTSTRUCTURE[" partnum "]" SP
bodystructureOfPart SP "BODY[" partnum "]" ["<" origin_octet ">"]
SP "{" num-bytes "}" CRLF bytes CRLF ")"
Result: OK - lconvert completed
NO - lconvert error: can't perform the command
BAD - command unknown or arguments invalid
Maes Expires û January 2006 [Page 5]
<LCONVERT> July 2005
Note: as DEFAULT/DEFAULT MAY be used to request conversion as
decided as default by the server (in general for the media type or
based on knowledge of the target device, possibly based on the user
preferences logged with the server)
Example: The client fetches an attachment in the message with the
message sequence number of 2 in the Inbox and asks to have that
attachment converted to pdf format. The client does not request a
content-transfer-encoding, and in this case, the server uses the same
content-transfer-encoding to encode the converted response.
C: a001 LCONVERT 2 BODY[3] as application/pdf
S: * 2 LCONVERT (BODYPARTSTRUCTURE[3] ("APPLICATION" "PDF" () NIL
NIL "Base64" 2135 NIL NIL NIL) BODY[3] {2135}
<the document in .pdf format>
)
S: a001 OK LCONVERT COMPLETED
Example: The client requests for conversion of a text/html section
as text/plain and asks for a charset of us-ascii and a 7bit encoding.
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 a 8bit
encoding, along with the converted text.
C: a001 LCONVERT 2 BODY[3] as text/plain;charset="us-ascii";
content-transfer-encoding="7bit"
S: * 2 LCONVERT (BODYPARTSTRUCTURE[3] ("TEXT" "PLAIN" () NIL
NIL "Base64" 2135 181 NIL NIL NIL) BODY[3] {2135}
the document in text/plain format
)
S: a001 OK LCONVERT COMPLETED
Example: The client requests for conversion of a text/html section
as text/plain, but only wants 1000 bytes, starting from byte 2001.
C: a001 LCONVERT 2 BODY[3]<2001.1000> as text/plain;charset="us-
ascii";content-transfer-encoding="7bit"
S: * 2 LCONVERT (BODYPARTSTRUCTURE[3] ("TEXT" "PLAIN" () NIL
NIL "Base64" 2135 181 NIL NIL NIL) BODY[3]<2001> {135}
bytes 2001 - 2135 of the document in text/plain format
)
S: a001 OK LCONVERT COMPLETED
luidconvert_cmd = tag SP "UID" SP "LCONVERT" uid SP
lconvert-listitem-list SP "as"
SP mime-type "/" subtype [parameter-list]
Valid States: SELECTED
Responses: untagged responses: UID LCONVERT
Maes Expires û January 2006 [Page 6]
<LCONVERT> July 2005
Untagged UID LCONVERT response = "*" SP message-sequence-number SP
"LCONVERT" SP "(" "UID" SP uid SP "BODYPARTSTRUCTURE[" partnum
"]" SP bodystructureOfPart SP "BODY[" partnum "]" SP "{" num-
bytes "}" CRLF bytes CRLF ")"
Result: OK - luidconvert completed
NO - luidconvert error: can't perform the command
BAD - command unknown or arguments invalid
Example: The client fetches an attachment in the message with UID
120 (and message sequence number 2) in the Inbox and asks to have
that attachment converted to pdf format.
C: a001 UID LCONVERT 120 BODY[3] as application/pdf
S: * 2 LCONVERT (UID 120 BODYPARTSTRUCTURE[3] ("APPLICATION" "PDF"
() NIL NIL "Base64" 2135 NIL NIL NIL) BODY[3] {2134}
<this part of a document in pdf format.>
)
S: a001 OK UID LCONVERT COMPLETED
Security Considerations
When an implementation is proxy-based, this may create new security
issues. These issues are discussed in detail in Appendix C, because
the issues are dependent on the implementation of this protocol
rather than inherent to the protocol itself.
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 LCONVERT.
It is also recommended that clients be explicitly registered with the
server through separate channels / application. Exchanges should then
be paired.
References
[LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile",
draft-ietf-lemonade-profile-XX.txt, (work in progress).
[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]
Maes Expires û January 2006 [Page 7]
<LCONVERT> July 2005
(http://member.openmobilealliance.org/ftp/Public_documents/BAC/STI
/Permanent_documents/OMA-STI-V1_0-20050209-D.zip).
[P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and
Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn
S-M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP
Protocol (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in
progress).
[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
Normative Appendices
A. Security Issues for Proxy-Based Implementations
In some implementations, the client may connect to a proxy that sits
in an operator network, but the backend email storage server sits in
a separate enterprise network. The enterprise network is assumed to
be secure, but the operator network may not be trusted. If
unencrypted information lies in the operator network, that
information is vulnerable to attacks.
If the LCONVERT extensions are all implemented in the enterprise
network, then the proxy on the carrier should be an encrypted SSL
pass-through proxy. The proxy is unaware of the encryption keys and
thus cannot encrypt any data. Without the encryption key, this proxy
cannot see any of the information sent from the client, nor can it
send any bogus commands to the backend enterprise email server to
corrupt the user's mailbox. The additional cost for this design is
that the backend enterprise email server and the client devices must
have additional processing to handle this encryption.
If the LCONVERT compliant server is implemented as a backend IMAP
server with additional command processing done on the proxy, there
are more complex security issues. This proxy must be able to send
commands to the backend server to accomplish its tasks, as well as
read information coming from the backend server. An attacker thus
can send commands to the backend to change the state of the mail
storage, possibly corrupting it. In addition, it can read responses
from the mail server that might contain confidential email
information. This proxy may also send bogus responses back to the
client. Clearly, this setup is not an ideal issue and many
Maes Expires û January 2006 [Page 8]
<LCONVERT> July 2005
complications that make this problem complex to solve. The
suggestion recommended is to remedy the problem of unencrypted,
untagged FETCH responses that may contain confidential information.
Encrypted responses should be used in place of any untagged FETCH
responses, which contain encrypted message information to be passed
through the proxy on the operator network. The key exchange for
encryption should not occur through the proxy. It has to be done
through another channel: manually entered by user (e.g. password), or
via an HTTP SSL request to the enterprise server. Any other
additional server responses containing sensitive information
(passwords, etc.) should be encrypted.
B. LCONVERT transcoding parameters
LCONVERT servers MAY support additional transcoding parameters for
each media type. All LCONVERT compliant servers MUST minally support
recognition of charset and encoding parameters 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, LCONVERT 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 second 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 MUST be used with XCONVERT.
C: a001 UID LCONVERT 100 BODY[2] as
image/jpg;width=128;height=96
S: * 2 LCONVERT (UID 100 BODYPARTSTRUCTURE[2] ("IMAGE" "JPG"
() NIL NIL "Base64" 4182 NIL NIL NIL) BODY[2] {4182}
<this part of a document is a rescaled image in JPG format
with width=128, height=96.>
)
S: a001 OK UID LCONVERT COMPLETED
Future Work
TBD
Version History
Release 00
Initial release published in June 2005
Maes Expires û January 2006 [Page 9]
<LCONVERT> July 2005
Acknowledgments
The authors want to thank all who have contributed key insight and
extensively reviewed and discussed the concepts of LDELIVER and its
early introduction as XDELIVER in P-IMAP [P-IMAP].
Authors Addresses
Stephane H. Maes
Oracle Corporation
500 Oracle Parkway
M/S 4op634
Redwood Shores, CA 94065
USA
Phone: +1-650-607-6296
Email: stephane.maes@oracle.com
Rafiul Ahad
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Eugene Chiu
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Ray Cromwell
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Jia-der Day
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Vida Ha
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Wook-Hyun Jeong
Samsung Electronics,CO., LTD
Maes Expires û January 2006 [Page 10]
<LCONVERT> July 2005
416, Maetan-3dong, Yeongtong-gu,
Suwon-city, Gyeonggi-do,
Korea 442-600
Tel: +82-31-279-8289
E-mail: wh75.jeong@samsung.com
Chang Kuang
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Rodrigo Lima
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Gustaf Rosell
Sony Ericsson
P.O. Box 64
SE-164 94 Kista,
Sweden
Tel: +46 8 508 780 00
Jean Sini
Symbol Technologies
6480 Via Del Oro
San Jose, CA 95119
USA
Sung-Mu Son
LG Electronics
Mobile Communication Technology Research Lab.
Tel: +82-31-450-1910
E-Mail: sungmus@lge.com
Fan Xiaohui
Product Development Division
R&D CENTER
CHINA MOBILE COMMUNICATIONS CORPORATION (CMCC)
ADD: 53A, Xibianmennei Ave.,Xuanwu District,
Beijing,100053
China
TEL:+86 10 66006688 EXT 3137
Zhao Lijun
CMCC R&D
ADD: 53A, Xibianmennei Ave.,Xuanwu District,
Maes Expires û January 2006 [Page 11]
<LCONVERT> July 2005
Beijing,100053
China
TEL:.8610.66006688.3041
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Full Copyright Statement
Copyright (C) The Internet Society (2005). 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 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.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
Maes Expires û January 2006 [Page 12]
<LCONVERT> July 2005
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Maes Expires û January 2006 [Page 13]