RFC relevance of complete

], as well as any .
forms of these

Any partial fetch that attempts to read beyond the end of the
is truncated as appropriate. If the starting octet is beyond
end of the text, an empty string is returned

The data are returned with the FETCH response. There is
indication of the range of the partial data in this response.
is not possible to stream multiple PARTIAL commands of the
data item without processing and synchronizing at each step,
streamed commands may be executed out of order

There is no requirement that partial fetches follow any sequence
For example, if a partial fetch of octets 1 through 10000
in an awkward place for BASE64 decoding, it is permitted
continue with a partial fetch of 9987 through 19987, etc

The handling of the \Seen flag is the same as in the
FETCH command

Example: C: A005 PARTIAL 4 RFC822 1 1024
S: * 1 FETCH (RFC822 {1024}
S: Return-Path: washington.edu
S: ...
S: ......... FLAGS (\Seen))
S: A005 OK PARTIAL

6.4.5.OBS.1 Obsolete FETCH Data

The following FETCH data items are obsolete

BODY[<...>0] A body part number of 0 is the [RFC-822] header
the message. BODY[0] is functionally equivalent
BODY[HEADER], differing in the syntax of
resulting untagged FETCH data (BODY[0]
returned).

RFC822.HEADER.LINES Functionally equivalent to BODY.PEEK[HEADER.
], differing in the syntax of
resulting untagged FETCH data (RFC822.HEADER
returned).

Crispin Informational [Page 4]

RFC 2062 IMAP4 Obsolete December 1996

RFC822.HEADER.LINES.NOT Functionally equivalent
BODY.PEEK[HEADER.LINES.NOT ],
differing in the syntax of the resulting
FETCH data (RFC822.HEADER is returned).

RFC822.PEEK Functionally equivalent to BODY.PEEK[], except
the syntax of the resulting untagged FETCH
(RFC822 is returned).

RFC822.TEXT.
Functionally equivalent to BODY.PEEK[TEXT],
for the syntax of the resulting untagged FETCH
(RFC822.TEXT is returned).

Obsolete

The following responses are OBSOLETE. Except as noted below,
responses MUST NOT be transmitted by new server implementations
Client implementations SHOULD accept these responses

The section headings of these responses are intended to
with where they would be located in the main document if they
not obsoleted

7.2.OBS.1. MAILBOX

Data:

The MAILBOX response MUST NOT be transmitted by
implementations except in response to the obsolete FIND
and FIND ALL.MAILBOXES commands. Client implementations that
not use these commands MAY ignore this response. It is
here for the benefit of implementors who may wish to support
for compatibility with old client implementations

This response occurs as a result of the FIND MAILBOXES and
ALL.MAILBOXES commands. It returns a single name that matches
FIND specification. There are no attributes or
delimiter

Example: S: * MAILBOX

Crispin Informational [Page 5]

RFC 2062 IMAP4 Obsolete December 1996

7.3.OBS.1. COPY

Data:

The COPY response MUST NOT be transmitted by new
implementations. Client implementations MUST ignore the
response. It is documented here for the benefit of
implementors who may encounter this response from old
implementations

In some experimental versions of this protocol, this response
returned in response to a COPY command to indicate on
per-message basis that the message was copied successfully

Example: S: * 44

7.3.OBS.2. STORE

Data: message

The STORE response MUST NOT be transmitted by new
implementations. Client implementations MUST treat the
response as equivalent to the FETCH response. It is
here for the benefit of client implementors who may encounter
response from old server implementations

In some experimental versions of this protocol, this response
returned instead of FETCH in response to a STORE command to
the new value of the flags

Example: S: * 69 STORE (FLAGS (\Deleted))

Formal Syntax of Obsolete Commands and

Each obsolete syntax rule that is suffixed with "_old" is added
the corresponding name in the formal syntax. For example
command_auth_old adds the FIND command to command_auth

command_auth_old ::=

command_select_
::=

date_year_old ::= 2
;; (year - 1900)

date_time_old ::= <"> date_day_fixed "-" date_month "-" date_
SPACE time "-" zone_name <">

Crispin Informational [Page 6]

RFC 2062 IMAP4 Obsolete December 1996

find ::= "FIND" SPACE ["ALL."] "MAILBOXES"
list_

fetch_att_old ::= "RFC822.HEADER.LINES" [".NOT"] SPACE header_list /
fetch_text_

fetch_text_old ::= "BODY" [".PEEK"] section_old /
"RFC822" [".HEADER" / ".TEXT" [".PEEK"]]

msg_data_old ::= "COPY" / ("STORE" SPACE msg_att

partial ::= "PARTIAL" SPACE nz_number SPACE fetch_text_old
number SPACE

section_old ::= "[" (number ["." number]) "]"

subscribe_old ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE

unsubscribe_old ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE

zone_name ::= "UT" / "GMT" / "Z" / ;; +0000
"AST" / "EDT" / ;; -0400
"EST" / "CDT" / ;; -0500
"CST" / "MDT" / ;; -0600
"MST" / "PDT" / ;; -0700
"PST" / "YDT" / ;; -0800
"YST" / "HDT" / ;; -0900
"HST" / "BDT" / ;; -1000
"BST" / ;; -1100
"A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6
"G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12
"N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6
"T" / "U" / "V" / "W" / "X" / "Y" ;; -7 to -12

Security

Security issues are not discussed in this memo

Crispin Informational [Page 7]

RFC 2062 IMAP4 Obsolete December 1996

Author's

Mark R.
Networks and Distributed
University of
4545 15th Aveneue
Seattle, WA 98105-4527

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

Crispin Informational [Page 8]

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