On 1/29/2021 8:11 AM, Jay R. Ashworth via mailop wrote:
The job of standards like RFCs is to *define the interface between syntax
and semantics*, as I see it: they tell you what the data *means*. That's
information that's in the domain of end applications as well, as I see it:
the MUA should care what the RFC thinks about the semantics of that data,
since everyone else is already singing off that page of the hymnal.
No standard forces a telephone to use NPAs rather than ZIP codes at the
front of a phone number, I don't think, but you won't interface with the
network (for which Bellcore's "Notes (heh) on the Networks" is that
standard)...
Just to make clear that I'm not fond of appeals to authority, including
my own, I'll note that folks with every bit as much experience as I have
often -- maybe even usually -- disagree with my assessments. But often
isn't always...
A standard defines the sandbox it plays in. It's essential that the
four walls of that sandbox (to mix metaphors) be quite clear. The
alternative is a mess. Every time.
That's why I had the prefatory comment, in my previous note, about
activity that is outside the email protocol specs.
The phrase *define the interface between syntax
> and semantics* isn't clear to me, since I think of them as an
integrated set, except at a very, very low level.
But I think the issue, here, is not about the syntax or semantics
/within/ the email specifications, but outside of them.
As I said, the specialized adaptation of display-name that has happened
in reaction to DMARC has no formal documentation or approval.
Everything about it is ad hoc. To the formal email specification,
display-name is an uninterpreted literal strong. Nothing more.
When an MUA gets clever, while formulating a reply message, it might be
clever good and it might be clever wrong, but its cleverness is fully
and completely outside of any existing standard.
And...
Although I showed some restraint in my earlier note, I will now point to
two specifications I put together, seeking a less hacky way of dealing
with this DMARC-generated issue:
Author Header Field
https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/
https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/
DMARC Use of the RFC5322.Sender Header Field
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
