From nobody Sat Jun 1 08:46:32 2019 Return-Path: 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 3997512004F; Sat, 1 Jun 2019 08:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 p-S-dNkoVgK2; Sat, 1 Jun 2019 08:46:20 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A4512007C; Sat, 1 Jun 2019 08:46:20 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id D52AB6A256; Sat, 1 Jun 2019 17:46:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1559403977; bh=msIMAlYas66Xt2BzxzJbLAM+PBu+oiUY+tovez+0Bss=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=AJAkov8jlefgVktPzI9wd6GCNvkSIwwH2rNp9tqO+bfqsIhzxmxwVSNvpBhZqMx6/ 6BB6H74PV8l7mEQ0vz3D3Z04xyoupr1LA4COr/YACg7ZeFMnGZvXm9h6lu5/7fcorN fKxx9s4zvw9zd5fzUdHMVi30UMqT1z9/a19AymDAGHm7EsR38QZ/1dcN49CCPqZAsO lb+LMtuCSRbf9gMdSTm2NtEqyf5tep31sYUN62H1/kOo7pQKuzKAhm6kj89AB9+SZ/ 5UCPwV0g8T4C/e/+85qyssf121VerfGq/Qc4/ELVxOMPZIzjKAVJyxjRQJ6rjzJZaP TOj+cLUKA1Zpg== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id BF0C13C0116; Sat, 1 Jun 2019 17:46:17 +0200 (CEST) Date: Sat, 1 Jun 2019 09:46:17 -0600 (MDT) From: Michael Slusarz Reply-To: Michael Slusarz To: Barry Leiba Cc: The IESG , extra@ietf.org, Bron Gondwana , draft-ietf-extra-imap-fetch-preview@ietf.org Message-ID: <1755746109.39421.1559403977713@appsuite-gw1.open-xchange.com> In-Reply-To: References: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> <1478535427.18024.1554953503900@appsuite.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.2-Rev4 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=michael.slusarz@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFdRf+ABCACjsnzeuEJqUrZHnmyTL0r8JwN0YF6ZS/hgHYx83/dhz2LRgq0bkl5FSYPc6ZY7j7G NqvvPxR4Ri6xfevym91IhdJbQaiJ2B0kWAz+p4H/iXhgZwsYdjFN/c3+MPEjSazCPwASWCDHv2ueCay 0YO2dmw9TnR6rA6GiReQPGumgCZJ4xX8AUBUQftdJOrq/fl1xpYWrsFrTIfBml1x3Q4Mf3+ocH7ZT/u SST2IJTx4a9szQcnrsVHn/Fc2wp4P4FkW87sQFpLND80E5VAwxEdCAtQrhoocUfmh3LyyIncAOIRdw0 aR/1PSgwuj8A2c1W0DRYuzCNaGveugCT6GmbF7qbABEBAAG5AQ0EV1F/4AEIAJ98e4BRvKeJSzSqybD ZzOcphkUy+PlMrhkQkc2m36U01+4E9AtUz3XGNIJE+in9yYKqXbtHJCavOPcFhktVGFvSADKT311ZXq Cx/ibvrWI/DmoBCCIY9iwrutJX08nOoj53wpiNVOuR6vGFJIHO7TNosPcWWsw16LiZIwo9GiU2KseU/ xW0h26ouPbVqVpFX1Tgv+xaCBF8rj4kgoghnvTVG5aEgF+QExOLqx6BmarePKboTFVnMk6NYAwC5TtJ DfpWqa/5vQa8oVAex09elUrN+IQM/tcbMG+tAe5mhjJCke96tdEno29KYjs3Ecl9t1GMcsVAM1k8D8J DJzPCB/cAEQEAAYkBMQQYAQIAGwUCV1F/4AIbDAQLCQgHBhUKCQgLAgUJEswDAAAKCRAH1y6/pl54M6 obB/9AbXRu5SYhYrmTMFGDNqq0BKeoeS1n6cA2rvYRPmmwKSd9/sZG6815X8worSUjPb4r0P/9UoUUy P99BIN0aKc/7baCCV2/00fITrW0sS5Es2xuDuwcRAwwMJX09yMDeCu6M0Y2kn8QjKr1Pu87isoxliQz QDdsYJd9b/iSPFAW+sV7xYlkVcw4XoXYolQTUjNBuWbl6tV6dQN66m6RnCnB1uolFtbZENRiVcHOAdI DmYMjX3UL8cMtqpMyAXe0HTkb1BK2I5m4Kz0thK+beBBLyd6M4bK45zI6L3f5oDOty9o2jAnxlSVdUi ZfBSBypOekOX0bw2w/4XtUoS9emDRk Archived-At: Subject: Re: [Extra] Barry Leiba's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2019 15:46:23 -0000 My comments below. > On May 13, 2019 8:22 PM Barry Leiba wrote: >=20 > =20 > Hi, Michael, > I'm sorry it took me so long to get back to this, and I won't let that > happen again. >=20 > > > ---------------------------------------------------------------------= - > > > DISCUSS: > > > ---------------------------------------------------------------------= - > > > > > > =E2=80=94 Section 3.1 =E2=80=94 > > > > > > I don=E2=80=99t understand =E2=80=9Cthe client=E2=80=99s priority dec= ision=E2=80=9D: what decision is that? > > > And what=E2=80=99s the point of giving the server a list of algorithm= s here, given that > > > they all have to be ones that are supported by the server? Won=E2=80= =99t the server > > > always have to use the first one in the list? If not, please add som= e text > > > explaining what the server does. > > > > Consensus seems to be this section is confusing, or unclear, or unneede= d, or some combination of this three. >=20 > But it's still there and still unexplained in version -05. Let's see > where we can go with it: >=20 > > I'll start with providing a (future) real-world example, and why this > > behavior exists in its present form. Given a hypothetical future > > algorithm "IMAGE" (generate image/jpeg preview if image data exists in > > message), I issue this preview command: > > > > a FETCH 1 (PREVIEW (LAZY=3DIMAGE FUZZY)) > > > > This is asking the server: provide me an image preview of the message, > > but ONLY if 1) the message actually contains image information and 2) > > that image information is already generated or can be generated very > > quickly. Otherwise, fall back to FUZZY generation. >=20 > Hm. That really seems like a contrived example. How would the client > software possibly know whether there's useful information in the > image, or whether the information in the accompanying text is more or > less important? Suppose I have two messages: >=20 > 1. text/plain that basically says nothing; image/jpeg that has a > diagram that explains everything >=20 > 2. text/plain that has the entire real content of the message; > image/jpeg of the senders company logo >=20 > It's pretty clear from that explanation that for message 1 I want some > sort of description of the image and for message 2 I want a preview of > the text. But how would the client software know that, and, > therefore, know what to ask for? Is that what a typical received message looks like? To me, that looks like= the edge case. Seems that a server could figure out (through experience) when image previe= w data should be calculated or ignored. Image size, MIME structure informa= tion, MIME order, etc. could all be used to reach some sort of 95% accuracy= threshold. Maybe that doesn't happen day 1 of implementation, but a compe= titive, reactive server implementation will work on this. The same issue exists for text previews, FWIW. What about a text/plain + t= ext/html alternative message, where text/plain is "Please click on this URL= to view the text part", and the text/html part is empty text (it's a singl= e image link). A server can be programmed to be smart enough to ignore tha= t part re: preview. As written, we allow a server to be given the latitude to figure these kind= of issues out. Closing down that opportunity because it might be a diffic= ult logical problem isn't the right approach from my view. =20 > Apart from that, if we're going to do any sort of text-based preview > of an image, I would think we'd just say that when FUZZY is applied to > an image, that's what it does. FUZZY is explicitly defined as text only output though, since that's genera= lly mapping what clients already do. Defining an algorithm that can potent= ially take any data input and produce any media type output (haha! I've now= learned not to use MIME type anymore!) seems too broad when trying to map = the default behavior with what the vast majority of clients currently do. > > I find that use-case plausible, albeit not something useful given the > > current landscape of a single algorithm. The alternative would be to > > have to send PREVIEW algorithms one at a time, non-pipelined, which is > > precisely the kind of inefficient client/server interaction this > > extension is trying to minimize. >=20 > We disagree on the plausibility. Realistically, I can't think of > *any* other plausible preview algorithms that a *client* might ask for > without user interaction. The most I can see is something about how > to apply FUZZY to non-text media types. Our UI client does "virtual attachment view", that shows graphical represen= tations of all attachment data within messages within a mailbox, so PREVIEW= is perfectly suited for that task. (We currently have to do the preview c= onversion via a proprietary plugin.) I'll agree that it may not be a common use-case, but it is entirely plausib= le. > > I do agree that there is language that can surely be cleaned up here, > > especially regarding error handling. But I will hold off on rewriting > > the section until we can have some discussion/consensus as to whether > > the proposed usage discussed above is something that others believe we > > should be supporting. >=20 > *If* we're going to keep the multi-algorithm syntax, I think the new > paragraph you added has it covered, and the paragraph with the phrase > "priority decision" is now unnecessary. >=20 > But I'd still like to see someone give a good argument for a case > where having a client ask for multiple algorithms to be applied could > really be useful and practical. >=20 > > > =E2=80=94 Section 3.2 =E2=80=94 > > > > > > If the preview is not available, the server MUST return NIL as the > > > PREVIEW response. A NIL response indicates to the client that > > > preview information MAY become available in a future PREVIEW FETCH > > > request. Note that this is semantically different than returning = a > > > zero-length string, which indicates an empty preview. > > > > > > I think the MUST here is hard to follow, because the text doesn=E2=80= =99t make a clear > > > enough distinction between =E2=80=9Cpreview is not available=E2=80=9D= and =E2=80=9Can empty preview=E2=80=9D. > > > Can you expand the text a bit to explain the distinction more clearly= , as this > > > is a protocol requirement? > > > > "Preview not available" examples =3D > > * Preview generation isn't available at the moment (previews are gene= rated in a separate thread, and that pool is saturated) > > * Body text is not available at the moment, so preview can't be gener= ated. > > * The preview text has not been generated within the alotted time (e.= g. LAZY modifier) >=20 > OK, so you're saying that NIL means that there's some transient issue, > and that a non-empty preview might be available later... and an empty > string means that there's no preview text available for this message > and never will be. Yes? Correct. NIL =3D I asked for preview, I don't have that preview cached, and the mess= age blob storage is acting up and taking 5 seconds to return data. As a se= rver, that's beyond my configured limit of requiring a message listing with= in 2 seconds, so the preview is "not available", but not necessarily empty Empty String =3D As a server, I have analyzed the body and there is no data= that I find worthy to display as "preview text" to the user, and this is a= determinative evaluation. Those are two entirely different scenarios (and the former scenario is expe= cted, especially in a distributed storage system). So they absolutely need= to be handled separately. > If that's right (and actually a necessary distinction), I suggest this: >=20 > OLD > If the preview is not available, the server MUST return NIL as the > PREVIEW response. A NIL response indicates to the client that > preview information MAY become available in a future PREVIEW FETCH > request. >=20 > Examples why a preview may not be available include: the preview > generation process is not available due to transient server resource > limitations, the message body text is unavailable, or a server- > imposed timeout was reached during generation. >=20 > A NIL response is semantically different than returning a zero-length > string, which indicates that no meaningful preview text can be > generated for the message. >=20 > NEW > It is possible that preview text is not available now, but might be > available later -- perhaps the server's preview-generating resources > are overloaded, there is a server-imposed timeout during preview > generation, or there is some transient issue with fetching the > message body. In such cases, the server will return NIL as the > preview response, and the client might possibly try again later. >=20 > On the other hand, it's possible that the server has determined that > no meaningful preview text can be generated for a particular > message, and that won't change later. Examples of this involve > encrypted messages, content types the server does not support > previews of, and other situations where the server is not able to > extract information for a preview. In such cases, the server will > return a zero-length string. Clients should not send another FETCH > for a preview for such messages. >=20 > END >=20 > But let's be sure we really think the distinction is important. Thank you for these clarification suggestions. Will adapt them in the next= draft. > > > =E2=80=94 Section 8 =E2=80=94 > > > > > > It seems like a bad idea to have to keep the IMAP Capabilities regist= ry in sync > > > with the two new registries: as it stands, when you add a new algorit= hm you > > > have to add it to the Preview Algorithms registry, and also add a cor= responding > > > entry in the Capabilities registry... and similarly for a modifier, i= f I have > > > that right above. > > > > > > Why not follow the model of AUTH=3D and RIGHTS=3D, and just reserve t= he PREVIEW=3D > > > capability in the registry, allowing it to apply to entries from the = two new > > > registries? That avoids inconsistencies in registrations if we later= add > > > algorithms or modifiers. > > > > See above. With my proposal to remove priority modifiers, I believe th= is discussion > > point becomes moot. >=20 > It does not; it's still an issue with algorithms. If you register > "PREVIEW=3DFUZZY" as a capability string and also register "FUZZY" as an > algorithm, you're doing double registration and are prone to getting > inconsistencies. >=20 > But if, instead, you just register "PREVIEW=3D" as a capability string > and let that stand for any "PREVIEW=3DX", where X is a registered > preview algorithm, you don't get into that sort of trouble. That's > what AUTH=3D and RIGHTS=3D did. Is there a reason not to do that? User error. Combination of reading previous specs wrong, and mistaken idea= s about how this should work. 100% agree with your reasoning. Will clean this up for the next draft. >=20 > > > ---------------------------------------------------------------------= - > > > COMMENT: > > > ---------------------------------------------------------------------= - > > > > > > =E2=80=94 Section 3.2 =E2=80=94 > > > > > > This relaxed requirement permits a > > > server to offer previews as an option without requiring potentiall= y > > > burdensome storage and/or processing requirements to guarantee > > > immutability for a use case that does not require this strictness. > > > > > > That=E2=80=99s sensible, but can you include some text giving an exam= ple of a situation > > > where the preview might change? Given that the messages themselves a= re > > > immutable, why would applying the same algorithm to the same text giv= e > > > different results? > > > > We discussed this on the list in the past, but one example would be > > loss of cached preview data on the server and re-generation uses a > > newer algorithm version which produces slightly different text. > > > > The consensus was that we should not be making extraordinary > > efforts/costs to ensure this text never changes, where this text is not > > being held out as being the canonical view of the message contents in > > the first place. >=20 > That's fine. So, as the first sentence of my comment says, can you > include some text to explain the situation? I'm not looking for a > lot, just a sentence. (If you think it's best not to, that's OK too: > this is a comment, not a discuss point). Fair point. I will address this suggestion. Maybe: "For example, the unde= rlying IMAP server may change for an account due to a software upgrade; acc= ount state information may be retained in the migration, but the new server= may support a different PREVIEW generation algorithm. Thus, message state= may remain the same but PREVIEW FETCH response may change." Traveling, so give me a day or two and I will incorporate above edits, and = discussion points previously raised by Alexey, in the next draft. michael From nobody Sun Jun 2 10:33:33 2019 Return-Path: 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 5598F120161; Sun, 2 Jun 2019 10:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 NxEFzdmOKflR; Sun, 2 Jun 2019 10:33:29 -0700 (PDT) Received: from mail-it1-f182.google.com (mail-it1-f182.google.com [209.85.166.182]) (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 A52C312015B; Sun, 2 Jun 2019 10:33:29 -0700 (PDT) Received: by mail-it1-f182.google.com with SMTP id l21so1865622ita.2; Sun, 02 Jun 2019 10:33:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rAqHyYRRpxO7Uo7V2dVD/ubN7LN6JAUhqGunE5JJ8Q4=; b=tW+AJBm4UPNIzh5EvJu3m9pfzhtI1GGADUbSLG8KoGogsSBoPW6xsk/d4Kes+sboTz DnQWtlUVtY2dXM4qlF71aY1w3EsIT7ZCH0OThH+V+KR1YG1n39Gx4sHMcoaWTXkb0Q3y /wbwCqtthkuloHnuB8d5EY5WUqEmEo71RHx3GlE+H/vh0Ltryv/crFSgm2kuKTQ/Km5u ymJ6tKMv1UlRRtcHQS6tgoKor9uFidR1S7vmysMtk/iTEqtN/QMwLTCRlVeCeIfUVeFY aGvtRUWv2/Pfkplt3Ge+KPIvk3C/1YfEU390VoNo036Deqc1ozME8Ko3q5CwUQ9WTLTG Uurw== X-Gm-Message-State: APjAAAVmZOlImT0I/BDVQMTct74jHKI980dDTWztDi7laWFH3KHeokEK 1O9LFzwOuQAs6XKNRpGfXLom7gSLyzsnPlYXsDw= X-Google-Smtp-Source: APXvYqzdHtQmCzNf1h1oeqZh/aEUn06D+MdnbfQdbvTqxM12uOOWRbK71pWgazuAUjAsLudYX151kxO8pXyVY6HBdqc= X-Received: by 2002:a24:a088:: with SMTP id o130mr13987508ite.86.1559496808490; Sun, 02 Jun 2019 10:33:28 -0700 (PDT) MIME-Version: 1.0 References: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> <1478535427.18024.1554953503900@appsuite.open-xchange.com> <1755746109.39421.1559403977713@appsuite-gw1.open-xchange.com> In-Reply-To: <1755746109.39421.1559403977713@appsuite-gw1.open-xchange.com> From: Barry Leiba Date: Sun, 2 Jun 2019 13:33:17 -0400 Message-ID: To: Michael Slusarz Cc: The IESG , extra@ietf.org, Bron Gondwana , draft-ietf-extra-imap-fetch-preview@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Extra] Barry Leiba's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2019 17:33:31 -0000 I think we're still in significant disagreement here; I'd like others from the working group to comment, and see if that can move us in one direction or the other. > > > I'll start with providing a (future) real-world example, and why this > > > behavior exists in its present form. Given a hypothetical future > > > algorithm "IMAGE" (generate image/jpeg preview if image data exists in > > > message), I issue this preview command: > > > > > > a FETCH 1 (PREVIEW (LAZY=IMAGE FUZZY)) > > > > > > This is asking the server: provide me an image preview of the message, > > > but ONLY if 1) the message actually contains image information and 2) > > > that image information is already generated or can be generated very > > > quickly. Otherwise, fall back to FUZZY generation. > > > > Hm. That really seems like a contrived example. How would the client > > software possibly know whether there's useful information in the > > image, or whether the information in the accompanying text is more or > > less important? Suppose I have two messages: > > > > 1. text/plain that basically says nothing; image/jpeg that has a > > diagram that explains everything > > > > 2. text/plain that has the entire real content of the message; > > image/jpeg of the senders company logo > > > > It's pretty clear from that explanation that for message 1 I want some > > sort of description of the image and for message 2 I want a preview of > > the text. But how would the client software know that, and, > > therefore, know what to ask for? > > Is that what a typical received message looks like? To me, that looks like the edge case. It's not the "typical" message, but I don't think it's an edge case either. I do often get messages where the only significant content is in an image. (I've tried to dissuade those responsible from sending things that way, but they persist.) So, no, I wouldn't call it an "edge case" either. And even if it were, that's not really the point; see below. > Seems that a server could figure out (through experience) when image > preview data should be calculated or ignored. Image size, MIME > structure information, MIME order, etc. could all be used to reach some > sort of 95% accuracy threshold. Maybe that doesn't happen day 1 of > implementation, but a competitive, reactive server implementation will > work on this. > > The same issue exists for text previews, FWIW. What about a text/plain > + text/html alternative message, where text/plain is "Please click on > this URL to view the text part", and the text/html part is empty text > (it's a single image link). A server can be programmed to be smart > enough to ignore that part re: preview. > > As written, we allow a server to be given the latitude to figure these > kind of issues out. Closing down that opportunity because it might be > a difficult logical problem isn't the right approach from my view. I note that in your response you say "server" four times, at least once per paragraph, and "client" never. But my point (see above) was, "But how would the client software know that, and, therefore, know what to ask for?" These are things a *client* is requesting; how does the client know whether to request that the preview be preferentially done on the image or on the text? I contend that it doesn't, and can't, and that, therefore, it's strange to expect it to ask, and strange to say that the server has to take the client's "priority decision" into account. I'm still looking for a real use case where the *client* is the entity that's better suited to asking for any specific action with respect to a message preview. > > Apart from that, if we're going to do any sort of text-based preview > > of an image, I would think we'd just say that when FUZZY is applied to > > an image, that's what it does. > > FUZZY is explicitly defined as text only output though, since that's generally mapping > what clients already do. Well, but saying, "That's the way it works now," isn't really the point. We need to be looking at how we *want* this to work going forward, and I think that having the *server* decide what the best way is to give a preview of a message is the right answer. And if that means that the server decides to make a preview from the text/plain part, the text/html part, the application/pdf part, or the image/jpeg part (perhaps using OCR on the image), then I think that's fine. FUZZY is explicitly defined as text only, only because that's how we've defined it so far. > > > I find that use-case plausible, albeit not something useful given the > > > current landscape of a single algorithm. The alternative would be to > > > have to send PREVIEW algorithms one at a time, non-pipelined, which is > > > precisely the kind of inefficient client/server interaction this > > > extension is trying to minimize. > > > > We disagree on the plausibility. Realistically, I can't think of > > *any* other plausible preview algorithms that a *client* might ask for > > without user interaction. The most I can see is something about how > > to apply FUZZY to non-text media types. > > Our UI client does "virtual attachment view", that shows graphical representations of all > attachment data within messages within a mailbox, so PREVIEW is perfectly suited for > that task. (We currently have to do the preview conversion via a proprietary plugin.) I don't understand this: this extension gives one preview for the message, not separate previews for different message parts. It looks like you're talking about showing a graphic representation of the message structure with each part having a preview. Can you post a screen capture of what you're talking about, showing how PREVIEW helps? > > But I'd still like to see someone give a good argument for a case > > where having a client ask for multiple algorithms to be applied could > > really be useful and practical. This comment of mine still stands. Please, EXTRA working group, join the discussion. Barry From nobody Sun Jun 2 12:23:47 2019 Return-Path: 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 0C61612008F for ; Sun, 2 Jun 2019 12:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no 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 01I2RP-Eo2Zo for ; Sun, 2 Jun 2019 12:23:43 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16A7B120074 for ; Sun, 2 Jun 2019 12:23:42 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 0C2FCC0546; Sun, 2 Jun 2019 20:26:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1559503575; bh=tKS2gdRMiilBeH36069g7MSJHATkUFBXihukVaBm5pA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qgwfZ8WAlHBDbzCKMway1wkzdpY62mMbeMTckj2knt8nXmcHtm5VH3Aw/iEJn2aNE 8jrfyCEmBxnP8+ePMBzZ0iT12gx4vLPNRc2f6hJ1lEaw2TvJz8sAfoNrh/98ZvGV6b jAvAbVcaXUCnboIA65xGEIGPvwKP/yzE1dMTOuEQ= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1559503574-19664-2661/9/5; Sun, 2 Jun 2019 19:26:14 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Sun, 2 Jun 2019 21:23:40 +0200 Mime-Version: 1.0 Message-Id: <91fde3a6-1f27-4848-924d-49d36d9413be@gulbrandsen.priv.no> In-Reply-To: References: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> <1478535427.18024.1554953503900@appsuite.open-xchange.com> <1755746109.39421.1559403977713@appsuite-gw1.open-xchange.com> User-Agent: Trojita/0.7; Qt/5.7.1; xcb; Linux; Devuan GNU/Linux 2.0 (ascii) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Extra] Barry Leiba's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2019 19:23:45 -0000 On Sunday 2 June 2019 19:33:17 CEST, Barry Leiba wrote: > I think we're still in significant disagreement here; I'd like others > from the working group to comment, and see if that can move us in one > direction or the other. My two cents, then: Michael is right. The correct wording, from my point of view, should specify the desired results in one or a few typical cases, suggest that implementations should do much the same in less common cases. Ideally it also contains an appendix might with some common/uncommon test messages _without_ specific results. My reason for this is that exact rules along the lines of e.g. THREAD=REFERENCES haven't been fortunate, while RFCs like FUZZY with more goal and less mechanism haven't led to complaints or calls for revision. Some servers have the knowledge to thread better (e.g. because they had language-specific ways to compute BASESUBJECT, or could thread based on information from Exch^Wnon-822 mail systems) but T=R banned that. On the other hand, FUZZY has let implementers use their platform's abilities, and I haven't noticed interop problems caused by that. Michael mentioned all-image HTML as an example. One of the platforms I know comes with OCR support, the others don't AFAICT. Now, this platform isn't typically a server platform... but I don't see a weighty reason to forbid using OCR for PREVIEW if the software has that available. Arnt From nobody Sun Jun 2 12:24:58 2019 Return-Path: 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 D8C77120074 for ; Sun, 2 Jun 2019 12:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 sFIcuk4JIx8Q for ; Sun, 2 Jun 2019 12:24:55 -0700 (PDT) Received: from fe1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4F66412006E for ; Sun, 2 Jun 2019 12:24:55 -0700 (PDT) Received: (qmail 11555 invoked from network); 2 Jun 2019 19:24:54 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (AES128-SHA encrypted) SMTP (198a90d0-856c-11e9-883a-efe88766a219); Sun, 02 Jun 2019 12:24:54 -0700 To: extra@ietf.org From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <7c3e99b6-ed70-f824-fbf0-bdd940fa3894@linuxmagic.com> Date: Sun, 2 Jun 2019 12:24:54 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: 198a90d0-856c-11e9-883a-efe88766a219 X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: [Extra] Any Further discussions on whether the extra group is expanding to include SMTP items? X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2019 19:24:57 -0000 Still looking for a home for our CLIENTID drafts, recently updated the IMAP draft to include more background and clarity on use cases. And we have been busy contributing patches for various open source clients and servers to support it. Just bringing it up again.. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Sun Jun 2 17:27:56 2019 Return-Path: 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 347EC120119 for ; Sun, 2 Jun 2019 17:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=PnT6wHeY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=d2pS+Qu/ 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 mdbriCZpPOxD for ; Sun, 2 Jun 2019 17:27:52 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF18120116 for ; Sun, 2 Jun 2019 17:27:52 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 630C220D87 for ; Sun, 2 Jun 2019 20:27:51 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sun, 02 Jun 2019 20:27:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=6R14WDB fM+tFcgxmEjbxQXYMEIi26nRVbjqkqWheWxY=; b=PnT6wHeYUdHf1YqIkFnp7gX iIY1mKXScXxMQ5ZjD35ikwzFPbv709F5sPHCYRYgSRZJZyYEvf0MfHke2ydFdUZM 4Syz6JDrRBPkcoUhk6PZ4Pzzi6bYeTxl7b1z3IJdjMcwUBsB2N6KhFzYHOvRrVoN j0Ykc4RPnckzqmEFr9lrpCE0FjgBi/FvtKkKpW0OM59x4XFJXsZbJwosUhs5x6Nu jF98FJ3C00Ehkuw5PEq+GBmQGRpjWYSzPzlBqZGMQxYto97lklg9Vrx7H21HYH5C GcRwzZjzks1d0qd+oo7PnFppVObrwcIXT3Vy4xjD4lN/IeqVksN5K8fn8aWJLeQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=6R14WD BfM+tFcgxmEjbxQXYMEIi26nRVbjqkqWheWxY=; b=d2pS+Qu/oaN3cwZ6qtIVqy eAx3mj+IF9nKDWH52KTbLl876L/hlXmPvMlKSO6Gzr6RnZUXjVowFYWeTHEi6lRi tpM6XWI+R358B6e42mrA2+lKjjqM12Aio7jCuib8PGPyJafSCJIyM9y4kRrhczK4 aEHfrVn6PQINoO1NSHKCsR/KPyGFXGWriaxDXgfAReDHMouNDQgXpW1T4lUc2LCd u/xb9HxepRYDq05ws7lTmKZRYS8Y+J9e03KlyWLbDelpofeGgxMws6R7diEX0Gy3 2g1OSj7tuDKR8xJrLpLN+im+QTWej4Z0QdDB/4a5AUcNfuefFkS/DRfPkaxHVZvg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudefiedgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvg hilhhjsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A285E180091; Sun, 2 Jun 2019 20:27:50 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-555-g49357e1-fmstable-20190528v2 Mime-Version: 1.0 Message-Id: <70781805-f45f-43aa-b71b-a1862a3610bb@beta.fastmail.com> In-Reply-To: References: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> <1478535427.18024.1554953503900@appsuite.open-xchange.com> <1755746109.39421.1559403977713@appsuite-gw1.open-xchange.com> Date: Mon, 03 Jun 2019 10:27:19 +1000 From: "Neil Jenkins" To: extra@ietf.org Content-Type: multipart/alternative; boundary=b734fa22ee5f4f5bbd0ae17d43789a96 Archived-At: Subject: Re: [Extra] =?utf-8?q?Barry_Leiba=27s_Discuss_on_draft-ietf-extra-im?= =?utf-8?q?ap-fetch-preview-03=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 00:27:55 -0000 --b734fa22ee5f4f5bbd0ae17d43789a96 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable I must admit to having skimmed this discussion, but it seems to me that = this extension is getting way over-complicated. The key here is simply t= o answer the question: what is this for? The only purpose of this is to = provide a way for clients to get a snippet of (plain) text to shown in t= he mailbox listing without downloading whole body parts and expecting a = fast response from the server (like fetching common headers). This is a = common feature and worth making more efficient. Trying to do anything el= se is making things more complicated for close to zero benefit. I would contend: * No server is going to implement more than one algorithm. Like with fu= zzy searching, we should not specify the algorithm in the spec. Servers = should be free to implement the best solution they can, which is likely = to change over time as new edge cases are found and new capabilities are= available (for example, skipping salutations, OCRing an image-only body= , skipping broken auto-generated plain text components and generating th= e preview from the text/html version instead, etc.). The server should b= e free to choose which parts it thinks it should use to generate the pre= view. * The client either accepts the server is going to give it a good previ= ew or it will ignore the whole capability and generate its own, at the e= xpense of being slower and more data hungry. * The output is always just plain text. This is what is shown in mailbo= x listings as the preview in Apple Mail, Gmail, FastMail, etc. If you th= ink an image or text/html preview is useful, I disagree, but regardless = that should be a different spec rather than overcomplicating one that so= lves an actual use case today. (To be clear, I think the spec already sa= ys this, but some of the comments in this thread seemed to indicate to m= e people thought you might want different typed outputs in the future). * (Perhaps controversial but=E2=80=A6) If the server offers the capabil= ity it should always have the data readily available, so the LAZY modifi= er is not necessary. I would expect servers that implement this to gener= ally calculate and cache a preview on delivery. If it's going to take a = while, the benefit to the client is much less and it might as well just = calculate its own. That way the client only has two code paths (server-p= review or client-preview) rather than three (server delayed preview as w= ell). In the JMAP Mail spec, we simply specify the following for the equivalen= t property: *preview*: `String` *A plain text fragment of the message body. This is intended to be shown= as a preview line on a mailbox listing, and may be truncated when shown= . The server may choose which part of the message to include in the prev= iew; skipping quoted sections and salutations and collapsing white-space= can result in a more useful preview.** * * * *This MUST NOT be more than 256 characters in length.* Neil. --b734fa22ee5f4f5bbd0ae17d43789a96 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
I must admit to= having skimmed this discussion, but it seems to me that this extension = is getting way over-complicated. The key here is simply to answer the qu= estion: what is this for? The only purpose of this is to provide a way f= or clients to get a snippet of (plain) text to shown in the mailbox list= ing without downloading whole body parts and expecting a fast response f= rom the server (like fetching common headers). This is a common feature = and worth making more efficient. Trying to do anything else is making th= ings more complicated for close to zero benefit.

I would contend:
  • No server is going to implement = more than one algorithm. Like with fuzzy searching, we should not specif= y the algorithm in the spec. Servers should be free to implement the bes= t solution they can, which is likely to change over time as new edge cas= es are found and new capabilities are available (for example, skipping s= alutations, OCRing an image-only body, skipping broken auto-generated pl= ain text components and generating the preview from the text/html versio= n instead, etc.). The server should be free to choose which parts it thi= nks it should use to generate the preview.
  • The client either= accepts the server is going to give it a good preview or it will ignore= the whole capability and generate its own, at the expense of being slow= er and more data hungry.
  • The output is always just plain tex= t. This is what is shown in mailbox listings as the preview in Apple Mai= l, Gmail, FastMail, etc. If you think an image or text/html preview is u= seful, I disagree, but regardless that should be a different spec rather= than overcomplicating one that solves an actual use case today. (To be = clear, I think the spec already says this, but some of the comments in t= his thread seemed to indicate to me people thought you might want differ= ent typed outputs in the future).
  • (Perhaps controversial but= =E2=80=A6) If the server offers the capability it should always have the= data readily available, so the LAZY modifier is not necessary. I would = expect servers that implement this to generally calculate and cache a pr= eview on delivery. If it's going to take a while, the benefit to the cli= ent is much less and it might as well just calculate its own. That way t= he client only has two code paths (server-preview or client-preview) rat= her than three (server delayed preview as well).

<= /div>
In the JMAP Mail spec, we simply specify the following for the= equivalent property:

preview: String
A plain text f= ragment of the message body. This is intended to be shown as a preview l= ine on a mailbox listing, and may be truncated when shown. The server ma= y choose which part of the message to include in the preview; skipping q= uoted sections and salutations and collapsing white-space can result in = a more useful preview.

This MUST NOT be more than 256 characters in length.
=
Neil.
--b734fa22ee5f4f5bbd0ae17d43789a96-- From nobody Mon Jun 3 01:52:11 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FE212011F; Mon, 3 Jun 2019 01:52:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: extra@ietf.org, brong@fastmailteam.com, barryleiba@computer.org, extra-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155955193070.24911.3342816801528365893.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2019 01:52:10 -0700 Archived-At: Subject: [Extra] extra - Not having a session at IETF 105 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 08:52:11 -0000 Bron Gondwana, a chair of the extra working group, indicated that the extra working group does not plan to hold a session at IETF 105. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Mon Jun 17 03:21:31 2019 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE6412013E; Mon, 17 Jun 2019 03:21:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <156076688417.10609.9286450496908059847@ietfa.amsl.com> Date: Mon, 17 Jun 2019 03:21:24 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-quota-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 10:21:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : IMAP QUOTA Extension Author : Alexey Melnikov Filename : draft-ietf-extra-quota-00.txt Pages : 15 Date : 2019-06-17 Abstract: The QUOTA extension of the Internet Message Access Protocol (RFC 3501) permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. This memo obsoletes RFC 2087, but attempts to remain backwards compatible whenever possible. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-quota/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-quota-00 https://datatracker.ietf.org/doc/html/draft-ietf-extra-quota-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 26 07:50:29 2019 Return-Path: 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 77B8712010D; Wed, 26 Jun 2019 07:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 fl5eHbQufFjX; Wed, 26 Jun 2019 07:50:25 -0700 (PDT) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) (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 7FC6412004D; Wed, 26 Jun 2019 07:50:25 -0700 (PDT) Received: by mail-io1-f49.google.com with SMTP id k20so5596822ios.10; Wed, 26 Jun 2019 07:50:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1cRxfUHgC9Ni66CqZw4sawqJTC1UaRKoSaBehxGvdeE=; b=QFV+W/GtDtrsMP68aepepl+22yaMQsHaVhGSjXIkq7TVaHEHkqX9l1l3VczrDiSxjn TKJGug+j6XQgKoOtb9S7Mi84i6iSK8YwdM32wobmwZCATC+egsDGYsdu3gYjy4fnvZxz mIaShdOk92PqiRK5FwAlE0RgFoYgt8gk1pFjnKALjN6nkkTdwIFNXTR6cQ1TolcTJvom HHkuvxL7PQuLXPGuhekLyPw0tDGapP0z6Si2+IVOhL4MpHyFzZiKulu+DwdHtp7MJEa3 QLZfNM3GX/QsP08xxYIDlRkqTv39G1xieOZQpTFA/2wZ2/H7pYiPsFBmyJPWBFpaAlZj sgEw== X-Gm-Message-State: APjAAAUbEgZrcnXl/zcE96eVdcCNuGF2eiQJeYpj2bYCVBHqT7lBkeci V9382O4rhcdjnt+bp3OJFBudkcAQoA/0RXzzWWA/3WS8 X-Google-Smtp-Source: APXvYqwYhJMtqKkZ1O4GyfbS8d/q56U/EnFWTnsqcVU7M6OGOi8OgivF9Cd7FhSkk2CkPdQ+YSZNxL2n8ceQMD3VQ9I= X-Received: by 2002:a6b:fb0f:: with SMTP id h15mr5639834iog.266.1561560624509; Wed, 26 Jun 2019 07:50:24 -0700 (PDT) MIME-Version: 1.0 References: <155469393077.18315.15660535375707491655.idtracker@ietfa.amsl.com> <1478535427.18024.1554953503900@appsuite.open-xchange.com> <1755746109.39421.1559403977713@appsuite-gw1.open-xchange.com> In-Reply-To: From: Barry Leiba Date: Wed, 26 Jun 2019 15:50:13 +0100 Message-ID: To: Michael Slusarz Cc: The IESG , extra@ietf.org, Bron Gondwana , draft-ietf-extra-imap-fetch-preview@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Extra] Barry Leiba's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 14:50:27 -0000 Ping... to both Michael and the EXTRA working group as a whole: Can we keep this discussion moving and get this document resolved, please? Thanks, Barry On Sun, Jun 2, 2019 at 5:33 PM Barry Leiba wrote: > > I think we're still in significant disagreement here; I'd like others > from the working group to comment, and see if that can move us in one > direction or the other. > > > > > I'll start with providing a (future) real-world example, and why this > > > > behavior exists in its present form. Given a hypothetical future > > > > algorithm "IMAGE" (generate image/jpeg preview if image data exists in > > > > message), I issue this preview command: > > > > > > > > a FETCH 1 (PREVIEW (LAZY=IMAGE FUZZY)) > > > > > > > > This is asking the server: provide me an image preview of the message, > > > > but ONLY if 1) the message actually contains image information and 2) > > > > that image information is already generated or can be generated very > > > > quickly. Otherwise, fall back to FUZZY generation. > > > > > > Hm. That really seems like a contrived example. How would the client > > > software possibly know whether there's useful information in the > > > image, or whether the information in the accompanying text is more or > > > less important? Suppose I have two messages: > > > > > > 1. text/plain that basically says nothing; image/jpeg that has a > > > diagram that explains everything > > > > > > 2. text/plain that has the entire real content of the message; > > > image/jpeg of the senders company logo > > > > > > It's pretty clear from that explanation that for message 1 I want some > > > sort of description of the image and for message 2 I want a preview of > > > the text. But how would the client software know that, and, > > > therefore, know what to ask for? > > > > Is that what a typical received message looks like? To me, that looks like the edge case. > > It's not the "typical" message, but I don't think it's an edge case > either. I do often get messages where the only significant content is > in an image. (I've tried to dissuade those responsible from sending > things that way, but they persist.) So, no, I wouldn't call it an > "edge case" either. And even if it were, that's not really the point; > see below. > > > Seems that a server could figure out (through experience) when image > > preview data should be calculated or ignored. Image size, MIME > > structure information, MIME order, etc. could all be used to reach some > > sort of 95% accuracy threshold. Maybe that doesn't happen day 1 of > > implementation, but a competitive, reactive server implementation will > > work on this. > > > > The same issue exists for text previews, FWIW. What about a text/plain > > + text/html alternative message, where text/plain is "Please click on > > this URL to view the text part", and the text/html part is empty text > > (it's a single image link). A server can be programmed to be smart > > enough to ignore that part re: preview. > > > > As written, we allow a server to be given the latitude to figure these > > kind of issues out. Closing down that opportunity because it might be > > a difficult logical problem isn't the right approach from my view. > > I note that in your response you say "server" four times, at least > once per paragraph, and "client" never. But my point (see above) was, > "But how would the client software know that, and, therefore, know > what to ask for?" These are things a *client* is requesting; how does > the client know whether to request that the preview be preferentially > done on the image or on the text? I contend that it doesn't, and > can't, and that, therefore, it's strange to expect it to ask, and > strange to say that the server has to take the client's "priority > decision" into account. > > I'm still looking for a real use case where the *client* is the entity > that's better suited to asking for any specific action with respect to > a message preview. > > > > Apart from that, if we're going to do any sort of text-based preview > > > of an image, I would think we'd just say that when FUZZY is applied to > > > an image, that's what it does. > > > > FUZZY is explicitly defined as text only output though, since that's generally mapping > > what clients already do. > > Well, but saying, "That's the way it works now," isn't really the > point. We need to be looking at how we *want* this to work going > forward, and I think that having the *server* decide what the best way > is to give a preview of a message is the right answer. And if that > means that the server decides to make a preview from the text/plain > part, the text/html part, the application/pdf part, or the image/jpeg > part (perhaps using OCR on the image), then I think that's fine. > FUZZY is explicitly defined as text only, only because that's how > we've defined it so far. > > > > > I find that use-case plausible, albeit not something useful given the > > > > current landscape of a single algorithm. The alternative would be to > > > > have to send PREVIEW algorithms one at a time, non-pipelined, which is > > > > precisely the kind of inefficient client/server interaction this > > > > extension is trying to minimize. > > > > > > We disagree on the plausibility. Realistically, I can't think of > > > *any* other plausible preview algorithms that a *client* might ask for > > > without user interaction. The most I can see is something about how > > > to apply FUZZY to non-text media types. > > > > Our UI client does "virtual attachment view", that shows graphical representations of all > > attachment data within messages within a mailbox, so PREVIEW is perfectly suited for > > that task. (We currently have to do the preview conversion via a proprietary plugin.) > > I don't understand this: this extension gives one preview for the > message, not separate previews for different message parts. It looks > like you're talking about showing a graphic representation of the > message structure with each part having a preview. Can you post a > screen capture of what you're talking about, showing how PREVIEW > helps? > > > > But I'd still like to see someone give a good argument for a case > > > where having a client ask for multiple algorithms to be applied could > > > really be useful and practical. > > This comment of mine still stands. Please, EXTRA working group, join > the discussion. > > Barry