Re: IMAP SNIPPET extension (initial draft)

On 6 May 2015 20:35, "Michael M Slusarz" <[email protected]> wrote:
>
> 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.

A server could use preferences set externally. Doesn't seem like must
territory to me.

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

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