Re: Fetching short text snippet for mails

On Tuesday, 2 December 2014 17:37:31 CEST, Cyrus Daboo wrote:
> Efficient as in eliminating the current extra round trip of 
> doing a FETCH BODY.PEEK[<section>]<<partial>>?

I don't think a roundtrip would be neccessary.

Sure, the client doesn't know whether it's a single-part text/plain, or if 
it's a multipart/mixed with plaintext and HTML, or whether it's something 
yet different. However, there's principally no problem in issuing a blind 
BODY.PEEK[1] which will "get the right thing" most of the time. One can 
play it extra-safe and ask for a BODY.PEEK[1.1] as well, these are also 
pretty popular and the worst case is wasting a tiny amount of bandwidth. 
It's OK to request a non-existing part in FETCH anyway.

> If so, then I think "SNIPPET" should be an alias for BODY.PEEK[the first 
> significant text section]<<partial>>. i.e., the server does not 
> do anything more than determine the "the first significant text 
> section". The client still gets to use <<partial>> as it could 
> today.

So that proposal would be just about finding a "first text part", and maybe 
returning a small, impementation-defined subset of that. As a client 
author, I don't think that such an extension would provide much added value 
to my users. I can already get "99%" of this with no extensions today.

What I would like much more is something "smarter", even if with an 
implementation-defined exact behavior. Finding a textual part is not 
particularly compelling. It should strip away quotations (and do it 
smartly, ignoring the leading "Hi John," or "On ABC, XYZ wrote" prefixes), 
kill the signature, notice that it's a meeting invitation from Exchange and 
display the subject/note along with time and location, etc.

Of course this cannot possibly be specified by an RFC. What I'm arguing 
against is specifying this extension to only extract a chunk of bytes from 
a first textual part.

An extension which I would like to use would use loose wording such as 
"return a textual preview of the e-mail, using implementation defined 
heuristics for determining the content of the response". The RFC can then 
go ahead and suggest what the typical steps to be performed are.

It would be nice to also have a command which returns back the supported 
features of this convertor/extractor. One could go as far as to maintain a 
IANA list of the capabilities, but that is probably an overkill :). I can 
certainly see a couple of use cases for that, though.

With kind regards,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext