[Imap-protocol] Unsolicited server responses

--===============8787923503268998210==
Content-Type: multipart/alternative; boundary="0000000000000b77fd057875b832"

--0000000000000b77fd057875b832
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

When can and should a server send data the client hasn=E2=80=99t requested?
RFC3501#2.2.2 says =E2=80=9CA client MUST be prepared to accept any server =
response
at all times. This includes server data that was not requested.=E2=80=9D Lo=
oking at
the semantics of the server responses, only EXISTS, RECENT, EXPUNGE and
FETCH stipulate sending =E2=80=9Cunrequested=E2=80=9D data.

Should this be interpreted, =E2=80=9CIn theory the server can send whatever
responses whenever it wants.  In practice, it just sends those four
piggybacked on command completion responses if there=E2=80=99s an unreporte=
d
mailbox update.=E2=80=9D

Given that the server can unilaterally send updates to the client, why was
the IDLE extension useful/necessary?

Aaron

--0000000000000b77fd057875b832
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

When can and should a server send data the client hasn=E2=80=99t requested?=
=C2=A0 RFC3501#2.2.2 says =E2=80=9CA client MUST be prepared to accept any =
server response at all times. This includes server data that was not reques=
ted.=E2=80=9D Looking at the semantics of the server responses, only EXISTS=
, RECENT, EXPUNGE and FETCH stipulate sending =E2=80=9Cunrequested=E2=80=9D=
 data.=C2=A0<div><br></div><div>Should this be interpreted, =E2=80=9CIn the=
ory the server can send whatever responses whenever it wants.=C2=A0 In prac=
tice, it just sends those four piggybacked on command completion responses =
if there=E2=80=99s an unreported mailbox update.=E2=80=9D</div><div><br></d=
iv><div>Given that the server can unilaterally send updates to the client, =
why was the IDLE extension useful/necessary?</div><div><br></div><div>Aaron=
=C2=A0</div>

--0000000000000b77fd057875b832--

--===============8787923503268998210==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
--===============8787923503268998210==--