Re: [Extra] AD Review of draft-ietf-extra-imap4rev2

[Alexey Melnikov <[e-mail]>]

Hi Murray,

On 04/01/2021 17:21, Murray S. Kucherawy wrote:
> On Mon, Jan 4, 2021 at 6:05 AM Alexey Melnikov 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>>
>>     Section 2.2.1
>>
>>       Clients MUST follow the syntax outlined in this specification
>>
>>        strictly.  It is a syntax error to send a command with missing or
>>
>>        extraneous spaces or arguments.
>>
>>
>>     It seems unnecessary to say this in a standards track document. 
>>     There’s a similar paragraph in Section 2.2.2.
>>
>     I think the text is there due to various bugs in implementations,
>     so I would rather keep it as is.
>
> I would use "need to" instead of "MUST" here.  It's otherwise a bit 
> hand-wavy for use of BCP 14 language.  But I'll leave this to the WG.
Barry replied to this and I think you are Ok with MUST staying as is.
>
>>     Section 2.2.2
>>
>>        In the case of certain server data, the data MUST be recorded.
>>
>>
>>     This seems misplaced; the MUST should be in the descriptions for
>>     the specific cases where this requirement exists.
>>
>     I think this text is actually Ok where it is, as it warns/requires
>     the client to implement proper cashing. It is more a statement of
>     intent.
>
>     If you think use of RFC 2119 language here is not right, we can
>     discuss that.
>
> Similar to the previous case, I suggest "needs to" here, and then 
> wherever you talk about certain server data, that's where the BCP 14 
> language should go.
The latter would be difficult, because there are several responses like 
EXISTS and EXPUNGE that needs to be remembered by clients, but this list 
is not exhaustive.
>
> I also didn't think you meant caching when you said "recorded"; I took 
> that to refer to logging.  Possibly something else to clarify.

So this paragraph says:

    Server data SHOULD
    be recorded, so that the client can reference its recorded copy
    rather than sending a command to the server to request the data.  In
    the case of certain server data, the data MUST be recorded.

I think caching is intended here. Is "remembered" better that "recorded" 
above?

>>
>>     The text surrounding $Phishing goes further into human factors
>>     work than other working groups have felt appropriate.  (DKIM and
>>     DMARC come to mind.)  Are we sure that belongs here?
>>
>     Yes, considering this is a security consideration, a good example
>     of UI is necessary here.
>
>
> I'm curious to see if anyone else raises this given how much energy 
> those other WGs used in the past to resist providing any UI advice at all.
There are obvious counter examples in recent history, like TLS and OAUTH WG.

>>     Should this section mention whether the system flags are
>>     permanent?  \Seen, for example, is clearly a system flag, but it
>>     could also be a session flag.
>>
>     No, implementations differ and sometimes even \Seen is not
>     permanent. (The last sentence of the first paragraph already says
>     "A flag of either type can also be permanent or session-only.")
>
> Yep, that's what caused me to make the comment.
Basically I don't think we can say anything useful about system flags in 
this respect. They may or may not be permanent, same as keywords. So I 
think no change for this one.
>
>
>>     Section 2.3.3
>>
>>
>>     All the SHOULDs in here make me wonder when an implementor might
>>     legitimately choose to do something different.  Or maybe instead
>>     of “SHOULD be”, just say “is”?
>>
>     I think for delivery by SMTP, I agree. For COPY/MOVE there is
>     actually a posibility that some mailstores wouldn't preserve
>     original values, so this is asking them to really think hard about
>     preserving it.
>
>     And for APPEND, this is a similar requirement on MUAs to preserve
>     this information. (Some don't and it is very awkward.)
>
>     So I prefer to keep the last 2 SHOULDs.
>
> I guess I'm wondering if those implementations chose not to for some 
> reason you think is valid, or was it purely an oversight on their part 
> and you're using SHOULD to grandfather them in?  Would it be fine to 
> say MUST here and just say that an implementation not doing this is 
> therefore not compliant with rev2?

I think I already gave an example of limited mailstores that are not 
able to preserve some information on COPY/MOVE. (For example they might 
be gatewaying data to other more restrictive formats). I don't think we 
want to make them non compliant at this time.

In regards to clients preserving internaldates on APPEND. If they use 
APPEND to migrate/copy data between 2 different IMAP servers or between 
a local and remote mailstore, they must preserve it. But APPEND can also 
be used for other creating modifications, so again I think SHOULD is 
fine as is.

>>
>>     Section 6.1.2
>>
>>
>>     This section says NOOP can be used to reset the autologout timer
>>     (which seems definite), but Section 5.1.4 says any command only
>>     SHOULD reset the timer.  Do these line up?
>>
>     (I assume you meant 5.4)
>
>     Well spotted. I changed text in 5.4 to readL
>
>      The receipt of any command from the client during that interval
>     resets the autologout timer.
>
> Why would a command deviate from the SHOULD and not reset the timer?
There is no reason I can think of, so the new text I suggested above no 
longer uses "SHOULD". I think that addresses your issue. Do you disagree?

>      [snip]
>
>>     This section should make it more explicit, up front, that the
>>     response names the extensions that were successfully enabled. 
>>     Right now the lede is buried in about the 7th paragraph.
>     I didn't move the paragraph that talks about ENABLED response, but
>     I clarified it.
>
>
> It seems like a pretty important aspect of the response, so I thought 
> it was strange that it wasn't presented until so late in the section.  
> Your call though.
I think the new text is clear, as it explains what appears in the 
ENABLED response the first time ENABLED response is mentioned. So have a 
look at -23 and let me know.
>
>>
>>     It’s weird to say “renaming INBOX is permitted”
>>
>     This is saying that the server wouldn't return "BAD" to it.
>>
>>     followed immediately by “some servers don’t let you do this”.
>>
>     But this is saying that the server can still return "NO".
>>
>>     Which is the standard for this version of IMAP?  If it’s an
>>     implementation choice, I think that’s what this should say.
>>
>     Yes, it is.
>
>
> That's fine, then, if this is clarified.  I just found that bit to be 
> self-contradicting as written in -22.

I think IMAP is a bit subtle in places, as NO and BAD have very 
different semantics. "BAD" means that the client shouldn't have tried 
this. "NO" means some other reason why this fails, which can be entirely 
server specific.

Anyway, I clarified this.


Best Regards,

Alexey