FM / rfc

/opt/cpanel/ea-libc-client/share/docs/rfc/

/opt/cpanel/ea-libc-client/share/docs/rfc

Name	Size	Mode	Actions
README	2337	0644	edit dl rm
rfc1732.txt	9276	0644	edit dl rm
rfc1733.txt	6205	0644	edit dl rm
rfc2061.txt	5867	0644	edit dl rm
rfc2062.txt	14042	0644	edit dl rm
rfc2087.txt	8542	0644	edit dl rm
rfc2088.txt	4052	0644	edit dl rm
rfc2177.txt	6770	0644	edit dl rm
rfc2180.txt	24750	0644	edit dl rm
rfc2193.txt	16248	0644	edit dl rm
rfc2195.txt	10468	0644	edit dl rm
rfc2221.txt	9251	0644	edit dl rm
rfc2342.txt	19489	0644	edit dl rm
rfc2683.txt	56300	0644	edit dl rm
rfc2971.txt	14670	0644	edit dl rm
rfc3348.txt	11868	0644	edit dl rm
rfc3501.txt	227638	0644	edit dl rm
rfc3502.txt	13379	0644	edit dl rm
rfc3503.txt	16937	0644	edit dl rm
rfc3516.txt	14598	0644	edit dl rm
rfc3656.txt	35509	0644	edit dl rm
rfc3691.txt	8436	0644	edit dl rm
rfc4314.txt	56599	0644	edit dl rm
rfc4315.txt	16629	0644	edit dl rm
rfc4422.txt	73206	0644	edit dl rm
rfc4466.txt	33752	0644	edit dl rm
rfc4467.txt	36714	0644	edit dl rm
rfc4468.txt	28614	0644	edit dl rm
rfc4469.txt	21822	0644	edit dl rm
rfc4505.txt	16599	0644	edit dl rm
rfc4549.txt	75417	0644	edit dl rm
rfc4551.txt	50265	0644	edit dl rm
rfc4616.txt	20270	0644	edit dl rm
rfc4731.txt	15431	0644	edit dl rm
rfc4752.txt	22133	0644	edit dl rm
rfc4790.txt	55591	0644	edit dl rm
rfc4959.txt	12284	0644	edit dl rm
rfc4978.txt	17554	0644	edit dl rm
rfc5032.txt	8921	0644	edit dl rm
rfc5051.txt	14965	0644	edit dl rm
rfc5092.txt	65197	0644	edit dl rm
rfc5161.txt	12220	0644	edit dl rm
rfc5162.txt	51620	0644	edit dl rm
rfc5234.txt	26359	0644	edit dl rm

Edit: /opt/cpanel/ea-libc-client/share/docs/rfc/rfc3502.txt (13379B)

Network Working Group                                         M. Crispin
Request for Comments: 3502                      University of Washington
Category: Standards Track                                     March 2003

Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension

Status of this Memo

This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

This document describes the multiappending extension to the Internet
   Message Access Protocol (IMAP) (RFC 3501).  This extension provides
   substantial performance improvements for IMAP clients which upload
   multiple messages at a time to a mailbox on the server.

A server which supports this extension indicates this with a
   capability name of "MULTIAPPEND".

Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
   be interpreted as described in [KEYWORDS].

Introduction

The MULTIAPPEND extension permits uploading of multiple messages with
   a single command.  When used in conjunction with the [LITERAL+]
   extension, the entire upload is accomplished in a single
   command/response round trip.

A MULTIAPPEND APPEND operation is atomic; either all messages are
   successfully appended, or no messages are appended.

In the base IMAP specification, each message must be appended in a
   separate command, and there is no mechanism to "unappend" messages if
   an error occurs while appending.  Also, some mail stores may require

Crispin                     Standards Track                     [Page 1]

RFC 3502                    IMAP MULTIAPPEND                  March 2003

an expensive "open/lock + sync/unlock/close" operation as part of
   appending; this can be quite expensive if it must be done on a
   per-message basis.

If the server supports both LITERAL+ and pipelining but not
   MULTIAPPEND, it may be possible to get some of the performance
   advantages of MULTIAPPEND by doing a pipelined "batch" append.
   However, it will not work as well as MULTIAPPEND for the following
   reasons:

1) Multiple APPEND commands, even as part of a pipelined batch,
        are non-atomic by definition.  There is no way to revert the
        mailbox to the state before the batch append in the event of an
        error.

2) It may not be feasible for the server to coalesce pipelined
        APPEND operations so as to avoid the "open/lock +
        sync/unlock/close" overhead described above.  In any case, such
        coalescing would be timing dependent and thus potentially
        unreliable.  In particular, with traditional UNIX mailbox files,
        it is assumed that a lock is held only for a single atomic
        operation, and many applications disregard any lock that is
        older than 5 minutes.

3) If an error occurs, depending upon the nature of the error,
        it is possible for additional messages to be appended after the
        error.  For example, the user wants to append 5 messages, but a
        disk quota error occurs with the third message because of its
        size.  However, the fourth and fifth messages have already been
        sent in the pipeline, so the mailbox ends up with the first,
        second, fourth, and fifth messages of the batch appended.

6.3.11.  APPEND Command

Arguments:  mailbox name
               one or more messages to upload, specified as:
                  OPTIONAL flag parenthesized list
                  OPTIONAL date/time string
                  message literal

Data:       no specific responses for this command

Result:     OK - append completed
               NO - append error: can't append to that mailbox, error
                    in flags or date/time or message text,
                    append cancelled
               BAD - command unknown or arguments invalid

Crispin                     Standards Track                     [Page 2]

RFC 3502                    IMAP MULTIAPPEND                  March 2003

