Hi Mark,
Thanks for that - my vague fear is that a poorly behaved server could
mix responses to one request with responses for another, which
probably betrays my lack of experience with IMAP servers. And I've
downloaded your library, just looking to implement some partial
functionality as a method of learning the protocol. I'm a learn by
doing kinda guy. Back to the RFC :)
Regards,
Liam Clarke-Hutchinson
On Jan 10, 2008 4:53 PM, Mark Crispin <MRC@cac.washington.edu> wrote:
> 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.
>