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

["Murray S. Kucherawy" <[e-mail]>]

On Tue, Jan 5, 2021 at 5:56 AM Alexey Melnikov <[e-mail]>
wrote:

> 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]>
> 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.
>

Yep, I just wanted to have the discussion.  Thanks for indulging.

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 hear you.  The thing that I was hoping to solve for is that it's not very
crisp.  Which server data MUST be cached, and which server data is OK to
toss?  You can't tell just from that sentence.  If it's specified more
clearly later on, then this isn't needed.


> 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?
>
Somehow when I read it the first time I didn't realize that was simply
caching; it seemed to be describing something more elaborate.  Anyway, yes,
this is fine.


>
>> 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.
>

Huh.  OK.  I learned something today.  :-)


> 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.
>

OK.


>> 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.
>
OK, thanks for explaining.  I don't have any particular remedy in mind now
that I know what's going on behind this.


>> 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?
>

Nope, we're good here.


>  [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.
>

Good to go.

>
>> 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.
>

Thanks!

-24 covers all of the major stuff except the text duplication (nice
work!).  Did we figure out how you'd like to deal with that?  That's not a
Last Call blocker for me -- I'll send -24 if you think it's ready -- but I
wouldn't be surprised if some downstream reviewer or AD makes the same
observation.

-MSK