Internet DRAFT - draft-wener-lemonade-conversion
draft-wener-lemonade-conversion
Internet Draft: IMAP Extension for CONVERSION M. Wener
Document: draft-wener-lemonade-conversion-00.txt Nokia, Inc.
Expires: August 2005 February 2005
IMAP Extension for Body Part Conversion
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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
This document describes an IMAP extension that allows a client to
convert and retrieve message MIME parts on demand. The conversion
would be from one Content-Type to another. The client can discover
the conversion set the server supports. It is assumed that there are
two distinct phases: one, server conversion capability discovery,
and two, client retrieval of a converted MIME part. In addition
to MIME type conversion this document allows for compressed body
part retrieval as a special case of conversion.
1. Introduction and Overview
The assumption is that the client knows best what body part needs to
be converted and what the target should be. Also, the client knows
best when it needs a particular body part converted.
The set of goals being met by this document are:
1) To give the client maximum control and choice.
2) Avoid having the server do unrequired conversions. Conversions
should be on client demand.
3) Avoid verbose communication of large capability sets. The
client should not be burdened by information that it is
not interested in.
In pursuit of these goals there are two main areas of functionality
specified: discovery and retrieval. Discovery is the act of the client
finding out what is a legal conversion. Retrieval is the client
obtaining the converted bytes.
Discovery is accomplished via a new server annotation entry. The entry
will allow the advertisement of range domain mappings. The client uses
the GETANNOTATION command to obtain a subset of mappings that it is
interested in. These mappings are read-only to all clients.
Retrieval is accomplished by use of the existing FETCH command. The
FETCH command has new modifiers used to indicate that the body part
is to be converted when retrieved.
A server supporting the conversion capability will advertise this via
the CONVERSION capability string returned in all CAPABILITY command
responses. In addition the server MUST support the annotate more
extension [ANNOTATEMORE].
2. Conversion Capability Discovery
The set of legal conversions a server supports are advertised with a
set of server annotations. The syntax and form of these entries are
as defined in the annotate more specification [ANNOTATEMORE].
The server entries defined in ANNOTATEMORE are extended with the
entries defined in the following section.
2.1 Entries
These entries are used when the mailbox name argument for the
GETANNOTATION command is the empty string.
/conversion
The existence of this entry indicates that the server supports
some type of conversion.
<<In addition attributes could be used to specify general
parameters>>
/conversion/<mime-type>
A conversion can be viewed as a mapping from a domain to a range.
The domain is the set of MIME types that can be converted. The
range is the set of MIME types that a member of the domain can
be converted to.
Each entry in this set is a member of the domain of legal
conversions. If a server has an entry in this item the server
can legally convert from this MIME type to some other MIME type.
The range MIME type is indicated via the range attribute.
/conversion/compress
Server supports the compression of MIME body parts as part of
the general conversion support.
The supported algorithm is specified with the "value" attribute.
2.2 Attributes
The attributes defined are the same as those defined in the annotate
more specification except for the /conversion/<mime-type> entry. The
"value" entry is replaced with the "range" entry.
range
A semi-colon separated list of MIME types. This list is the set
of MIME types that this entry may be converted to.
2.3 Conversion Entry Discovery
The GETANNOTATION command as defined in the annotate more
specification is used to retrieve conversion information. The
SETANNOTATION command is not supported.
Example:
C: a GETANNOTATION "" "/conversion/application/pdf" "range.shared"
S: * ANNOTATION "" "/conversion/application/pdf"
("range.shared" "test/plain;text/html")
S: a OK GETANNOTATION complete
3. Converted Byte Retrieval
3.1 FETCH Command Modification
Result: OK - Conversion fetch completed
NO - fetch error: can't convert that data, or illegal
body section specifier.
The FETCH command is modified by adding a new modifier. The modifier
when present means the server should check to see if it is a legal
conversion as per what it has advertised via the server annotation
entry. If it is not legal a NO response is generated. If it is a
legal conversion then the converted bytes are generated and sent
back subject to the CONVERSION data item.
BODY.CONVERT[<section>]<<partial>>
Retrieve the converted bytes of the body part specified by the
section. The retrieval is subject to partial retrieval as per
the partial byte specification.
BODY.CONVERT.PEEK[<section>]<<partial>>
A form of BODY.CONVERT that does not set the \Seen flag.
BODY.CONVERT.SIZE[<section>]
A form of BODY.CONVERT that returns the estimated converted size.
This is an estimate and the client MUST NOT rely on this size as
an exact size. This MUST NOT set the \Seen flag.
CONVERSION
This is used to pass parameters the server may need to perform
the conversion. There is a single required parameter. The first
parameter MUST indicate a fully specified MIME Content Type. The
Content Type is the Content Type to convert the body part to.
Additional parameters MAY be specified. << TBD: but the idea is
that these would be the parameters that may be needed for more
complex parametrically driven conversions>>
The values passed in this data item are advertised by the
sever via the server annotation entries.
A single CONVERSION data item MUST be specified if there are any
BODY.CONVERT data items in the fetch command. The single CONVERSION
item MUST apply to all BODY.CONVERT data items in the command.
<<Binary transmission of converted body part? This could leverage off
of RFC3516 or another modifier could be added such as
BODY.CONVERT.BINARY>>
Example:
C: 1 UID FETCH 678 (BODY.CONVERT[1.3] CONVERSION (text/plain)
S: * 4 FETCH (UID 678 BODY.CONVERT[1.3] {567}
S: ...
S: )
S: 1 OK FETCH Completed
Example:
C: 1 UID FETCH 678 (BODY.CONVERT.SIZE[1.3] CONVERSION (text/plain)
S: * 4 FETCH (UID 678 BODY.CONVERT[1.3] 600)
S: 1 OK FETCH Completed
3.2 FETCH Response Additions
Two new response data items are defined.
BODY.CONVERT[<section>]<<origin octet>>
This response has the same form and function as the BODY[] response
defined in in IMAP4Rev1 [RFC3501]. The only difference is that the
literal contains the converted body part. It has the Content-Type
specified by the CONVERSION FETCH command data item.
BODY.CONVERT.SIZE[<section>]
A numeric value providing the estimated size of the entire body part
after conversion.
3.3 ILLEGALCONVERSION Response Code
If the client asks for a conversion that the server does not support
the tagged response to the overall command will be NO and the response
MUST contain the ILLEGALCONVERSION Response Code. The response code
MUST prefix any text in the NO response.
This failure could be for any one or more of the messages in the
sequence number or UID set passed to the command.
Example:
C: 2 FETCH 5,6 (BODY.CONVERT[1.2] CONVERSION (text/plain)
S: * 6 FETCH (BODY.CONVERT[1.2] {567}
S: ...
S: )
S: 2 NO [ILLEGALCONVERSION] FETCH Failed Conversion
The intent is for the client to avoid getting this response code by
using discovery to determine if the server supports a particular
conversion.
4. Body Part Compression
It is recognized that compression is a special case for conversion.
Body part compression can be obtained very simply by creating a
keyword to replace or extend the Content Type parameter in the
CONVERSION data item.
The keyword used to indicate compression is "compress". If the
compress keyword is specified then the body part is retrieved in a
in a compressed form. It MAY or MAY NOT be converted when compressed.
Example:
C: 3 FETCH 8 (BODY.CONVERT[1.2] CONVERSION (text/plain compress)
S: * 6 FETCH (BODY.CONVERT[1.2] {567}
S: ...
S: )
S: 3 OK FETCH Completed
To retrieve multiple mail messages in a compressed form with no
conversion.
Example:
C: 4 FETCH 1:5 (BODY.CONVERT[] CONVERSION (compress)
S: * 1 FETCH ...
S: * 2 FETCH ...
S: * 3 FETCH ...
S: * 4 FETCH ...
S: * 5 FETCH ...
S: 4 OK FETCH Completed
5. Formal Syntax
<<TODO>>
6. Author
Michael J. Wener
Nokia, Inc.
EMail: Michael.Wener@Nokia.com
7. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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.
8. Intellectual Property Statement
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."
References
[ANNOTATEMORE] Daboo, C., "IMAP ANNOTATEMORE Extension"
, draft-daboo-imap-annotatemore-07, 2005.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
