On 5/8/2014 3:21 AM, Dionysios Kalofonos wrote:
> On 5/7/14, 10:14 PM, Ray Satiro wrote:
>> I'll probably keep issuing custom commands because of my requirements.
>> With a regular SEARCH I can't get exactly what I want but that's my
>> problem. If you're going to make changes to FETCH may I suggest it would
>> be helpful if a result even of a custom FETCH were recognized and didn't
>> have to be parsed from the header (which maybe is what you are thinking
>> about implementing?). For example "FETCH 1 BODY[TEXT]" the actual bytes
>> returned would be in the body (what curl recognizes as the body).
>
> Let me list some commands/responses to help ourselves reach a conclusion.

I was thinking of responses which contain string literals according to
the RFC so they have the braces and then some bytes. I think it would be
intuitive if any response that returns a command that includes a literal
that that data is at least part of the body. Right now here is what I
get for header and body using curl 7.34.0:

FETCH 5 BODY.PEEK[HEADER.FIELDS (SUBJECT)]
--------------
* Connection #0 to host imap.gmail.com left intact
HTTP CODE: 0
0 KB/sec ( 0 bytes in 0 seconds )
URL retrieved.

Header:
* 5 FETCH (BODY[HEADER.FIELDS (SUBJECT)] {30}
Subject: test 123 test 456

)
A005 OK Success

Body:
* 5 FETCH (BODY[HEADER.FIELDS (SUBJECT)] {30}
--------------

I don't know what the returned header should be, because it could all be
considered header. But what goes into the body it seems to me should at
least include "Subject: test 123 test 456\r\n\r\n". It doesn't make
sense to leave that out.

Your examples raise a good point, I hadn't really considered all the
combinations until I read your e-mail and then looked at RFC 3501.

> FETCH 1 UID
> * 1 FETCH (UID 1)
>
> FETCH 1 ALL
> * 1 FETCH (FLAGS (\Seen)
> INTERNALDATE "04-Dec-2012 07:23:55 +0000"
> RFC822.SIZE 955
> ENVELOPE ("Mon, 3 Dec 2012 23:23:55 -0800 (PST)"
> "Welcome to Yahoo!"
> (("Yahoo!" NIL "noreply" "yahoo-inc.com"))
> (("Yahoo!" NIL "noreply" "yahoo-inc.com"))
> (("Yahoo!" NIL "noreply" "yahoo-inc.com"))
> ((NIL NIL "example" "yahoo.com"))
> NIL
> NIL
> NIL
> NIL))

It seems to me the body is at least everything in parentheses \\*
[^(]*\(((?:.|\r|\n)*)\) if not the whole thing.

> We could return only the response of a FETCH, ie. whatever is within
> the outer brackets. Equivalently, we could return only the results of
> the remaining IMAP commands for example
>
> SEARCH 1:*
> 1 2 3 4 5 6 7 8 9 10 11 12
>
> instead of
> * SEARCH 1 2 3 4 5 6 7 8 9 10 11 12

It seems to me that * SEARCH 1, etc is part of the result and therefore
part of the body. Unless you are going to parse the result for the body,
and I think that is the crux of the issue. It's probably best to do
whatever is most consistent and intuitive, taking backward compatibility
into account.

>
> But then again we have SELECT/EXAMINE which return
> * 12 EXISTS
> * 0 RECENT
> * OK [UIDVALIDITY 1354605835] UIDs valid
> * OK [UIDNEXT 2248] Predicted next UID
> * FLAGS (\Answered \Deleted \Draft \Flagged \Seen $Forwarded $Junk
> $NotJunk)
> * OK [PERMANENTFLAGS ()] No permanent flags permitted
> * OK [HIGHESTMODSEQ 6010850161961900152]
>
> What do we do with that? :)

That also depends on what you guys consider part of the body and whether
body is parsed data or raw data. I wouldn't expect curl to parse that
for me.

Thanks

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-05-09