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

[Benjamin Kaduk <[e-mail]>]

Hi Alexey,

This all sounds good; just one answer to your question inline.

On Wed, Feb 10, 2021 at 02:54:46PM +0000, Alexey Melnikov wrote:
> 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)?

It would feel more complete to me with such an example, but it's not a big
deal and it will be fine to just leave it as-is.

Thanks for all the updates,

Ben

> > 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
>