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

[Alexey Melnikov <[e-mail]>]

Hi Bron,

On 08/07/2020 13:58, Bron Gondwana wrote:
> I have reviewed all the changes from -12 to -15 and am still mostly 
> happy :)  I haven't reviewed -15 in full because it's a big job!
>
> Regarding the changes in -13, I have a couple of small things:
>
> *Regarding unsolicited fetch:**
> *
>
> If the server chooses to send unsolicited FETCH responses, they 
> MUST include UID FETCH item.  Note that this is a new requirement when 
> compared to RFC 3501.
>
> This could do with a clarification that this only applies after 
> "ENABLED IMAP4REV2".

Actually, in this one case: I don't think so. It shouldn't break any old 
(IMAP4rev1 only) clients to return this.

But this made me think: Maybe the document needs a new section that list 
everything that the server should do after ENABLED IMAP4rev2?

> *Regarding SELECT allowing non-canonical names:**
> *
>
> We've already discussed the list response to CREATE.  Should SELECT 
> also return the canonical representation of the mailbox name as part 
> of the reply?

This will be again returning an untagged LIST response on SELECT.

I will add it to my to do list.

>
> *Next steps:**
> *
>
> Alexey - are there any other changes still waiting before we do a 
> working group last call?
>
> Thanks,
>
> Bron.
>
> On Fri, Feb 14, 2020, at 10:47, Bron Gondwana wrote:
>> 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]
>>
>>
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   [e-mail]
>
>
>
> _______________________________________________
> Extra mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/extra