On Tue, 9 Jul 2002, Alexey Melnikov wrote:
> If I understood the question correctly: "why would the server bother
> returning this"? Can the server don't send FETCH reply in this case.
It could avoid sending a FETCH reply, but then it would have to send a NO
instead of an OK. It is a protocol vi
Mark Crispin wrote:
> On Tue, 9 Jul 2002, David Harris wrote:
> > assume we
> > have a message with 384 bytes, and the client issues this command:
> >A30 FETCH 42 (BODY[TEXT]<385.16384>)
> > Am I correct in assuming that the correct return for this command is:
> >* 42 FETCH (BODY[TEXT]<
Mark Crispin <[EMAIL PROTECTED]>
> The more difficult issue is if the client asked for BODY[TEXT]<386.16384>.
> I contend that BODY[TEXT]<386> (zero bytes starting at byte 386) in no way
> implies that byte 385 exists, and thus the server should respond in the
> same way rather than issuing an err
On Tue, 9 Jul 2002, David Harris wrote:
> assume we
> have a message with 384 bytes, and the client issues this command:
>A30 FETCH 42 (BODY[TEXT]<385.16384>)
> Am I correct in assuming that the correct return for this command is:
>* 42 FETCH (BODY[TEXT]<385> {0})
Close, but not quite.
T
RFC2060 section 6.4.5 has this text:
-- Cut here
Any partial fetch that attempts to read beyond the
end of the text is truncated as appropriate. A
partial fetch that starts at octet 0 is returned as
a partia
