[Extra] BCP 178/X- convention (was AD Review of draft-ietf-extra-imap4rev2)

[Alexey Melnikov <[e-mail]>]

Hi Murray/Barry,

I've extracted all of your comments related to BCP 178 ("X- convention 
considered harmful):

On 04/01/2021 08:18, Murray S. Kucherawy wrote:
>
> Section 6.1.1
>
>
> Is the stuff about XBLURDYBLOOP still appropriate given BCP 178?
>
I deleted this text, as it really belongs to future revision of RFC 4422 
(SASL), if at all.

> Section 6.3.1
>
> There’s another “X” reference here (BCP 178).
>
>
This is section defines the ENABLE command. The example is using 
X-GOOD-IDEA as an example of a fictitious capability that can be 
enabled. Use of X-GOOD-IDEA in the example is not critical, but it makes 
it more explicit that this is not registered. I can change the example.

>   In this example, a server supports 2 Personal Namespaces.  …
>
>
> There’s a reference to X-PARAM in here that probably needs updating in 
> light of BCP 178.
>
Here, I think we need to use an unregistered parameter. It doesn't have 
to be X-PARAM, but X-PARAM seems a bit more obvious due to old usage, 
even if it is considered wrong these days.


> Section 6.5
>
> Is this appropriate in light of BCP 178?
>
So this section is titled "Client Commands - Experimental/Expansion" and 
talks in general terms about implementation specific commands (that were 
required to start with "X" in RFC 3501) and some generic requirements on 
clients/servers in regards to extensions. I can extract useful text 
about the latter and drop the former.
>
> Section 7.2.2
>
>
> The stuff about capability names starting with “X” should be reviewed 
> in light of BCP 178.
>
This section is titled "CAPABILITY Response". Below is the offending text:

    Capability names MUST either begin with "X" or be informational,
    experimental or standards-track IMAP4rev2 extensions, revisions, or
    amendments registered with IANA.

Dropping "X" from the above list would be fine with me. But this raises 
a related question: should this document allow Experimental RFCs outside 
of IETF stream in order to encourage people to document their private 
extensions?

    A server SHOULD NOT offer
    unregistered or non-standard capability names, unless such names are
    prefixed with an "X".

This probably should be dropped.

Best Regards,

Alexey