The APPEND command appends the literal arguments as new messages
      to the end of the specified destination mailbox.  This argument
      SHOULD be in the format of an [RFC-2822] message.  8-bit
      characters are permitted in the message.  A server implementation
      that is unable to preserve 8-bit data properly MUST be able to
      reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB]
      content transfer encoding.

Note: There MAY be exceptions, e.g., draft messages, in
            which required [RFC-2822] header lines are omitted in the
            message literal argument to APPEND.  The full implications
            of doing so MUST be understood and carefully weighed.

If a flag parenthesized list is specified, the flags SHOULD be set
      in the resulting message; otherwise, the flag list of the
      resulting message is set empty by default.

If a date-time is specified, the internal date SHOULD be set in
      the resulting message; otherwise, the internal date of the
      resulting message is set to the current date and time by default.

A zero-length message literal argument is an error, and MUST
      return a NO.  This can be used to cancel the append.

If the append is unsuccessful for any reason (including being
      cancelled), the mailbox MUST be restored to its state before the
      APPEND attempt; no partial appending is permitted.  The server MAY
      return an error before processing all the message arguments.

If the destination mailbox does not exist, a server MUST return an
      error, and MUST NOT automatically create the mailbox.  Unless it
      is certain that the destination mailbox can not be created, the
      server MUST send the response code "[TRYCREATE]" as the prefix of
      the text of the tagged NO response.  This gives a hint to the
      client that it can attempt a CREATE command and retry the APPEND
      if the CREATE is successful.

If the mailbox is currently selected, the normal new message
      actions SHOULD occur.  Specifically, the server SHOULD notify the
      client immediately via an untagged EXISTS response.  If the server
      does not do so, the client MAY issue a NOOP command (or failing
      that, a CHECK command) after one or more APPEND commands.

Crispin                     Standards Track                     [Page 3]

RFC 3502                    IMAP MULTIAPPEND                  March 2003

Example: C: A003 APPEND saved-messages (\Seen) {329}
            S: + Ready for literal data
            C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
            C: From: Fred Foobar <foobar@Blurdybloop.example.COM>
            C: Subject: afternoon meeting
            C: To: mooch@owatagu.example.net
            C: Message-Id: <B27397-0100000@Blurdybloop.example.COM>
            C: MIME-Version: 1.0
            C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
            C:
            C: Hello Joe, do you think we can meet at 3:30 tomorrow?
            C:  (\Seen) " 7-Feb-1994 22:43:04 -0800" {295}
            S: + Ready for literal data
            C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST)
            C: From: Joe Mooch <mooch@OWaTaGu.example.net>
            C: Subject: Re: afternoon meeting
            C: To: foobar@blurdybloop.example.com
            C: Message-Id: <a0434793874930@OWaTaGu.example.net>
            C: MIME-Version: 1.0
            C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
            C:
            C: 3:30 is fine with me.
            C:
            S: A003 OK APPEND completed
            C: A004 APPEND bogusname (\Flagged) {1023}
            S: A004 NO [TRYCREATE] No such mailbox as bogusname
            C: A005 APPEND test (\Flagged) {99}
            S: + Ready for literal data
            C: Date: Mon, 7 Feb 2000 22:43:04 -0800 (PST)
            C: From: Fred Foobar <fred@example.com>
            C: Subject: hmm...
            C:  {35403}
            S: A005 NO APPEND failed: Disk quota exceeded

Note: The APPEND command is not used for message delivery,
        because it does not provide a mechanism to transfer [SMTP]
        envelope information.

Modification to IMAP4rev1 Base Protocol Formal Syntax

The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) notation as specified in [ABNF].

append          = "APPEND" SP mailbox 1*append-message

append-message  = [SP flag-list] [SP date-time] SP literal

Crispin                     Standards Track                     [Page 4]

RFC 3502                    IMAP MULTIAPPEND                  March 2003

MULTIAPPEND Interaction with UIDPLUS Extension

Servers which support both MULTIAPPEND and [UIDPLUS] will have the
   "resp-code-apnd" rule modified as follows:

resp-code-apnd  = "APPENDUID" SP nz-number SP set

That is, the APPENDUID response code returns as many UIDs as there
   were messages appended in the multiple append.  The UIDs returned
   should be in the order the articles where appended.  The message set
   may not contain extraneous UIDs or the symbol "*".

Security Considerations

The MULTIAPPEND extension does not raise any security considerations
   that are not present in the base [IMAP] protocol, and these issues
   are discussed in [IMAP].  Nevertheless, it is important to remember
   that IMAP4rev1 protocol transactions, including electronic mail data,
   are sent in the clear over the network unless protection from
   snooping is negotiated, either by the use of STARTTLS, privacy
   protection is negotiated in the AUTHENTICATE command, or some other
   protection mechanism is in effect.

Normative References

[ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

[IMAP]     Crispin, M., "Internet Message Access Protocol - Version
              4rev1", RFC 3501, March 2003.

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[MIME-IMB] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet
              Mail Extensions) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

[RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April
              2001.

Crispin                     Standards Track                     [Page 5]

RFC 3502                    IMAP MULTIAPPEND                  March 2003

Informative References

[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
              January 1997.

[UIDPLUS]  Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1988.

[SMTP]     Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC
              2821, April 2001.

Author's Address

Mark R. Crispin
   Networks and Distributed Computing
   University of Washington
   4545 15th Avenue NE
   Seattle, WA  98105-4527

Phone: (206) 543-5762
   EMail: MRC@CAC.Washington.EDU

Crispin                     Standards Track                     [Page 6]

RFC 3502                    IMAP MULTIAPPEND                  March 2003

Full Copyright Statement

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.

This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
   Internet Society.

Crispin                     Standards Track                     [Page 7]

cmd: