Re: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap4rev2-27: (with COMMENT)

[Alexey Melnikov <[e-mail]>]

Hi Ben,

Replying to a few more of your comments:

On 04/02/2021 09:33, Benjamin Kaduk via Datatracker wrote:
> There are several places where we see a:
>
>     Note: Since this document is restricted to 7-bit ASCII text, it is
>     not possible to show actual UTF-8 data.  [...]
>
> But this document is *not* restricted to 7-bit ASCII text!
> (I guess the (not-quoted) bit about not being possible to show actual KOI8-R data is
> still true, though.)  Showing actual non-ASCII text may not be as
> helpful as the current formulation, though, so I'd suggest just a
> modification to the disclaimer.
Ok.
> Section 6.1.1
>
>     Other capability names refer to extensions, revisions, or amendments
>     to this specification.  See the documentation of the CAPABILITY
>     response in Section 7.2.2 for additional information.  No
>     capabilities, beyond the base IMAP4rev2 set defined in this
>     specification, are enabled without explicit client action to invoke
>     the capability.
>
> Should we also note here that even the base IMAP4rev2 set can require
> explicit client action to enable (e.g., when IMAP4rev1 is also
> advertised)?

You have a point. I replaced the last sentence with 2 sentences:

If IMAP4rev1 capability is not advertised, no capabilities, beyond the base IMAP4rev2 set 

defined in this specification, are enabled without explicit client action to invoke the capability.
If both IMAP4rev1 and IMAP4rev1 capabilities are advertised, no capabilities, 
beyond
the base IMAP4rev1 set specified in RFC 3501, are enabled without explicit 
client action
     to invoke the capability.
> Section 6.3.9.8
>
>     4:   In this example, we see more mailboxes that reside on another
>          server.  This is similar to the command <RLIST "" "%">.
>
>        C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)
>        S: * LIST (\Marked \NoInferiors) "/" "inbox"
>        S: * LIST (\HasChildren) "/" "Fruit"
>        S: * LIST (\HasNoChildren) "/" "Tofu"
>        S: * LIST (\HasChildren) "/" "Vegetable"
>        S: * LIST (\Remote) "/" "Bread"
>        S: * LIST (\HasChildren \Remote) "/" "Meat"
>        S: A04 OK done
>
> Why does "Bread" not give \HasChildren or \HasNoChildren?
> I thought §6.3.9.5 said that the server MUST return these attributes
> (and the example does show \HasChildren returned for another \Remote
> box).
Agreed. I added \HasNoChildren for it.
> In example 10, "also" doesn't exist and "also/jazz" is remote.  Can we say
> anything a priori about whether "also" is remote (the example, of
> course, shows that it is not remote)?
It doesn't matter, because it doesn't exist.

   [snip]

> Section 7.1.3
>
> The example doesn't seem to show the tagged BAD usage, and I'm having
> trouble convincing myself whether "very long command line" should
> qualify for the tagged form or not.

Either. I think it depends on how the parser is written.

Would you like me to add an example of a command issued in a wrong state 
(that would result in tagged BAD)?

> Section 7.2, 7.3
>
> If the section headings are split into server and mailbox status,
> respectively, why does the initial intro paragraph still list both
> server and mailbox status data in both sections?
They were initially part of the same section, which was split up. I 
fixed description now.
> Section 7.2.2
>
>     Other capability names indicate that the server supports an
>     extension, revision, or amendment to the IMAP4rev2 protocol.  Server
>     responses MUST conform to this document until the client issues a
>     command that uses the associated capability.
>
> (another instance) should we say anything about "MUST conform to this
> document" not applying when the server also advertises IMAP4rev1?
I've made a similar update here to the above.

Best Regards,

Alexey