Re: [Extra] Review: draft-ietf-extra-imap4rev2-11

[Alexey Melnikov <[e-mail]>]

Hi Bron,

Replying to issues raised not covered by my reply to Timo:

On 29/01/2020 12:08, Bron Gondwana wrote:
> Sorry about the delay in doing this!   I was supposed to be doing the 
> shepherding write-up, and so I figured I should read it properly.
>
> I've had a full read through over some very many days (I admit, I 
> skimmed through the ABNF) and I have comments.  It's long, and 
> hopefully comprehensive - though I'm sure I missed things.
>
>
> *2.1 Link level
> *
>
> Is it appropriate to mention TLS on 993 here?  It's mentioned deep 
> within the document, but not here.
Done.
> *2.3.2 Flags Message Attribute
> *
>
> formatting issue: $Forwarded is duplicated 3 times and $MDNSent is 
> duplicated twice in the plain-text format.

This is actually a bug in TXT rendering from XML.

  [snip]

> *6.3.1 ENABLE command
> *
>
> The example shows a conversation with an imap4rev1 only server.
Fixed.
> The examples don't clearly show that only the newly enabled responses 
> are correct, e.g. the sequence:
>
> C1 ENABLE CONDSTORE
> * ENABLED CONDSTORE
> C1 OK foo
> C2 ENABLE CONDSTORE QRESYNC
> * ENABLED QRESYNC
> C2 OK foo
>
> The second doesn't say "ENABLED CONDSTORE" because it was already 
> enabled earlier on this connection.

Actually, it is perfectly Ok for the server to return in response to C2:

* ENABLED QRESYNC CONDSTORE

The text in the document wasn't entirely clear. It was trying to say 
that the preferred server behaviour is:

L1 ENABLE A B
* ENABLED A B
L1 OK foo

L2 ENABLE C
* ENABLED C
L2 OK foo

and not

L2 ENABLE C
* ENABLED A B C
L2 OK foo

I clarified this.
>
> (AKA: clients MUST remember what they have enabled)
>
> *6.3.2 SELECT command
> *
>
> The [UIDNEXT <n>] response is duplicated with two different pieces of 
> text.
Again, this is a tool issue.
> /When deselecting a selected mailbox, the server MUST return an 
> untagged OK response with the "[CLOSED]" response code when the 
> currently selected mailbox *is closed (see Paragraph 10). */*- I'm not 
> sure where "Paragraph 10" is.**
> *
I will check. I think the section reference for response codes is missing.
> The last paragraph of this section has the word "deprecated" spelled 
> as "depractated".
Fixed.
>
> *6.3.7 SUBSCRIBE
> *
>
> Speak of the devil.  Lots of sites violate the MUST NOT unilaterally 
> remove rule.  Should we weaken it to SHOULD?
Done.
>   The justification for the MUST is "the server site might choose to 
> do X" - well, if the server site is doing that, then maybe they 
> SHOULDN'T unilaterally remove the subscriptions, but otherwise it's a 
> better user experience and what people want.
>
> (also: by enabling a non-default break the rules config, it's what our 
> server does!)
>
> *6.3.8 UNSUBSCRIBE*
>
> /This command returns a tagged OK response only if the unsubscription 
> is successful. /- this is not clear on what happens if the mailbox is 
> not currently subscribed - does it silently succeed, or is there an 
> expected error?
>
> For what it's worth, our server just says "OK Completed" even if it's 
> already been unsubscrbed - and likewise for subscribe if it's already 
> subscribed it just say "yep, all good".
I agree that your server behaviour is sensible. Updated description of 
both SUBSCRIBE and UNSUBSCRIBE.
>
> . create INBOX.foo
> . OK [MAILBOXID (7eca8f55-e233-4458-9d48-af854fb4b279)] Completed
> . subscribe INBOX.foo
> . OK Completed
> . unsubscribe INBOX.foo
> . OK Completed
> . unsubscribe INBOX.foo
> . OK Completed
> . subscribe INBOX.foo
> . OK Completed
> . subscribe INBOX.foo
> . OK Completed
>
>
> *6.3.9 LIST
> *
>
> There's a weird line wrapping near the top of page 44 where a 
> paragraph is split in half:
>
>     The reference and mailbox name arguments are interpreted into a
>     canonical form that represents an unambiguous left-to-right
>     hierarchy.  The returned mailbox names will be in the interpreted
>     form,
>
>     that we call "canonical LIST pattern" later in this document.  To
>     define the term "canonical LIST pattern" formally: it refers to the
>     canonical pattern constructed internally by the server from the
>     reference and mailbox name arguments.
I will double check, but I think it is another rendering issue to TXT 
format (there is a comment in bettween 2 parts of the sentence.
>
> *6.3.9.2 LIST Return Options
> *
>
> The CHILDREN item is duplicated with two different pieces of text.

Again, a rendering issue. These are actually 2 separate paragraphs under 
the same item.


> *6.4.4 SEARCH
> *
>
>     For example,
>     the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all
>     deleted messages from Smith that were placed in the mailbox since
>     February 1, 1994.
>
> That's not strictly true - SAVEDATE would be "placed in the mailbox".  
> The wording should say "with INTERNALDATE greater than February 1, 
> 1994" or so.

Good point. Fixed.


> *6.4.4.1 SAVE Result
> *
>
> I'm not sure I understand the interaction here with closing and 
> re-opening a mailbox.  I would expect that closing a mailbox would 
> wipe the SAVED result, and that trying to use a SAVED result when 
> there isn't one should return an error.
I think Timo explained this well in his response.

  [snip]

>
> *7.1 Status Responses
> *
>
> Using 'o' as a tag in the ALREADYEXISTS item is confusing, it looks 
> like an attempt to do dot points!
Changed :-).

  [snip]

Best Regards,

Alexey