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
