Re: IMAP SNIPPET extension (initial draft)

Quoting Cyrus Daboo <[email protected]>:

> --On May 3, 2015 at 11:56:25 PM -0600 Michael M Slusarz  
> <[email protected]> wrote:
>
>> But hopefully this is a decent enough starting point where it can be used
>> to continue the discussion going forward.
>
> The spec should state somewhere that if the server is unable to  
> extract a suitable snippet (e.g., message is encrypted, contains  
> only an image), then it returns NIL in the FETCH SNIPPET response.

Cyrus,

Thanks for the pointer.  I probably reminded myself five times to put  
explicit NIL return language in the server response part and,  
naturally, never did so.  I've added this language to the next draft.

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.

In the interest of keeping the base specification as minimal as  
possible, I stuck with a single fuzzy algorithm.  In light of the  
above, maybe it makes sense to define an additional base algorithm to  
indicate to the server that it MAY try to create a dynamic snippet  
based on the entire content/structure of the message.

In other words, define both a FUZZYTEXT and a FUZZY algorithm where  
the former requests the server to limit snippet responses to message  
body text only while the latter allows the server to generate dynamic  
descriptions.  I would think that FUZZYTEXT would have to be the only  
MUST implement, as FUZZY starts becoming more involved when it comes  
to implementation details as it will require interaction with the  
LANGUAGE extension in order to allow for translatable snippets.

michael

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