112 lines
4.4 KiB
Plaintext
112 lines
4.4 KiB
Plaintext
MBOX-Line: From MRC at CAC.Washington.EDU Wed Jan 9 19:53:27 2008
|
|
To: imap-protocol@u.washington.edu
|
|
From: Mark Crispin <MRC@CAC.Washington.EDU>
|
|
Date: Fri Jun 8 12:34:41 2018
|
|
Subject: [Imap-protocol] Question on FETCH example in RFC3501
|
|
In-Reply-To: <b6f3249e0801091938m12cbccd6j4fff9f406cf0fee1@mail.gmail.com>
|
|
References: <b6f3249e0801091938m12cbccd6j4fff9f406cf0fee1@mail.gmail.com>
|
|
Message-ID: <alpine.WNT.1.00.0801091945320.3080@Tomobiki-Cho.CAC.Washignton.EDU>
|
|
|
|
In the example that you quoted, you will notice that lines from the client
|
|
are labelled with "C:" and lines from the server are labelled with "S:".
|
|
But, in this example, there are some physical lines which are not
|
|
labelled. Those are all part of the same line that came from the server,
|
|
and the line break that was in the example is not actually in the
|
|
protocol.
|
|
|
|
I'm not sure what you mean by "the second". Do you mean the response to
|
|
the a004 command? That is, indeed, a multiline response, but you will
|
|
notice the use of a literal (the "{342}").
|
|
|
|
An IMAP client must read an arbitrarily long line from the server. And by
|
|
"arbitrarily long" I mean exactly that; there is no limit. If the line
|
|
does not end with a literal size specifier such as {342} that is the end
|
|
of the response. If, however, the line ends with such a specifier, then
|
|
you must read exactly that number of octets in substitution for the
|
|
literal size specifier, THEN more of the line afterwards.
|
|
|
|
For example, the two responses
|
|
|
|
* 12 FETCH FOO {3}
|
|
BAR ZAP {5}
|
|
ZOWIE
|
|
|
|
and
|
|
|
|
* 12 FETCH FOO BAR ZAP ZOWIE
|
|
|
|
are exactly equivalent.
|
|
|
|
Does this answer your question?
|
|
|
|
I would also like to suggest that, instead of implementing a client
|
|
library, that you consider using an existing client library for your
|
|
application. One such library is my c-client library, part of the UW IMAP
|
|
Tookit on
|
|
ftp://ftp.cac.washington.edu/mail/imap.tar.Z
|
|
|
|
On Thu, 10 Jan 2008, Liam Clarke wrote:
|
|
> 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
|
|
> _______________________________________________
|
|
> Imap-protocol mailing list
|
|
> Imap-protocol@u.washington.edu
|
|
> https://mailman1.u.washington.edu/mailman/listinfo/imap-protocol
|
|
>
|
|
|
|
-- Mark --
|
|
|
|
http://staff.washington.edu/mrc
|
|
Science does not emerge from voting, party politics, or public debate.
|
|
Si vis pacem, para bellum.
|
|
|