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

Thanks Alexey. Am traveling this week but will try to make time to review.

Extra isn't meeting in Vancouver, so we will have to discuss things on the list! Probably good with the number of people not coming anyway.

I'm not so sure that unsolicited UID is common, but then I haven't looked at what other servers do for 10 years or so...

Cheers,

Bron.

On Mon, Mar 9, 2020, at 08:39, Alexey Melnikov wrote:
> Hi Bron,

> I addressed several more comments from you in -13:

> On 29/01/2020 12:08, Bron Gondwana wrote:
>> *2.2.1 Client protocol*
>> **
>> *"A different tag is generated by the client for each command".* There's no "MUST" on this, and certainly I've seen clients which don't. Do we want to make that more strict in rev2? It would be a bit of a pain on the commandline where I normally use ".", but it's also annoying as a server author that you can't rely on tag uniqueness.
>> 
>> Maybe the client SHOULD generate a different tag for every command, but a server MUST accept tag reuse (could restrict concurrency, a tag can only be reused after it's been "returned")
> I added:

>  (More formally: the client SHOULD generate a unique tag for every command,
>  but a server MUST accept tag reuse.)
> ****

>> 
>> 
>> *2.3.1.1 UID Attribute*
>> **
>> Both UID and UIDVALIDITY say "unsigned 32-bit value" - but strictly (as seen later in the ABNF) they aren't allowed to be zero. It would be good to say "non-zero" when each is first mentioned, but I don't care strongly about this one.
> Clarified.

>> 
>> 
>> *2.3.2 Flags Message Attribute*
>> 
>> Should this section also reference https://www.iana.org/assignments/imap-jmap-keywords/imap-jmap-keywords.xhtml ?
> Added
> 
>> 
>> 
>> *5.1 Mailbox Naming*
>> 
>> This doesn't solve one of my naming bugbears. The spec says things like *"servers MAY accept a de-normalized UTF-8 mailbox name and conver it to Net-Unicode prior to mailbox creation." -*** **there is no clear way to know what the SELECTable name will be after creating a mailbox.
>> 
>> If I was designing this myself from scratch I would say that "SELECT of the same octets that were passed to CREATE MUST open that same mailbox" or something to that effect. Since we're messing with how mailbox naming works somewhat for imap4rev2, I'd be keen to add this restriction on server behaviour so that clients don't fall into a "CREATE -> ALREADY EXISTS / SELECT -> DOESN'T EXIST" loop.
>> 
>> It still doesn't mean that you can reliably tell the correct octets for the matching mailbox from the LIST response though :(
>> 
> I believe I clarified this with the following text:

>  However, servers MAY accept a de-normalized UTF-8
>  mailbox name and convert it to Unicode normalization form "NFC"
>  (as per Net-Unicode requirements) prior to mailbox creation.
>  Servers that choose to accept such de-normalized UTF-8 mailbox
>  names MUST accept them in all IMAP commands that have a mailbox name parameter.
>  In particular SELECT &lt;name&gt; must open the same mailbox that
>  was successfully created with CREATE &lt;name&gt;, even if &lt;name&gt;
>  is a de-normalized UTF-8 mailbox name.

> 
>> 
>> *7.2.3 LIST Response*
>> 
>> This is the interesting bit for SPECIAL-USE - it should reference that here - as well as referencing the registry since it reproduces some of it inline.
>> 
>> https://www.iana.org/assignments/imap-mailbox-name-attributes/imap-mailbox-name-attributes.xhtml
> I've added the IANA registry reference.

> __

>> __
>> __
>> *7.4.2 FETCH Response*
>> 
>> I remember past bugs with UID in "unsolicited" FLAGS responses. Do we need to require that including UID only happen after ENABLE IMAP4REV2 (as it is for ENABLE QRESYNC)?
> I am border line on this, but I don't think so. This should be common enough that even IMAP4rev1 clients should be able to handle this.

> 

>> 
>> *Appendix C: Changes*
>> 
>> Right now it's still stated as "the planned changes" and there's still some TODO in there (some of which I think could be well handled by referencing the registries rather than replicating them inline).
> I cleaned this up and there are only 2 smaller items remaining, that we might want to discuss in the WG.

> Best Regards,

> Alexey

> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra
> 

--
 Bron Gondwana, CEO, Fastmail Pty Ltd
 brong@fastmailteam.com