Re: [Extra] SNIPPET (now PREVIEW) draft update

I think from IMAP protocol purity point of view it would be nice if we didn't have fields that could suddenly change without any indication. But from a practical point of view: Who cares, really? The previews are mainly intended for clients that don't have a local cache. Even if we implemented modseq changes for previews, would any client (that has more than a couple of users) ever really use them? I find it doubtful. More likely these additional requirements would make it more difficult for servers to implement this feature, so the clients wouldn't have it at all.

> On 9 Nov 2018, at 21.14, Brandon Long <blong=40google.com@dmarc.ietf.org> wrote:
> 
> Do we think this is likely to be used for full-sync clients?  Theoretically, those could just generate their own snippets locally from the rest of the data.
> 
> For online clients, the preview would just be part of what they download to display the message list.
> 
> Without QRESYNC, we still have some ugly polling, though obviously PREVEIWS are larger than UIDs.
> 
> OTOH, I feel we already have part of this type of problem today, where improvements to our parsers or encoding detection might change our response to any
> given message based request, but obviously we won't rev the UIDVALIDITY folders on every bi-weekly release when its only ever going to affect a small number of messages.
> 
> Brandon
> 
> On Thu, Nov 8, 2018 at 4:52 PM Stuart Brandt <stujenerin=40aol.com@dmarc.ietf..org <mailto:40aol.com@dmarc.ietf.org>> wrote:
> I know I brought this up years ago, but I'm not sure I ever saw solid 
> resolution. If, as proposed, the Preview is mutable, then are we not 
> addressing how to efficiently identify and sync changes that might have 
> been made to it? If I were a client dev, I'd want to have the most 
> recent Preview for a message because a new version likely means:
> a) server fixed a defective preview
> b) server improved preview's value-to-user
> 
> Mutable data without an efficient way to sync leads to ugly polling.
> 
> - Stu
> 
> On 11/8/2018 7:03 AM, Bron Gondwana wrote:
> > Hi Michael,
> >
> > Thanks again for submitting this, and apologies that I haven't done a
> > thorough review yet - it's on my todo list and I expect to do so soon.
> >
> > The ONLY remaining question was length.  200 is good, but JMAP says 255
> > and consistency will make it better.  Unless you have a strong reason to
> > lock it down to 200, would you consider changing it to "no more than 255
> > octets" with an understanding that there's no requirement that servers
> > have to store that much, just that clients must be willing to accept
> > that much.  That will keep everything consistent.
> >
> > Other than this, we believe we're ready to take this document to working
> > group last call, which I intend to do once I've heard back from you -
> > it's easy to fix this up during last call.
> >
> > Thanks for your work and for getting us the update in time for this meeting.
> >
> > Cheers,
> >
> > Bron.
> >
> > On Tue, Nov 6, 2018, at 03:30, Michael Slusarz wrote:
> >> I've submitted an update to the (formerly snippet, now) preview draft
> >> incorporating feedback received from this list and other implementers.
> >>
> >> Main change is the name - this is now "PREVIEW" instead of "SNIPPET".
> >> Also, increased recommended preview size to 200 characters
> >> (previously: 100).
> >>
> >> Will not be able to remotely join IETF 103 meeting as I am traveling,
> >> but wanted to make sure this draft was updated before then.
> >>
> >> michael
> >>
> >> _______________________________________________
> >> Extra mailing list
> >> Extra@ietf.org <mailto:Extra@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/extra <https://www.ietf.org/mailman/listinfo/extra>
> >>
> >
> > --
> >    Bron Gondwana, CEO, FastMail Pty Ltd
> >    brong@fastmailteam.com <mailto:brong@fastmailteam.com>
> >
> >
> >
> >
> > _______________________________________________
> > Extra mailing list
> > Extra@ietf.org <mailto:Extra@ietf.org>
> > https://www.ietf.org/mailman/listinfo/extra <https://www.ietf.org/mailman/listinfo/extra>
> >
> 
> _______________________________________________
> Extra mailing list
> Extra@ietf.org <mailto:Extra@ietf.org>
> https://www.ietf.org/mailman/listinfo/extra <https://www.ietf.org/mailman/listinfo/extra>
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra