Subject: [Extra] Benjamin Kaduk's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Fri, 05 Apr 2019 14:05:13 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-extra-imap-fetch-preview-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I wavered a lot about whether this was DISCUSS-worthy, but it seems like
we should at least talk about how big a risk for future confusion there
is:

I'm a little confused by the ABNF for 'capability' in Section 7 -- it
seems to allow for (e.g.) PREVIEW=LAZYV2, but the introduction and
Section 3.1 talk only about *algorithms* in PREVIEW capability responses
(and not modifiers).  Is the intent to have capability tags for
(non-mandatory) priority modifiers?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3.1

   Alternately, the client may explicitly indicate which algorithm(s)
   should be used in a parenthesized list after the PREVIEW attribute
   containing the name of the algorithm.  These algorithms MUST be one

nit: there's potential for misparsing here (e.g., that the PREVIEW
attribute contains the name of the algorithm and the parenthesized list
is after that), so maybe put "after the PREVIEW attribte" in parentheses
or offset by commas.

   of the algorithms identified as supported in the PREVIEW capability
   responses.  [...]

nit: singular/plural mismatch between "these algorithms" and "one of".

Section 7

How much discussion was there about "SHOULD be registered" (as opposed
to "MUST be registered")?

Section 8

side note: This is one of the shortest IANA considerations sections I've
seen thta creates registries (in that it doesn't lay out a registration
template), but IANA seems to be saying they have what information they
need, so who am I to complain...

Section 9

I agree with Roman that there should be discussion of the caching/data
retention strategy for message previews.

This existing text about denial-of-service attacks is probably fine,
though I might consider rephrasing it along the lines of "this mechanism
introduces a new way for clients to make requests that consume server
resources.  As is the case for all such mechanisms, it could be used as
part of a denial-of-service attack on server resources, e.g., via
excessive memory or CPU usage, or increased storage if preview results
are cached on the server after generation.  The additional attack
surface presented by this specific mechanism is not believed to higher
risk that other similar mechanisms in use already, since the individual
resource consumption per message processed is likely to be modest.
Nonetheless, servers MAY limit the resources consumed by preview
generation."

As I write the above, though, I wonder how this interacts with the
previous text in Section 3.1 about how the "server MUST honor a client's
algorithm priority decision".  Does that mean that if some future
(expensive) algorithm is specified, once a server implements that
algorithm, any client can force its use and thus the expensive resource
consumption on the server?  It's not entirely clear to me how this MAY
interacts with that MUST, in such a hypothetical scenario.

---

From: Michael Slusarz <[email-masked]>
Date: Wed, 10 Apr 2019 20:32:11 -0600 (MDT)

Benjamin,

Thank you for the comments.  Disccusion below:

> On April 5, 2019 at 3:05 PM Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 

[Edit: looks like this was discussion item moved to Barry's ballot, but I'll leave the discussion here for clarity in the thread history]

I struggled with the decision to include priority modifier extensions in the draft.

Algorithm extensions make sense, as there can be competing or expanded way of generating preview text in the future.  But priority modifiers are tied to the behavior of the command, not the output of the command.  In the case there would be a need for a priority modifier in the future, that's a fundamental change to the semantics of the command itself and would probably require extensive discussion.

Under further thought and review, I would be perfectly fine with removing the extension/registry for priority modifiers and simply making it an explicit part of the base command.  This would simplify the draft a bit.  Thoughts?

(To answer your original DISCUSS: a separate CAPABILITY string wasn't defined, because it is implicit in PREVIEW=FUZZY, which is required to implement PREVIEW, that LAZY must also be handled.  Not requiring PREVIEW=LAZY, and not defining what a potential capability would look like in the future, were explicit choices.)

Alexey and I discussed in a previous thread, located here:

I think a valid summation is that Alexy was pushing hard for MUST register, but my reading of 6648 is that it allows flexibility in allowing extensions, as long as you follow naming conventions.

My personal example is that there is at least one additional PREVIEW extension we may develop, and which may be implemented quickly, but there is no intention to register that extension (at least at the beginning) because it is a very specific use-case that may not be generally useful to the wider Internet.  So demanding a MUST register to me seems unduly harsh and inflexible.

> retention strategy for message previews.

As mentioned in response to Roman, I worked on this language last week and I will share with the group once I have access to that revision.

> interacts with that MUST, in such a hypothetical scenario.

I don't see this as any different of a problem than with other IMAP commands.  Example: a user issues a SORT/THREAD command in a large mailbox, and that command would require 10,000s of message accesses to return.  An IMAP server should be allowed to abort the response somehow (we will return an unsorted list, for example), subject to some kind of resource limitations, even though the requirements of the command is that it must return a sorted list.

More broadly, any IMAP command should be subject to this kind of truncation if there is concern that completion risks resource starvation as a consequence.  (On that note, I thought there was some sort of "resource limitation" response code defined for this kind of situation, e.g. in RFC 5530, but it looks like there isn't.  Maybe we need something like this).

michael

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 11 Apr 2019 06:29:51 -0400

Hi Michael,

On Thu, Apr 11, 2019, at 3:32 AM, Michael Slusarz wrote:

> More broadly, any IMAP command should be subject to this kind of 
> truncation if there is concern that completion risks resource 
> starvation as a consequence.  (On that note, I thought there was some 
> sort of "resource limitation" response code defined for this kind of 
> situation, e.g. in RFC 5530, but it looks like there isn't.  Maybe we 
> need something like this).

I think we have TEMPFAIL for this: <https://www.iana.org/assignments/imap-response-codes/imap-response-codes.xhtml#imap-response-codes-1>

Best Regards,
Alexey

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 Apr 2019 14:11:03 -0500

> [Edit: looks like this was discussion item moved to Barry's ballot, but I'll leave the discussion here for clarity in the thread history]

[Ok]

> Under further thought and review, I would be perfectly fine with removing the extension/registry for priority modifiers and simply making it an explicit part of the base command.  This would simpli…

That would definitely simplify things (and IIUC remove the concerns here).
I don't want to pressure you or the WG into making that decision, though --
pick what seems best for the technology, and figuring out how to describe
it properly will come pretty easily after that.

> Alexey and I discussed in a previous thread, located here:

(I missed the link, but I don't want to relitigate the question if it was
already covered.)

> My personal example is that there is at least one additional PREVIEW extension we may develop, and which may be implemented quickly, but there is no intention to register that extension (at least a…

With a "standards-track or IESG-approved experimental RFC" registration
policy, that's probably true.  It might be different with a lighter-weight
registration policy like "expert review", though.

> More broadly, any IMAP command should be subject to this kind of truncation if there is concern that completion risks resource starvation as a consequence.  (On that note, I thought there was some…

I'm happy with that answer (and would be happy to see a document with such
a new response code appear).

Thanks,

Ben

---

From: "Chris Newman" <[email-masked]>
Date: Thu, 11 Apr 2019 16:34:23 -0700

On 10 Apr 2019, at 19:32, Michael Slusarz wrote:
> [Edit: looks like this was discussion item moved to Barry's ballot, 
> but I'll leave the discussion here for clarity in the thread history]
>
> Algorithm extensions make sense, as there can be competing or expanded 
> way of generating preview text in the future.  But priority modifiers 
> are tied to the behavior of the command, not the output of the 
> command.  In the case there would be a need for a priority modifier in 
> the future, that's a fundamental change to the semantics of the 
> command itself and would probably require extensive discussion.
>
> Under further thought and review, I would be perfectly fine with 
> removing the extension/registry for priority modifiers and simply 
> making it an explicit part of the base command.  This would simplify 
> the draft a bit.  Thoughts?

As a server implementor, I think that's a good proposal to resolve this 
issue.

		- Chris

> (To answer your original DISCUSS: a separate CAPABILITY string wasn't 
> defined, because it is implicit in PREVIEW=FUZZY, which is required to 
> implement PREVIEW, that LAZY must also be handled.  Not requiring 
> PREVIEW=LAZY, and not defining what a potential capability would look 
> like in the future, were explicit choices.)
>
>
> I think a valid summation is that Alexy was pushing hard for MUST 
> register, but my reading of 6648 is that it allows flexibility in 
> allowing extensions, as long as you follow naming conventions.
>
> My personal example is that there is at least one additional PREVIEW 
> extension we may develop, and which may be implemented quickly, but 
> there is no intention to register that extension (at least at the 
> beginning) because it is a very specific use-case that may not be 
> generally useful to the wider Internet.  So demanding a MUST register 
> to me seems unduly harsh and inflexible.
>
>> Section 9
>>
> As mentioned in response to Roman, I worked on this language last week 
> and I will share with the group once I have access to that revision.
>
> I don't see this as any different of a problem than with other IMAP 
> commands.  Example: a user issues a SORT/THREAD command in a large 
> mailbox, and that command would require 10,000s of message accesses to 
> return.  An IMAP server should be allowed to abort the response 
> somehow (we will return an unsorted list, for example), subject to 
> some kind of resource limitations, even though the requirements of the 
> command is that it must return a sorted list.
>
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=_6NkoEgIENsYMaNoSASPfK2B1zYYYPt9O1NJVWklBGw&s=YRIPXtCQVIlTe3Fk5OkDQMENKX5db8JeL5XXhi7DfAU&e=

---

From: Michael Slusarz <[email-masked]>
Date: Wed, 24 Apr 2019 21:52:19 -0600 (MDT)

> On April 11, 2019 at 4:29 AM Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Michael,
> 

As a bare response code, this seems like the correct answer.  But in RFC 5259, TEMPFAIL is defined as a "transcoding request [that] failed temporarily".  My opinion: I don't think that maps to failing a[ny] IMAP request due to resource constraints.

michael