Re: [Extra] Discussing SNIPPET

["Chris Newman" <[e-mail]>]

On 17 Sep 2018, at 4:52, Bron Gondwana wrote:
> Hi All,
>
> I've just posted REPLACE off for publication after the expiry of the 
> WGLC period and confirming the IPR status.
>
> In terms of the remaining documents, we have a couple of Sieve docs 
> which Jiankang is busy Shepherding through their last calls, we have 
> 64bit which we allowed to lapse (for now) and we have imap4rev2 which 
> is a giant piece of work.
>  Finally, we have the recently adopted 
> draft-ietf-extra-imap-fetch-snippet-00.
>
> To summarise the discussion:
>
> 1) there's nobody who thinks this is a bad idea
> 2) there's general agreement that specifying an exact algorithm is bad
> 3) while LAZY may or may not be that valuable, nobody minds it that 
> much. Easy approach is to always generate regardless of the modifier.

+1.

> So much for the things everyone agreed on (please correct me if I 
> missed anything!) Here's the issues under debate:
>
> a) Naming. The great difficulties, naming and cache invalidation! (and 
> yep, we've got the second one too). Should it be called SNIPPET, or 
> something else like PREVIEW? I'm asking largely because JMAP used 
> "SearchSnippet" to refer to a fragment of matching text with terms 
> hilighted. And JMAP used "preview" for the short piece of text (up to 
> 256 characters) that represents the email content.

I strongly feel that JMAP and IMAP should use consistent terminology 
when possible. Although the term 'snippet' is cute, the term 'preview' 
is more technically accurate for the desired functionality, particularly 
when producing a fuzzy preview for an image-only message (in which case 
the dictionary definition of 'snippet' is not what's desired). So I have 
a mild preference for changing SNIPPET to match JMAP terminology.

> b) Cache Invalidation. Ho hum. Is this an immutable property? If so, 
> what happens if the server implementation changes? I'm quite happy to 
> call it "softly immutable" myself - it might not be exactly the same 
> bytes, but you can use the old version without major problems.

The 'softly immutable' option works for me. However, I'll propose an 
alternative so we can contrast two reasonable options. We could add a 
way to fetch a FUZZY algorithm identifier for a given folder. Something 
like:

C: A043 STATUS blurdybloop (FUZZYALG)
S: * STATUS blurdybloop (FUZZYALG ("ocms:8.0"))

A cached PREVIEW=FUZZY (SNIPPET=FUZZY) from that folder is immutable 
unless the FUZZYALG string changes. This has some non-trivial server 
implications, but if clients really need predictable PREVIEW caching 
behavior, this is a protocol model I'd be willing to implement to 
provide that.

> c) Length:
>    The server SHOULD limit the length of the snippet text to 100
>    characters.  The server MUST NOT output snippet text longer than 
> 200
>    characters.
>
> I would prefer to bring this up to more like 200 for should and 256 
> for MUST NOT. 100 is a pretty short preview on big screens. I'd also 
> be willing to have a way for the client to hint for shorter previews 
> to save network bandwidth, but have servers generally store 256 chars. 
> The syntax makes it quite easy to add a MAXLEN=80 or whatever to the 
> fetch command.

No opinions here. Also easy for me to implement, but only useful if 
client implementers use it.

		- Chris

> And yes, this would be trivial to implement in our server with its 
> existing previews, and I would totally do it during last call :)
>  Bron.
>
>
> -- 
>  Bron Gondwana, CEO, FastMail Pty Ltd
>  [e-mail]


> _______________________________________________
> Extra mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=Bzf8nG-Anmd7ybQFCYQd_kA5QfrsUFDlskrm11eWwSY&s=HOeED7FM1BpaoYj0D522AM5_Ke2XpfLSYfjTUoqhrPc&e=