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

[Michael Peddemors <[e-mail]>]

Lets' talk some real world examples, and what the consensus is..

X-Archive
X-Attachment-Id
X-Auth-ID
X-Authority-Analysis
X-Auto-Response-Suppress
X-BeenThere
X-CampTrackID
X-Classification-ID
X-CL-ID
X-CMAE-Envelope
X-Contact-Form-Submission
X-CTCH
X-FE-Policy-ID-smtp.fortinet.com
X-Footer
X-Forwarded-Message-Id
X-Gmail-Original-Message-ID
X-Gm-Message-State
X-Gm-Phishy
X-Gm-Spam
X-GOOD-IDEA as an example of a fictitious capability that can be=20
X-Google-DKIM-Signature
X-Google-Original-From
X-Google-Passthru
X-Google-Smtp-Source
X-Headerized
X-LinkedIn-Class
X-LinkedIn-fbl
X-LinkedIn-Id
X-LinkedIn-Template
X-MagicMail-Quarantine
X-MagicMail-SourceIP
X-Mailbox-Line
X-Mailer
X-Mailman-Approved-At
X-Mailman-Version
X-MDID
X-MessageID-Signature
X-Microsoft-Antispam-Mailbox-Delivery
X-Microsoft-Antispam-Message-Info
X-MS-Exchange-CrossTenant-AuthAs
X-MS-Exchange-CrossTenant-AuthSource
X-MS-Exchange-CrossTenant-fromentityheader
X-MS-Exchange-CrossTenant-id
X-MS-Exchange-CrossTenant-mailboxtype
X-MS-Exchange-CrossTenant-Network-Message-Id
X-MS-Exchange-CrossTenant-originalarrivaltime
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg
X-MS-Exchange-CrossTenant-userprincipalname
X-MS-Exchange-Organization-AuthSource
X-MS-Exchange-Organization-Network-Message-Id
X-MS-Exchange-Organization-RecordReviewCfmType
X-MS-Exchange-Transport-CrossTenantHeadersStamped
X-MS-Has-Attach
X-MS-TNEF-Correlator
X-No-Archive
X-OriginalArrivalTime
X-Original-To
X-Originating-IP
X-OriginatorOrg
X-PPP-Message-ID
X-PPP-Vhost
X-Priority
X-RADICALE-NAME
X-Received
X-SES-Outgoing
X-Spam-Flag
X-Spam-Level
X-Spam-Score
X-Spam-Status
X-Telus-Authed
X-Time-IN
X-Virus-Scanned

Many of these are now semi-permanent, and it is doubtful they will be 
deprecated any time soon in many cases..

What are we suggesting here? And in some cases the headers are placed by 
a receiving MTA, and only meant for local decision making, and aren't 
expected to be seen in MTA->MTA traffic..



On 2021-01-04 10:54 a.m., Barry Leiba wrote:
> 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
>>
>>
> 
> _______________________________________________
> Extra mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/extra
> 



-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.