Thanks for the clarifications. Much of that wasn't clear from the spec.
And just to confirm, a server should never return "NIL" for a BODY
content, even if I attempt to read way past the end of the content,
correct? At least, as long as the message exists. It might return
NIL if the message has been expunged, right?
Timo Sirainen wrote on 05/12/2012 01:42 AM:
> On 12.5.2012, at 10.21, Bill Shannon wrote:
>
>> The spec says of a FETCH BODY request:
>>
>> 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 partial fetch, even if this
>> truncation happened.
>
> This is mainly about how the server is supposed to reply to it, i.e. it should still give BODY[]<0> reply instead of BODY[]. All partial replies may be truncated, this just tries to clarify that offset=0 shouldn't be treated as a special case.
>
>> The spec says of a FETCH BODY response:
>>
>> If the origin octet is specified, this string is a substring of
>> the entire body contents, starting at that origin octet. This
>> means that BODY[]<0> MAY be truncated, but BODY[] is NEVER
>> truncated.
>
> This is an instruction for client implementors about what they may assume about the replies.
>
>> It's not clear whether the truncation being talked about is the same in
>> both cases. If it were only allowed to truncate the response at the end
>> of the data, "BODY[]" would be allowed to be truncated as well, so it
>> seems that it must be talking about truncation for some other reason.
>
> Truncation means that a partial fetch ended before the requested number of bytes. BODY[] always requests all bytes.
>
>> If I do "FETCH 2 (BODY[]<0.16384>)" and the server responds
>> "2 FETCH (BODY[]<0> {2817}", can I assume that that's the end
>> of the data or not?
>
> If the client remembers that it fetched 16384 bytes (or anything more than 2817 bytes) it can assume it's at end of data.
>
>> What if I request "FETCH 2 (BODY[]<16384.16384>)" and the response is
>> "2 FETCH (BODY[]<16384> {2817}"? Is that a different case than above,
>> since the request doesn't start at octet 0?
>
> If this was the same mail as above then the server's reply would be an empty string. But assuming a different mail then the message's size can be assumed to be 19201 bytes.
>
>> If I do "FETCH 2 (BODY[]<2817.16384>)" and the server responds
>> "2 FETCH (BODY[]<2817> {0}" I know I'm at the end of the data.
>
> Yes. The reply may also be "" instead of {0}.
>
>> Is
>> "2 FETCH (BODY[]<2817> NIL)" semantically equivalent? The spec says:
>>
>> ... If the starting octet is beyond
>> the end of the text, an empty string is returned.
>>
>> Is "NIL" equivalent to an empty string in this case?
>
> No.
>
>> It would appear not,
>> according to this part of the spec:
>>
>> The special form "NIL" represents the non-existence of a particular
>> data item that is represented as a string or parenthesized list, as
>> distinct from the empty string "" or the empty parenthesized list ().
>>
>> Even though the syntax specifies "nstring", is "NIL" a valid response
>> in this case?
>
> A well behaving server should never return NIL to any replies. But many servers do if the fetched message has already been expunged by another session.