Internet DRAFT - draft-maes-lemonade-lconvert
draft-maes-lemonade-lconvert
Lemonade
Internet Draft: LCONVERT S. H. Maes
Document: draft-maes-lemonade-lconvert-01 R. Cromwell
(Editors)
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."
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.
Maes [Page 1]
<LCONVERT> July 2005
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..........................................................1
Conventions used in this document.................................1
Table of Contents.................................................2
1. Introduction...................................................2
2. Relation with other E-mail specifications......................3
3. Interactions between the Client and Server when supporting
LCONVERT..........................................................3
4. The CAPABILITY Command.........................................4
5. LCONVERT BODY and BINARY data item extension...................4
6. FETCH response extensions......................................6
7. Status responses, Response code extensions.....................6
8. Formal Syntax..................................................7
Security Considerations...........................................7
References........................................................8
Normative Appendices..............................................9
A. Security Issues for Proxy-Based Implementations.............9
B. LCONVERT transcoding parameters............................10
Future Work......................................................10
Version History..................................................10
Acknowledgments..................................................10
Authors Addresses................................................11
Intellectual Property Statement..................................13
Full Copyright Statement.........................................13
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
Maes Expires û January 2006 [Page 2]
<LCONVERT> July 2005
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 LCONVERT can convert leaf 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 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.
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 extension. 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
Maes Expires û January 2006 [Page 3]
<LCONVERT> July 2005
server and client must behave as specified in [RFC3501]. In
addition, the client and server SHOULD support the IMAP Binary
specification [RFC3516].
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 BINARY
S: a001 OK CAPABILITY completed
5. LCONVERT BODY and BINARY data item extension
LCONVERT is a FETCH extension used to transcode the media type of a
leaf 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.
LCONVERTÆs syntax is modeled after the HEADER.FIELDS syntax in
RFC3501, and is generally structured as:
BODY[section-part.LCONVERT (ômedia typeö ôsubtypeö (parameters))]
BODY.PEEK[section-part.LCONVERT (ômedia typeö ôsubtypeö
(parameters))]<partial>
BINARY[section-part.LCONVERT (ômedia typeö ôsubtypeö
(parameters))]<partial>
Maes Expires û January 2006 [Page 4]
<LCONVERT> July 2005
BINARY.PEEK[section-part.LCONVERT (ômedia typeö ôsubtypeö
(parameters))]<partial>
BINARY.SIZE[section-part.LCONVERT (ô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.LCONVERT (ôAPPLICATIONö ôPDFö)]
S: * 2 FETCH (BODYPARTSTRUCTURE[3] ("APPLICATION" "PDF" () NIL
NIL "Base64" 2135 NIL NIL NIL) BODY[3] {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: a001 FETCH 2 BODY[3.LCONVERT (ôtextö ôplainö (ôcharsetö ôus-
asciiö))]
S: * 2 FETCH (BODYPARTSTRUCTURE[3] ("TEXT" "PLAIN" () NIL
NIL "Base64" 2135 181 NIL NIL NIL) BODY[3] {2135}
the document in text/plain format
)
S: a001 OK FETCH 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 FETCH 2 BODY[3.LCONVERT (ôTEXTö ôPLAINö (ôCHARSETö ôus-
asciiö))]<2001.1000>
S: * 2 FETCH (BODYPARTSTRUCTURE[3] ("TEXT" "PLAIN" () NIL
NIL "7bit" 2135 181 NIL NIL NIL) BODY[3]<2001> {135}
bytes 2001 - 2135 of the document in text/plain format
)
S: a001 OK FETCH COMPLETED
The server is not required to respect a particular transcoding
request or its request parameters, although it MAY try to make a best
effort to fulfill that request. 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
Maes Expires û January 2006 [Page 5]
<LCONVERT> July 2005
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. FETCH response extensions
The BODYPARTSTRUCTURE data item is introduced when using the LCONVERT
extension. It 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.
7. 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 BAD response. Likewise, malformed mime types may also generate
BAD responses.
If the server is unable to perform the requested conversion because a
resource is unavailable (internal error, transcoding service down)
than a BAD 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 SHOULD 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 exactly why it
different.
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 richmedia is often
compressed with loss)
Maes Expires û January 2006 [Page 6]
<LCONVERT> July 2005
BADPARAMETERS ô(ô lconvert-params ô)ö û the listed parameters were
not understood, or could not be honored for the reasons noted in
section-text
SERVEROVERRIDE û the server overrode the request because it
determined it could substitute a better one based on preferences,
device capability knowledge, or server policy.
8. 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].
In the ABNF section-msgtext grammar in section 9 of [RFC3501].
Section-msgtext is hereby amended to read:
section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list
/ "TEXT" / ôXCONVERTö SP xconvert-params
lconvert-params = "(" (media-basic / default-conversion) [SP "("
transcoding-params ")"] ")"
transcoding-params = transcoding-param-name SP transcoding-param-
value
*(SP transcoding-param-name SP transcoding-param-value)
transcoding-param-name = string
transcoding-param-value = string
default-conversion = "NIL" "NIL"
In the ABNF syntax ôsection-binaryö of [RFC3516], is amended to:
section-binary = "[" [section-part [ô.XCONVERTö SP xconvert-
params] "]"
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.
Maes Expires û January 2006 [Page 7]
<LCONVERT> July 2005
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
[ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications:
ABNFö, RFC 2234, November 1997.
http://www.ietf.org/rfc/rfc2234
[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]
(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
[RFC3516] Nerenberg, L. ôIMAP4 Binary Content Extensionö, RFC3516,
April 2003.
http://www.ietf.org/rfc/rfc3516
Maes Expires û January 2006 [Page 8]
<LCONVERT> July 2005
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. SSL ensures confidentiality and integrity of the
proxied datastream, ensuring that the proxy cannot monitor the
content of messages, nor inject commands to modify or corrupt the
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 the overhead of SSL.
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 who
compromises the proxy 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 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.
It is beyond the scope of this document to define the implementation
of transcoding services. In general, it is recommended that they
reside within the same domain as the IMAP server, and are not
performed by third party services, which may compromise the privacy
of the data being transcoded.
Maes Expires û January 2006 [Page 9]
<LCONVERT> July 2005
B. LCONVERT transcoding parameters
LCONVERT servers MAY support additional transcoding parameters for
each media type. All LCONVERT compliant servers MUST minimally
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, 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 LCONVERT.
C: a001 UID FETCH 100 BINARY[2.LCONVERT (ôIMAGEö ôJPGö (ôWIDTHö
ô128ö ôHEIGHTö ô96ö))]
S: * 2 FETCH (UID 100 BODYPARTSTRUCTURE[2] ("IMAGE" "JPG"
() NIL NIL "8bit" 4182 NIL NIL NIL) BINARY[2] {4182}
<this part of a document is a rescaled image in JPG format
with width=128, height=96.>
)
S: a001 OK UID FETCH COMPLETED
Future Work
TBD
Version History
Release 01
Update to re-use the Binary / Fetch mechanisms in answer to SunÆs
comments
Release 00
Initial release published in June 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].
The following contributed to the authoring of LCONVERT.
Maes Expires û January 2006 [Page 10]
<LCONVERT> July 2005
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
416, Maetan-3dong, Yeongtong-gu,
Suwon-city, Gyeonggi-do,
Korea 442-600
Tel: +82-31-279-8289
E-mail: wh75.jeong@samsung.com
Maes Expires û January 2006 [Page 11]
<LCONVERT> July 2005
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,
Beijing,100053
China
TEL:.8610.66006688.3041
Dwayne Bennett
Maes Expires û January 2006 [Page 12]
<LCONVERT> July 2005
Consilient
P.O. Box 2172
St. John's, NL A1C 6E6
Canada
Tel: +1 709 576 1706
E-mail: bennett@consilient.com
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.
Maes Expires û January 2006 [Page 13]
<LCONVERT> July 2005
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
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 14]
