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/rfc1732.txt (9276B)

Network Working Group                                         M. Crispin
Request for Comments: 1732                      University of Washington
Category: Informational                                    December 1994

IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS

Status of this Memo

This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Introduction

This is a summary of hints and recommendations to enable an IMAP4
   implementation to interoperate with implementations that conform to
   earlier specifications.  None of these hints and recommendations are
   required by the IMAP4 specification; implementors must decide for
   themselves whether they want their implementation to fail if it
   encounters old software.

IMAP4 has been designed to be upwards compatible with earlier
   specifications.  For the most part, IMAP4 facilities that were not in
   earlier specifications should be invisible to clients unless the
   client asks for the facility.

In some cases, older servers may support some of the capabilities
   listed as being "new in IMAP4" as experimental extensions to the
   IMAP2 protocol described in RFC 1176.

This information may not be complete; it reflects current knowledge
   of server and client implementations as well as "folklore" acquired
   in the evolution of the protocol.

Crispin                                                         [Page 1]

RFC 1732                 IMAP4 - Compatibility             December 1994

IMAP4 client interoperability with old servers

In general, a client should be able to discover whether an IMAP2
   server supports a facility by trial-and-error; if an attempt to use a
   facility generates a BAD response, the client can assume that the
   server does not support the facility.

A quick way to check whether a server implementation supports the
   IMAP4 specification is to try the CAPABILITY command.  An OK response
   that includes the IMAP4 capability value indicates a server that
   supports IMAP4; a BAD response or one without the IMAP4 capability
   value indicates an older server.

The following is a list of facilities that are only in IMAP4, and
   suggestions for how new clients might interoperate with old servers:

CAPABILITY command
            A BAD response to this command indicates that the server
            implements IMAP2 (or IMAP2bis) and not IMAP4.

AUTHENTICATE command.
            Use the LOGIN command.

LSUB and LIST commands
            Try the RFC 1176 FIND command.

* in a sequence
            Use the number of messages in the mailbox from the EXISTS
            unsolicited response.

SEARCH extensions (character set, additional criteria)
            Reformulate the search request using only the searching
            options listed in search_old in the IMAP4 grammar.  This may
            entail doing multiple searches to achieve the desired
            results.

BODYSTRUCTURE fetch data item
            Try to fetch the non-extensible BODY data item.

body section number 0
            Fetch the entire message and extract the header.

RFC822.HEADER.LINES and RFC822.HEADER.LINES.NOT fetch data items
            Use RFC822.HEADER and remove the unwanted information.

BODY.PEEK[section], RFC822.PEEK, and RFC822.TEXT.PEEK fetch data
            items Use the corresponding non-PEEK versions and manually
            clear the \Seen flag as necessary.

Crispin                                                         [Page 2]

RFC 1732                 IMAP4 - Compatibility             December 1994

UID fetch data item and the UID commands
            No equivalent capabilitity exists in older servers.

FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items
            Use the corresponding non-SILENT versions and ignore the
            untagged FETCH responses which com eback.

The following IMAP4 facilities were introduced in the experimental
   IMAP2bis revisions to RFC-1176, and may be present in a server that
   does not support the CAPABILITY command:

CREATE, DELETE, and RENAME commands
            To test whether these commands are present, try a CREATE
            INBOX command.  If the response is NO, these commands are
            supported by the server.  If the response is BAD, they are
            not.  Older servers without the CREATE capability may sup-
            port implicit creation of a mailbox by a COPY command with a
            non-existant name as the destination.

APPEND command
            To test whether this command is present, try to append a
            zero-length stream to a mailbox name that is known not to
            exist (or at least, highly unlikely to exist) on the remote
            system.

SUBSCRIBE and UNSUBSCRIBE commands
            Try the form of these commands with the optional MAILBOX
            keyword.

EXAMINE command
            Use the SELECT command instead.

flags and internal date argument to APPEND command
            Try the APPEND without any flag list and internal date argu-
            ments.

BODY, BODY[section], and FULL fetch data items
            Use RFC822.TEXT and ALL instead.  Server does not support
            MIME.

PARTIAL command
            Use the appropriate FETCH command and ignore the unwanted
            data.

IMAP4 client implementations must accept all responses and data for-
   mats documented in the IMAP4 specification, including those labeled

Crispin                                                         [Page 3]

RFC 1732                 IMAP4 - Compatibility             December 1994

as obsolete.  This includes the COPY and STORE unsolicited responses
   and the old format of dates and times.  In particular, client imple-
   mentations must not treat a date/time as a fixed format string; nor
   may they assume that the time begins at a particular octet.

IMAP4 client implementations must not depend upon the presence of any
   server extensions that are not in the base IMAP4 specification.

The experimental IMAP2bis version specified that the TRYCREATE spe-
   cial information token is sent as a separate unsolicited OK response
   instead of inside the NO response.

The FIND BBOARDS, FIND ALL.BBOARDS, and BBOARD commands of RFC 1176
   are removed from IMAP4.  There is no equivalent to the bboard com-
   mands, which provided a separate namespace with implicit restrictions
   on what may be done in that namespace.

Older server implementations may automatically create the destination
   mailbox on COPY if that mailbox does not already exist.  This was how
   a new mailbox was created in older specifications.  If the server
   does not support the CREATE command (see above for how to test for
   this), it will probably create a mailbox on COPY.

Older server implementations may not preserve flags or internal dates
   on COPY.  Some server implementations may not permit the preservation
   of certain flags on COPY or their setting with APPEND as site policy.

Crispin                                                         [Page 4]

RFC 1732                 IMAP4 - Compatibility             December 1994

IMAP4 server interoperability with old clients

In general, there should be no interoperation problem between a
   server conforming to the IMAP4 specification and a well-written
   client that conforms to an earlier specification.  Known problems are
   noted below:

Poor wording in the description of the CHECK command in earlier
      specifications implied that a CHECK command is the way to get the
      current number of messages in the mailbox.  This is incorrect.  A
      CHECK command does not necessarily result in an EXISTS response.
      Clients must remember the most recent EXISTS value sent from the
      server, and should not generate unnecessary CHECK commands.

An incompatibility exists with COPY in IMAP4.  COPY in IMAP4
      servers does not automatically create the destination mailbox if
      that mailbox does not already exist.  This may cause problems with
      old clients that expect automatic mailbox creation in COPY.

The PREAUTH unsolicited response is new in IMAP4.  It is highly
      unlikely that an old client would ever see this response.

The format of dates and times has changed due to the impending end
      of the century.  Clients that fail to accept a four-digit year or
      a signed four-digit timezone value will not work properly with
      IMAP4.

An incompatibility exists with the use of "\" in quoted strings.
      This is best avoided by using literals instead of quoted strings
      if "\" or <"> is embedded in the string.

Security Considerations

Security issues are not discussed in this memo.

Author's Address:

Mark R. Crispin
   Networks and Distributed Computing, JE-30
   University of Washington
   Seattle, WA  98195

Phone: (206) 543-5762

EMail: MRC@CAC.Washington.EDU

Crispin                                                         [Page 5]

cmd: