MBOX-Line: From ml.cyresse at gmail.com  Wed Jan  9 19:38:00 2008
To: imap-protocol@u.washington.edu
From: Liam Clarke <ml.cyresse@gmail.com>
Date: Fri Jun  8 12:34:41 2018
Subject: [Imap-protocol] Question on FETCH example in RFC3501
Message-ID: <b6f3249e0801091938m12cbccd6j4fff9f406cf0fee1@mail.gmail.com>

Hi,

I'm very new to IMAP, looking to implement a client library and
somewhat worried by this line in the RFC:

> A client MUST be prepared to accept any server response at all times. This includes server data that was not requested.

For the most part handling of unrequested untagged responses seems to
be straightforward pattern matching, as the context doesn't really
matter - but what has me confused and a little worried is one of the
examples of two FETCH responses in the last section of the RFC
(apologies for the long c&p):

C:   a003 fetch 12 full
S:   * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
      RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
      "IMAP4rev1 WG mtg summary and minutes"
      (("Terry Gray" NIL "gray" "cac.washington.edu"))
      (("Terry Gray" NIL "gray" "cac.washington.edu"))
      (("Terry Gray" NIL "gray" "cac.washington.edu"))
      ((NIL NIL "imap" "cac.washington.edu"))
      ((NIL NIL "minutes" "CNRI.Reston.VA.US")
      ("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
      "<B27397-0100000@cac.washington.edu>")
       BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028
       92))
S:    a003 OK FETCH completed
C:    a004 fetch 12 body[header]
S:    * 12 FETCH (BODY[HEADER] {342}
S:    Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S:    From: Terry Gray <gray@cac.washington.edu>
S:    Subject: IMAP4rev1 WG mtg summary and minutes
S:    To: imap@cac.washington.edu
S:    cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
S:    Message-Id: <B27397-0100000@cac.washington.edu>
S:    MIME-Version: 1.0
S:    Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S:    )
S:    a004 OK FETCH completed

From the layout and note that " A long line in this sample is broken
for editorial clarity." I'm deducing that the server response to a003
is all on a single \r\n delimited line, but is the second actually
split over multiple \r\n delimited lines?

If so, would it be possible for lines from separate fetch responses to
arrive together? Borrowing trouble from the future, but just got
worried when I saw that.

Regards,

Liam Clarke-Hutchinson

