home *** CD-ROM | disk | FTP | other *** search
/ ftp.uv.es / 2014.11.ftp.uv.es.tar / ftp.uv.es / pub / unix / pine4.10.tar.gz / pine4.10.tar / pine4.10 / imap / docs / rfc / rfc2359.txt < prev   
Text File  |  1998-06-18  |  11KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           J. Myers
  8. Request for Comments: 2359                       Netscape Communications
  9. Category: Standards Track                                      June 1998
  10.  
  11.  
  12.                         IMAP4 UIDPLUS extension
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. Copyright Notice
  23.  
  24.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  25.  
  26. IESG NOTE
  27.  
  28.    The IMAP extension described here assumes a particular means of using
  29.    IMAP to support disconnected operation.  However, this means of
  30.    supporting disconnected operation is not yet documented.  Also, there
  31.    are multiple theories about how best to do disconnected operation in
  32.    IMAP, and as yet, there is no consensus on which one should be
  33.    adopted as a standard.
  34.  
  35.    This document is being approved as a Proposed Standard because it
  36.    does not appear to have technical flaws in itelf.  However, approval
  37.    of this document as a Proposed Standard should not be considered an
  38.    IETF endorsement of any particular means of doing disconnected
  39.    operation in IMAP.
  40.  
  41. Table of Contents
  42.  
  43.    1.   Abstract ..............................................    2
  44.    2.   Conventions Used in this Document .....................    2
  45.    3.   Introduction and Overview .............................    2
  46.    4.   Features ..............................................    2
  47.    4.1. UID EXPUNGE Command ...................................    2
  48.    4.2. APPENDUID response code ...............................    3
  49.    4.3. COPYUID response code .................................    4
  50.    5.   Formal Syntax .........................................    4
  51.    6.   References ............................................    4
  52.    7.   Security Considerations ...............................    5
  53.    8.   Author's Address ......................................    5
  54.    9.   Full Copyright Statement ..............................    6
  55.  
  56.  
  57.  
  58. Myers                       Standards Track                     [Page 1]
  59.  
  60. RFC 2359                IMAP4 UIDPLUS extension                June 1998
  61.  
  62.  
  63. 1.   Abstract
  64.  
  65.    The UIDPLUS extension of the Internet Message Access Protocol [IMAP4]
  66.    provides a set of features intended to reduce the amount of time and
  67.    resources used by some client operations.  The features in UIDPLUS
  68.    are primarily intended for disconnected-use clients.
  69.  
  70. 2.   Conventions Used in this Document
  71.  
  72.    In examples, "C:" and "S:" indicate lines sent by the client and
  73.    server respectively.
  74.  
  75.    The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
  76.    in this document are to be interpreted as defined in "Key words for
  77.    use in RFCs to Indicate Requirement Levels" [KEYWORDS].
  78.  
  79. 3.   Introduction and Overview
  80.  
  81.    The UIDPLUS extension is present in any IMAP4 server implementation
  82.    which returns "UIDPLUS" as one of the supported capabilities to the
  83.    CAPABILITY command.  The UIDPLUS extension contains one additional
  84.    command and additional data returned with successful APPEND and COPY
  85.    commands.
  86.  
  87.    Clients that wish to use the new command in UIDPLUS must of course
  88.    first test for the presence of the extension by issuing a CAPABILITY
  89.    command.  Each of the features in UIDPLUS are optimizations; clients
  90.    can provide the same functionality, albeit more slowly, by using
  91.    commands in the base protocol.  With each feature, this document
  92.    recommends a fallback approach to take when the UIDPLUS extension is
  93.    not supported by the server.
  94.  
  95. 4.   Features
  96.  
  97. 4.1. UID EXPUNGE Command
  98.  
  99.    Arguments:  message set
  100.  
  101.    Data:       untagged responses: EXPUNGE
  102.  
  103.    Result:     OK - expunge completed
  104.                NO - expunge failure (e.g. permission denied)
  105.                BAD - command unknown or arguments invalid
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Myers                       Standards Track                     [Page 2]
  115.  
  116. RFC 2359                IMAP4 UIDPLUS extension                June 1998
  117.  
  118.  
  119.       The UID EXPUNGE command permanently removes from the currently
  120.       selected mailbox all messages that both have the \Deleted flag set
  121.       and have a UID that is included in the specified message set.  If
  122.       a message either does not have the \Deleted flag set or is has a
  123.       UID that is not included in the specified message set, it is not
  124.       affected.
  125.  
  126.       This command may be used to ensure that a replayed EXPUNGE command
  127.       does not remove any messages that have been marked as \Deleted
  128.       between the time that the user requested the expunge operation and
  129.       the time the server processes the command.
  130.  
  131.       If the server does not support the UIDPLUS capability, the client
  132.       should fall back to using the STORE command to temporarily remove
  133.       the \Deleted flag from messages it does not want to remove.  The
  134.       client could alternatively fall back to using the EXPUNGE command,
  135.       risking the unintended removal of some messages.
  136.  
  137.    Example:    C: A003 UID EXPUNGE 3000:3002
  138.                S: * 3 EXPUNGE
  139.                S: * 3 EXPUNGE
  140.                S: * 3 EXPUNGE
  141.                S: A003 OK UID EXPUNGE completed
  142.  
  143. 4.2. APPENDUID response code
  144.  
  145.    Successful APPEND commands return an APPENDUID response code in the
  146.    tagged OK response.  The APPENDUID response code contains as
  147.    arguments the UIDVALIDITY of the destination mailbox and the UID
  148.    assigned to the appended message.
  149.  
  150.    If the server does not support the UIDPLUS capability, the client can
  151.    only discover this information by selecting the destination mailbox
  152.    and issuing FETCH commands.
  153.  
  154.    Example:    C: A003 APPEND saved-messages (\Seen) {310}
  155.                C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
  156.                C: From: Fred Foobar <foobar@Blurdybloop.COM>
  157.                C: Subject: afternoon meeting
  158.                C: To: mooch@owatagu.siam.edu
  159.                C: Message-Id: <B27397-0100000@Blurdybloop.COM>
  160.                C: MIME-Version: 1.0
  161.                C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  162.                C:
  163.                C: Hello Joe, do you think we can meet at 3:30 tomorrow?
  164.                C:
  165.                S: A003 OK [APPENDUID 38505 3955] APPEND completed
  166.  
  167.  
  168.  
  169.  
  170. Myers                       Standards Track                     [Page 3]
  171.  
  172. RFC 2359                IMAP4 UIDPLUS extension                June 1998
  173.  
  174.  
  175. 4.3. COPYUID response code
  176.  
  177.    Successful COPY and UID COPY commands return a COPYUID response code
  178.    in the tagged OK response whenever at least one message was copied.
  179.    The COPYUID response code contains as an argument the UIDVALIDITY of
  180.    the appended-to mailbox, a message set containing the UIDs of the
  181.    messages copied to the destination mailbox, in the order they were
  182.    copied, and a message containing the UIDs assigned to the copied
  183.    messages, in the order they were assigned.  Neither of the message
  184.    sets may contain extraneous UIDs or the symbol '*'.
  185.  
  186.    If the server does not support the UIDPLUS capability, the client can
  187.    only discover this information by selecting the destination mailbox
  188.    and issuing FETCH commands.
  189.  
  190.    Example:    C: A003 COPY 2:4 MEETING
  191.                S: A003 OK [COPYUID 38505 304,319:320 3956:3958] Done
  192.                C: A003 UID COPY 305:310 MEETING
  193.                S: A003 OK Done
  194.  
  195. 5.   Formal Syntax
  196.  
  197.    The following syntax specification uses the augmented Backus-Naur
  198.    Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
  199.    Non-terminals referenced but not defined below are as defined by
  200.    [IMAP4].
  201.  
  202.    Except as noted otherwise, all alphabetic characters are case-
  203.    insensitive.  The use of upper or lower case characters to define
  204.    token strings is for editorial clarity only.  Implementations MUST
  205.    accept these strings in a case-insensitive fashion.
  206.  
  207.    resp_code_apnd  ::= "APPENDUID" SPACE nz_number SPACE uniqueid
  208.  
  209.    resp_code_copy  ::= "COPYUID" SPACE nz_number SPACE set SPACE set
  210.  
  211.    uid_expunge     ::= "UID" SPACE "EXPUNGE" SPACE set
  212.  
  213. 6.   References
  214.  
  215.    [IMAP4]    Crispin, M., "Internet Message Access Protocol -
  216.               Version 4rev1", RFC 2060, December 1996.
  217.  
  218.    [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
  219.               Requirement Levels", BCP 14, RFC 2119, March 1997.
  220.  
  221.    [RFC-822]  Crocker, D., "Standard for the Format of ARPA Internet
  222.               Text Messages", STD 11, RFC 822, August 1982.
  223.  
  224.  
  225.  
  226. Myers                       Standards Track                     [Page 4]
  227.  
  228. RFC 2359                IMAP4 UIDPLUS extension                June 1998
  229.  
  230.  
  231. 7.   Security Considerations
  232.  
  233.    There are no known security issues with this extension.
  234.  
  235. 8.   Author's Address
  236.  
  237.    John Gardiner Myers
  238.    Netscape Communications
  239.    501 East Middlefield Road
  240.    Mail Stop MV-029
  241.    Mountain View, CA  94043
  242.  
  243.    EMail: jgmyers@netscape.com
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Myers                       Standards Track                     [Page 5]
  283.  
  284. RFC 2359                IMAP4 UIDPLUS extension                June 1998
  285.  
  286.  
  287. 9.  Full Copyright Statement
  288.  
  289.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  290.  
  291.    This document and translations of it may be copied and furnished to
  292.    others, and derivative works that comment on or otherwise explain it
  293.    or assist in its implementation may be prepared, copied, published
  294.    and distributed, in whole or in part, without restriction of any
  295.    kind, provided that the above copyright notice and this paragraph are
  296.    included on all such copies and derivative works.  However, this
  297.    document itself may not be modified in any way, such as by removing
  298.    the copyright notice or references to the Internet Society or other
  299.    Internet organizations, except as needed for the purpose of
  300.    developing Internet standards in which case the procedures for
  301.    copyrights defined in the Internet Standards process must be
  302.    followed, or as required to translate it into languages other than
  303.    English.
  304.  
  305.    The limited permissions granted above are perpetual and will not be
  306.    revoked by the Internet Society or its successors or assigns.
  307.  
  308.    This document and the information contained herein is provided on an
  309.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  310.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  311.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  312.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  313.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Myers                       Standards Track                     [Page 6]
  339.  
  340.