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

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

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.

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.

I also didn't think you meant caching when you said "recorded"; I took that
to refer to logging.  Possibly something else to clarify.

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

>
> It seems strange to oblige a client detecting both $Junk and $NotJunk
> being set to deal with that condition by fixing it.  The advice to ignore
> them is fine, however.
>
> This is how they were defined when they were registered. I appreciate that
> this might be strange, but changing semantics at this point is not going to
> work.
>

Fair enough.

If you suggest changing the description without changing the semantics, we
> should consider this.
>

No, it's the semantics I found odd, but I realize you're not doing
something new here.

It’s also curious to put a normative SHOULD on registering keywords, as
> IANA activity is outside of the protocol.
>
> I've seen this done in other RFCs.
>

Doesn't mean they're right.  :-)

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.


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


>
> Section 5.1.2.1
>
> Although both “Implementer” and “Implementor” appear to be correct, you
> use the latter everywhere in the document except here.  (Actually, Google
> docs suggests the former.)
>
> I changed it to implementors and I am happy for RFC Editor to tell me
> which one they prefer ;-)
>

Yeah, I'm fine with either.  I just wanted internal consistency.


>
> Section 5.2
>
> “Sometimes, such behavior is REQUIRED.”  This isn’t a specific normative
> statement, so I’d use the lowercase version here, and use BCP 14 language
> when you’re presenting specific cases.
>
> I agree. Changed.
>  [snip]
>
>
> 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?

> Section 6.2.3
>
> I think there’s an “or” missing in the last paragraph.
>
> This looks Ok to me. Can you elaborate?
>
Uh, no, I can't. Ignore this one.  It was very late.

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


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


>
>    Clients SHOULD use the empty reference
>
>    argument.
>
> Why might I not do this?
>
> If you want "change directory" kind of behaviour (where the directory is
> the reference name argument).
>

Ah, yes.  Then this could use a bit of clarification.


>
> Section 6.3.9.2
>
> This section (and the previous) require that \Subscribed be computed
> accurately before the response is generated.  How does this square with the
> text in Section 6.3.9 that insists replies come quickly?
>
> You have to comply with both :-). It is quite important for \Subscribed to
> be accurate, so implementations need to do that while maintaining
> reasonable performance.
>

OK.  I just wanted to make sure the reader isn't getting "You MUST be
fast!" from one direction while also doing "You MUST do all this expensive
stuff!" from the other with no guidance about how to resolve this.

>
>
>  [snip]
>
>
> The second paragraph also gets into the presentation of the reply.  This
> is human factors stuff the IETF tends to avoid.  Are we sure it belongs
> here?
>
> This is copy of the text from another RFC and I personally found this text
> to be useful when implementing.
>

You might consider putting these presentation advice paragraphs into an
appendix too.

-MSK