[ih] Email behavior (better subject ID...)

[Dave Crocker]

On 9/3/2021 3:04 PM, Jack Haverty via Internet-history wrote:
> I didn't know about those header fields until you pointed them out. The 
> mail app I use (Thunderbird)  doesn't appear to do anything with those 
> fields, but I can see them only if I enable "Show All Headers". 

I am responding to your email by using Thunderbird's Reply to List 
command.  It's had that ability for so long, I don't remember whether it 
is built in or I added an extension that does it.  The advantage of 
using that command is that it drops off all of the individual addresses.



On 9/3/2021 9:16 PM, Jack Haverty via Internet-history wrote:
> Regardless of their status, you just described exactly what I
> observed: "Lots of mail programs recognize them and do something with
> them "   The phrase "do something" doesn't sound like a definition of
> a standard.

Even in lower layers, there is information defined that does not include 
specification of what to 'do' with it.  Rather, the specification serves 
to standardize the syntax for finding the information and the semantics 
of what it means.  It leaves the 'doing something' as a consideration 
outside that specification.,

Consider RFC 791 and "source address".

There is no text in that specification that says what a receiver is to 
do with it.

(There's some text about sending-side and some text about maintaining 
the field when doing source routing.)

Sometimes, it's deemed reasonable to specify common syntax and semantics 
and carriage of information, without specifying what the current layer 
or higher-layers of a system will do with it.  This allows multiple 
consumers and it allows experimentation.

This distinction often causes confusion.  RFC 9078 defines labeling of 
emojis in a message as having the semantic of a 'reaction' to a previous 
message.  But how should user agents /use/ it?  The spec has a tiny 
amount of discussion, but doesn't tell a recipient system what something 
to do with it.  That's because there are lots of entirely reasonable 
choices and there is no need to constrain them.



d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net