[Emailcore] Re: Your (Roman's) DISCUSS on draft-ietf-emailcore-as and status of the document

[Ken Murchison <[e-mail]>]

Roman, John,

On 9/18/26 3:27 PM, John C Klensin wrote:
> (2) The BCP versus Applicability Statement question is a bit more
> complicated because the boundary is not clear and because the IESG
> has not raised the issue when several previous documents were
> published as BCPs that probably should have been ASs.  Neither, IIR,
> have IETF participants raised that issue in a memorable way.   In any
> event, the decision to do this document as an AS goes back to the
> WG's chartering and the initial outline was done on that basis.
> Changing it to a BCP would require some rewriting (with the risks of
> getting things wrong in the process) so one question is whether, even
> if a BCP classification were more appropriate, it would be worth the
> time, energy, and risk.
>
> More important, the arguments for retaining it as an AS are quire
> strong.  The second attachment is extracted from a discussion among
> the editors, WG Chairs, and Andy (as AD) and is one summary of the
> arguments.  Ken also took the initiative to have Claude prepare a
> summary of the topic, with the same conclusion about leaving it as an
> AS.  I assume he can forward either that analysis, or his summary of
> it, to you if that would be helpful.

Re: Claude

I asked Claude to read RFC 2026 and our draft and give me his opinion on 
the A/S vs BCP question.  I further asked him to ignore the fact that 
the draft uses "applicability statement" in several places.  His analysis:

Having actually read the TOC and body content rather than just the
self-declaration, my own read agrees it functions as an Applicability
Statement — but it's a closer call than the document's own framing suggests.

Why it reads as AS, not BCP:

RFC 2026 §3.2 defines an AS as a document that takes one or more
existing Technical Specifications and says how/when they apply,
including marking individual provisions required, recommended, or
elective. That's almost exactly the shape of this draft's core sections:

- §2.4 doesn't invent anything — it takes named, already-standardized
extensions (STARTTLS/RFC 3207, 8BITMIME/RFC 6152, PIPELINING/RFC 2920,
SMTPUTF8) and classifies each as MUST or SHOULD for senders/receivers.
That's a profile over existing TSs, the textbook AS move.

- §6.5's "SMTP-senders MUST use confidentiality if it is available and
accepted by the receiver" is the same pattern applied to TLS: not a new
protocol requirement, but a rule for when an existing mechanism must be
invoked.

- The document's own dependencies (5321bis, 5322bis) are the TSs being
profiled; this draft doesn't redefine SMTP or IMF syntax itself.

A BCP, by contrast, is supposed to be the output of a
community-deliberation on operational/procedural matters — not a spec,
not a profile of specs, but an agreed practice (registration policy,
operational conduct, IETF process). Nothing here is that; every
recommendation is tied back to "which existing spec provision applies,
and how strictly."

Where it blurs a little:

§4.1's local-part case-sensitivity guidance ("most implementations don't
distinguish case... maximum interoperability is achieved by...") isn't
really "apply TS X in circumstance Y" — it's advice about how to behave
given that real-world implementations diverge from what the base spec
technically permits. That's closer to accumulated operational wisdom
than applicability-of-a-spec. But it's still explicitly interpreting a
specific provision of 5321bis/5322bis (local-part case-sensitivity), so
it stays tethered to a TS rather than standing alone as community
practice the way a BCP would.

My opinion: it's correctly an AS. The document's center of mass —
extension MUST/SHOULD tables, TLS usage rules, address-literal handling
— is squarely "how do existing specs apply here," which is the AS's
defining job. It brushes up against BCP territory in a couple of
interoperability-folklore passages, but not enough to change the
document's fundamental character.

-- 
Kenneth Murchison
Staff Software Developer
Fastmail US LLC
IETF MailMaint Co-Chair