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

Stuart Brandt <stujenerin@aol.com> Sun, 11 November 2018 23:38 UTC

Return-Path: <stujenerin@aol.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C44130E2F for <extra@ietfa.amsl.com>; Sun, 11 Nov 2018 15:38:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id by2gKW6dsOUF for <extra@ietfa.amsl.com>; Sun, 11 Nov 2018 15:38:26 -0800 (PST)
Received: from sonic313-14.consmr.mail.bf2.yahoo.com (sonic313-14.consmr.mail.bf2.yahoo.com [74.6.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F23E130E48 for <extra@ietf.org>; Sun, 11 Nov 2018 15:38:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1541979504; bh=+ALhwEY+bgOv+d703S4aaagvieDCsymfHY1DipvTnk8=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=F/wAWylpaSqBJ1DHF+04G13LdqRq5yXQVFzK7EMpt8XvLXScmFvSbbOl1L+1vguV5dS7gjcqyxc5R3WxbdPNqIN16CU7m58j9iWVtOiL/Vo8sg3QpkrXM1fe8uC8kHH9i35jim5d1shXKGHop3ijIfjj2sFWFnn6kKpYqexhtSGddzgN9WnrmOrg6yrCBomWD8sKSy8JSr9l2pIsrYgCQvDV2pXngoZ/mXbSiYn6QySAbP5GkZl+vJ39nRXgXPLRtGrZqtwXJ4GtKwd/7DSUNI52vupv9ZNPtkL9tdvjadoPRZct4Akpkbe9WJsPKoQlA+GK3hOKtxk8ark/UgcGGg==
X-YMail-OSG: XYo5hdkVM1lxQNttsD4An9m0ywv0aJMwRBufGGT.DIyu6rGdoMI0Vlw97Uoh3nY fp10wE4jYCiU7KBhWl6aGMkuuHW9qffTMkprX1neLkHplBzRsKRSvmPtOl5EX6hyxJ2gEqKWbRc3 NkbKl.uwEpGQLfaTZBIG.zSpfIErg_iHRG6HoiY8eQMqwWp.HK1a2EtCUzM4aB0FkbxX6SZtUum3 qCiqE_0Yf8HdBlGxuW0XWdyzQUlL.0hYJvWC7TcEpebsjBB8NPkM2jr1vlr6JJT0qutH9ac.6BkO w9vugsUFdgFu.7wx0PcMzfIdOD3GZnm8GCQt9VsRKMJJ887wnLT6y5OVkGuZBfcTxHc068WKNQ0h CCndPs8bFEiQfuLxyoLwjxyLH0sy.In52mpKdK9bdedMsIl7sHVC.6UPmlDNc2PR6N37wZZOojM3 dzSXZNiVG1Bpj6H5syswKSf7cEerQuO9kGW6ur20qoOtoYY.HkUi3.VzC77B05EhFRqkKsl1h8E1 xKqyzqQYyAGDXxKRkxftSF5mbfqDblj1eWsHBNBu6aIKDYF6oIk.qrHVhUxpqsvSPGiH4CXzcJ5o OVN_TLOypOy6lgQdmqaz6y9dBtnz2t7L8ETnvhtRb.nVnwbBB4xsdmdfqclRbvkNAQz4ZWfQ1iwC vQYZb2N0GhQRwyQi_5fHQtcrqLnDYYmpycduz_Pvx8fcDuiJRH61LFhbVc0vjPaEjpoAjXp3TSUV B6F4nk3bNlYmiIdw6H6WXzLAj1CSq.qEaHgBrEEHmXlKaopz0o.mpBqxob.9AT2Yqtc7e9pzXsD. ldQYTz7MAiXSCNPikydHJuG1sMxfKEKJufrmAjmRAofeytCvz3WHsA0Vi0JnJpAya5PN1jlTYJq. pev37Yvb37y2RR39i1_b828fi0vxNNLMuoupnUWWAIUOw8LFebnVc.ADM.m05qFdOPEd_eCpEWn7 7Cxow6LBpfs31SdBjtilRDW0LvNNio_VUog2_Z44l3vDIizep5TzcNha3JVaGhUHUMARNrbpjtkg wPL1SPvTXqH_W
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Sun, 11 Nov 2018 23:38:24 +0000
Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp420.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1736d2dd96a40834d5c0c8274cbd514f for <extra@ietf.org>; Sun, 11 Nov 2018 23:38:23 +0000 (UTC)
To: extra@ietf.org
References: <222011778.12006.1541435419815@appsuite.open-xchange.com> <c877cb70-125a-4494-8d42-56c91b6e0bc0@sloti7d1t02> <5BE4D9CA.2040809@aol.com> <CABa8R6uNy9vtnvkozaFk0emvNw6CWLWT4gp+RpLUE7fsuKDVjw@mail.gmail.com> <9CA9D1B7-CB4B-4D8B-8A53-B92E815F690F@iki.fi> <c1e4fae9-7b3a-4945-a176-bf6c481e27ae@sloti7d1t02>
From: Stuart Brandt <stujenerin@aol.com>
Message-ID: <5BE8BD67.3060507@aol.com>
Date: Sun, 11 Nov 2018 18:38:15 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <c1e4fae9-7b3a-4945-a176-bf6c481e27ae@sloti7d1t02>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/XZdJPBbrhmAMSJXkRcgudyE2klg>
Subject: Re: [Extra] SNIPPET (now PREVIEW) draft update
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Nov 2018 23:38:36 -0000

If this is the case, then it might be best to include some level of 
recommendation in the draft that clients *not* make an effort to stay up 
to date with any changes that the server might make. I sure would hate 
to see <tag> FETCH 1:* (FLAGS) become <tag> FETCH 1:* (FLAGS PREVIEW), 
adding up to 255bytes per item to the FETCH response just because 
PREVIEW *might* change.

- Stu

On 11/10/2018 12:15 AM, Bron Gondwana wrote:
> That's my attitude to previews too, they don't "change" but they might
> not be byte identical if fetched again later due to changing server
> algorithms. The old value is never "wrong" though, short of buggy servers.
>
> Bron.
>
> On Sat, 10 Nov 2018, at 13:14, Timo Sirainen wrote:
>> 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
>>> <mailto: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
>>>     >>
>>>     >
>>>     > --
>>>     >    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
>>>     >
>>>
>>>     _______________________________________________
>>>     Extra mailing list
>>>     Extra@ietf.org <mailto:Extra@ietf.org>
>>>     https://www.ietf.org/mailman/listinfo/extra
>>>
>>> _______________________________________________
>>> Extra mailing list
>>> Extra@ietf.org <mailto:Extra@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/extra
>>
>> _______________________________________________
>> Extra mailing list
>> Extra@ietf.org
>> https://www.ietf.org/mailman/listinfo/extra
>>
>
> --
>    Bron Gondwana, CEO, FastMail Pty Ltd
>    brong@fastmailteam.com
>
>
>
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra
>