Re: IMAP SNIPPET extension (initial draft)
Michael M Slusarz <[email protected]>
| Newsgroups | gmane.ietf.imapext |
|---|---|
| Message-ID | <20150506133543.Horde.XoqNpGjwdRJe2q1r1Xu5LbQ@bigworm.curecanti.org> |
Quoting Cyrus Daboo <[email protected]>: > Hi Michael, > > --On May 6, 2015 at 1:11:06 PM -0600 Michael M Slusarz > <[email protected]> wrote: > >> As for your examples as when a server cannot extract a suitable snippet: >> those are actually great use cases as to why an extensible SNIPPET >> extension is useful. As someone had mentioned in the initial >> conversation on the topic (apologies that I don't remember who brought >> the topic up), it may be useful to have a server generate a snippet like >> >> - "This message contains 2 images" >> - "This message contains 1 image (X KB)" >> - "This message contains encrypted content" >> - "[This message contains 2 attachments] <...Snippet text of initial >> body part...>" >> >> rather than display actual textual content of any single message body. > > Well that gets tricky because really those strings would need to be > localized. Perhaps the LANGUAGE extension (RFC5255) could be > leveraged for that. Yup. That's what I mentioned it later in that message :) If that algorithm was to be implemented, I would think that it almost becomes a MUST requirement that dynamically generated text only be created if the client has explicitly set a language via the LANGUAGE command. Otherwise the only sane response is to use the actual body content. michael _______________________________________________ imapext mailing list [email protected] https://www.ietf.org/mailman/listinfo/imapext