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

["Bron Gondwana" <[e-mail]>]

Thanks Alexey, I see there's a -12 there now, and I'm happy with all the edits in it :)

There are still some outstanding points from this thread - are you expecting to issue a -13 for those?

Thanks,

Bron.

On Sat, Feb 8, 2020, at 04:04, Alexey Melnikov wrote:
> 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

> _______________________________________________
> Extra mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/extra
> 

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 [e-mail]