[secdir] Re: SECDIR review of draft-ietf-emailcore-rfc5321bis-42

[John C Klensin <[e-mail]>]

Donald,

Just to address this one issue and try to clarify...

If the WG (copied) and IESG want changes in this area (noting that
you identified it as a nit), I'll see what can be done.  However, for
their information rather than to drag this conversation out:

(1) Based on recent experience, inserting a "MUST NOT" in this
context would almost certainly lead to a demand of why a violation
would cause interoperability problems.  It would be easy to explain
how it would cause unnecessary confusion or registry clutter, but the
criterion is interoperability problems.

(2) For the first case, the number of times an extension has been
proposed (not even adopted, but proposed) that would change the
meaning of an existing code, or the sequencing of those codes, since
RFC 1425 defined such extensions in 1993 is zero.  Going back only to
the use of the same "in principle" language in RFC  2821, that makes
24 years without any evidence that the phrasing caused harm.   The
second case (in 8.1.4) is more complicated because new clauses have
been defined (see
<https://www.iana.org/assignments/mail-parameters/mail-parameters.xhtml#mail-parameters-8>)
and, while one of them references an external registry for values,
that registry existed before the specification that added the clauses
to "Received:" and is used for other purposes rather than being email
specific.   So, in that case, only 16 or 17 years with no
demonstration of harm or even confusion.

best,
   john


--On Friday, April 4, 2025 18:14 -0400 Donald Eastlake
<[e-mail]> wrote:

>...
>> The use of "in principle" appears, in both of the contexts you
>> observed, in RFC 5321 and the first usage is in RFC 2821.  Changing
>> it interacts with "minimal change" principle established by the WG
>> and its charter.  Independent of that procedural issue, the
>> phrasing was used in 2008 and earlier to indicate that the changes
>> to code definitions referred to in 4.3.2 and the possible separate
>> registries referred to in 8.1.4 would be bad ideas under any
>> circumstances the WG could determine.  While "in principle" is, in
>> a way, hand waving, the alternative would have been to say,
>> explicitly, something like "we don't want to prohibit that
>> possibility, but any attempt to do it should be scrutinized very
>> carefully" or a normative "such things SHOULD NOT be done".   The
>> experience in 2007-2008 and predictions
> 
> "in principle" and "scrutinized very carefully" are both vague. If
> you can't think of any type of reason for people to do it, then
> just say MUST NOT and be done with it. If something does come up,
> as is always possible for anything, this can be changed by later
> RFCs.