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

[Barry Leiba <[e-mail]>]

For what it's worth, I don't think that BCP 178 means to say that you
should never use things that start with "X".  It says that you should
not specifically use "X"-prefixed stuff to make a distinction between
registered and unregistered things when you lay out registries.

Therefore, I think it's fine to use examples that start with "X".
They're only examples.

For the other cases, such as these:

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

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

...well, they clearly fall under BCP 178 and we should fix those.

Barry

On Mon, Jan 4, 2021 at 1:26 PM Alexey Melnikov
<[e-mail]> wrote:
>
> 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
>
>