As per Relevance of the word implementation, we have this rfc below:
Network Working Group M.
Request for Comments: 1732 University of
Category: Informational December 1994
IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This is a summary of hints and recommendations to enable an IMAP
implementation to interoperate with implementations that conform
earlier specifications. None of these hints and recommendations
required by the IMAP4 specification; implementors must decide
themselves whether they want their implementation to fail if
encounters old software
IMAP4 has been designed to be upwards compatible with
specifications. For the most part, IMAP4 facilities that were not
earlier specifications should be invisible to clients unless
client asks for the facility
In some cases, older servers may support some of the
listed as being "new in IMAP4" as experimental extensions to
IMAP2 protocol described in RFC 1176.
This information may not be complete; it reflects current
of server and client implementations as well as "folklore"
in the evolution of the protocol
Crispin [Page 1]
RFC 1732 IMAP4 - Compatibility December 1994
IMAP4 client interoperability with old
In general, a client should be able to discover whether an IMAP
server supports a facility by trial-and-error; if an attempt to use
facility generates a BAD response, the client can assume that
server does not support the facility
A quick way to check whether a server implementation supports
IMAP4 specification is to try the CAPABILITY command. An OK
that includes the IMAP4 capability value indicates a server
supports IMAP4; a BAD response or one without the IMAP4
value indicates an older server
The following is a list of facilities that are only in IMAP4,
suggestions for how new clients might interoperate with old servers
CAPABILITY
A BAD response to this command indicates that the
implements IMAP2 (or IMAP2bis) and not IMAP4.
AUTHENTICATE command
Use the LOGIN command
LSUB and LIST
Try the RFC 1176 FIND command
* in a
Use the number of messages in the mailbox from the
unsolicited response
SEARCH extensions (character set, additional criteria
Reformulate the search request using only the
options listed in search_old in the IMAP4 grammar. This
entail doing multiple searches to achieve the
results
BODYSTRUCTURE fetch data
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
Use RFC822.HEADER and remove the unwanted information
BODY.PEEK[section], RFC822.PEEK, and RFC822.TEXT.PEEK fetch
items Use the corresponding non-PEEK versions and
clear the \Seen flag as necessary
Crispin [Page 2]
RFC 1732 IMAP4 - Compatibility December 1994
UID fetch data item and the UID
No equivalent capabilitity exists in older servers
FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data
Use the corresponding non-SILENT versions and ignore
untagged FETCH responses which com eback
The following IMAP4 facilities were introduced in the
IMAP2bis revisions to RFC-1176, and may be present in a server
does not support the CAPABILITY command
CREATE, DELETE, and RENAME
To test whether these commands are present, try a
INBOX command. If the response is NO, these commands
supported by the server. If the response is BAD, they
not. Older servers without the CREATE capability may sup
port implicit creation of a mailbox by a COPY command with
non-existant name as the destination
APPEND
To test whether this command is present, try to append
zero-length stream to a mailbox name that is known not
exist (or at least, highly unlikely to exist) on the
system
SUBSCRIBE and UNSUBSCRIBE
Try the form of these commands with the optional
keyword
EXAMINE
Use the SELECT command instead
flags and internal date argument to APPEND
Try the APPEND without any flag list and internal date argu
ments
BODY, BODY[section], and FULL fetch data
Use RFC822.TEXT and ALL instead. Server does not
MIME
PARTIAL
Use the appropriate FETCH command and ignore the
data
IMAP4 client implementations must accept all responses and data for
mats documented in the IMAP4 specification, including those
Crispin [Page 3]
RFC 1732 IMAP4 - Compatibility December 1994
as obsolete. This includes the COPY and STORE unsolicited
and the old format of dates and times. In particular, client imple
mentations must not treat a date/time as a fixed format string;
may they assume that the time begins at a particular octet
IMAP4 client implementations must not depend upon the presence of
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
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
on what may be done in that namespace
Older server implementations may automatically create the
mailbox on COPY if that mailbox does not already exist. This was
a new mailbox was created in older specifications. If the
does not support the CREATE command (see above for how to test
this), it will probably create a mailbox on COPY
Older server implementations may not preserve flags or internal
on COPY. Some server implementations may not permit the
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
In general, there should be no interoperation problem between
server conforming to the IMAP4 specification and a well-
client that conforms to an earlier specification. Known problems
noted below
Poor wording in the description of the CHECK command in
specifications implied that a CHECK command is the way to get
current number of messages in the mailbox. This is incorrect.
CHECK command does not necessarily result in an EXISTS response
Clients must remember the most recent EXISTS value sent from
server, and should not generate unnecessary CHECK commands
An incompatibility exists with COPY in IMAP4. COPY in IMAP
servers does not automatically create the destination mailbox
that mailbox does not already exist. This may cause problems
old clients that expect automatic mailbox creation in COPY
The PREAUTH unsolicited response is new in IMAP4. It is
unlikely that an old client would ever see this response
The format of dates and times has changed due to the impending
of the century. Clients that fail to accept a four-digit year
a signed four-digit timezone value will not work properly
IMAP4.
An incompatibility exists with the use of "\" in quoted strings
This is best avoided by using literals instead of quoted
if "\" or <"> is embedded in the string
Security
Security issues are not discussed in this memo
Author's Address
Mark R.
Networks and Distributed Computing, JE-30
University of
Seattle, WA 98195
Phone: (206) 543-5762
EMail: MRC@CAC.Washington.
Crispin [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
