[Emailcore] (correction) Re: Ticket #76: G.22. IANA Registration Model for Registries Other, Than Service Extensions

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

Sorry... While I think the argument in my earlier note holds,
the example I used was wrong.  So please substitute the new
discussion below... 

--On Friday, November 11, 2022 14:27 -0500 John C Klensin
<[e-mail]> wrote:

> Consider receiving a "Received:" header field that looks like:
> 
> Received: from somehost.example.com (localhost [IPv6:::1])
> 	by otherhost.example.com (Postfix) with ESMTP id 0CE6CC14CE38
>   fiddlefaddle frozzlefoop;
> 	Fri, 11 Nov 2022 05:46:24 -0800 (PST)
> 
> Now "Received:" header fields are, the specs more or less say,
> intended for use in tracing the messages and the paths taken
> and not for interpretation by automata _and_ that we are
> already including more information in what are syntactically
> comments than 5322bis and its predecessors generally
> encourage,   We have also moved toward making a separate
> "Fiddlefaddle:" header field easy to register on essentially a
> FCFS basis.  So, if there is no community-reviewed and
> accepted documentation for
> "fiddlefaddle" in "Received:" header fields, what value does
> registering it have?  Put differently, in this case, if the
> "requirement" for registration with community checking drives
> someone toward either a separate extension header field or
> explicitly as a comment within the "Received:" header field,
> maybe that is A Good Thing.
>...

> Consider receiving a "Received:" header field that looks like:
> 
> Received: from somehost.example.com (localhost [IPv6:::1])
> 	by otherhost.example.com (Postfix) with ESMTP id 0CE6CC14CE38
>   fiddlefaddle frozzlefoop;
> 	Fri, 11 Nov 2022 05:46:24 -0800 (PST)
> 
> Now "Received:" header fields are, the specs more or less say,
> intended for use in tracing the messages and the paths taken
> and not for interpretation by automata _and_ that we are
> already including more information in what are syntactically
> comments than 5322bis and its predecessors generally
> encourage,   We have also moved toward making a separate
> "Fiddlefaddle:" header field easy to register on essentially a
> FCFS basis.  So, if there is no community-reviewed and
> accepted documentation for
> "fiddlefaddle" in "Received:" header fields, what value does
> registering it have?  Put differently, in this case, if the
> "requirement" for registration with community checking drives
> someone toward either a separate extension header field or
> explicitly as a comment within the "Received:" header field,
> maybe that is A Good Thing.


Improved example/discussion for link and protocol identifiers:

IMO, that case applies even more strongly for link identifiers
and, as I mentioned at the meeting, more strongly yet for
protocol ones:

The example above, derived from a "Received:" header field in a
message distributed from an IETF list, omits "via" entirely,
something that is not uncommon these days and for which there is
not evidence of harm.  

So, assume one were supplied and, instead of "via TCP" (the only
value called out in rfc5321; the registry also contains "UUCP"
but nothing else), they said "via FunnyExample" without a
definition (as allowed by FCFS).  Do we prefer that over "(via
FunnyExample)" as a comment and, if so why?  More specifically,
does encouraging someone to register and use "via FunnyExample"
rather than "via TCP" seem helpful, especially since we have
examples of the lower-information above that would also clearly
allow "(FunnyExample)" as part of the comment associated with
"by" if one considered the 5322bis syntax and not the
peculiarity of 5321bis (and 5321) specifying the syntax of the
inside of a comment).  Either way, under FCFS, we still would
have no way to know either what "FunnyExample" might mean or
whether any supplied definition would be stable from week to
week (remember Ned's oft-repeated admonition about email
messages being stored and interpreted years later).  Now, with
35 or so years retrospect, I wonder why we never registered,
e.g., "BITNET", and maybe you remember why "CSNET" was not
registered, but, while I do remember the former being used (and
gatewayed), it is clear to me that no serious harm was done by
its omission.

The situation with protocol is different but may be equally bad:
borrowing from recent discussions on various other IETF lists,
do we really believe that encouraging registration of, e.g.,
"WITH JunkMail" without a definition as helpful.  Certainly
"WITH SpamMechanism4" would be helpful, but no spammer in
their/its collective right minds would register such a thing,
even with FCFS.  The registrations we do have are all variations
on SMTP/ESMTP, LMTP, and one for MMS.  Again, not clear that has
done any harm.  More important, the real interoperability
issues, as distinct from the tracing ones, arise with gatewaying
and that requires serious, comprehensible, and stable protocol
specifications.  Could the requirement be downgraded to
"Specification Required" with a serious specification review?
Yep, but then one would need to be sure of a pool of experts
with enough knowledge and experience who were able and willing
to do the reviews and I don't think there is evidence that they
exist.   

So, again, my inclination is to apply the "minimum change"
principle until and unless there is evidence that the present
registrations model is causing harm or that changing the
registration model to dispense with the requirement for
carefully IETF-reviewed documentation would bring significant
benefits, especially given that they are elements of a header
field that it intended to be informational only (for humans).

And, Alexey, "minimum change" argues that the registry should
remain Standards Track or "RFC-documented, IESG-approved,
Experimental protocol".  That does not allow for Informational,
which "IETF Review" does.  I didn't hear any discussion
yesterday that would justify such a change.  I don't,
personally, have any strong objection, but I don't consider it
just a minor textual change either.

   john

not having these