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.