G.3. Meaning of "MTA" and Related Terminology

ietf-wg-emailcore / emailcore

3 stars 0 forks source link

G.3. Meaning of "MTA" and Related Terminology #3

Closed ietf-svn-bot closed 2 years ago

ietf-svn-bot commented 3 years ago

keyword_SMTP type_defect | by alexey.melnikov@isode.com

G.3. Meaning of "MTA" and Related Terminology

A terminology issue has come up about what the term "MTA" actually refers to, a question that became at least slightly more complicated when we formalized RFC 6409 Submission Servers. Does the document need to be adjusted to be more clear about this topic? Note that the answer may interact with the question asked in Section 2 above. Possibly along the same lines, RFC 2821 changed the RFC 821 terminology from "sender-SMTP" and "receiver-SMTP" to "SMTP client" and "SMTP server" respectively. As things have evolved, it is possible that newer terminology is a source of confusion and that the terminology should be changed back, something that also needs discussion.

Issue migrated from trac:3 at 2022-01-31 12:33:13 +0000

ietf-svn-bot commented 3 years ago

@alexey.melnikov@isode.com changed title from Meaning of "MTA" and Related Terminology to G.3. Meaning of "MTA" and Related Terminology

ietf-svn-bot commented 3 years ago

@alexey.melnikov@isode.com set component to smtp

aamelnikov commented 2 years ago

From IETF 113 discussion:

Question 1 - "sender-SMTP" and "receiver-SMTP" vesus "SMTP client" and "SMTP server". Proposal: no change

Klensin points out that 5321 currently contains both. Minimal change says leave as-is; maximal clarity says clean it up and make it consistent.
Resnick agrees with minimal change
Kucherawy from chat - 'You could add a sentence near the top that indicates this document uses "sender-SMTP" and "SMTP client" interchangeably, and change nothing else.'
Melnikov as participant agrees that leaving as-is is best
Murchison asks if he has to update A/S text
Resnick echoes Kucherawy's recommendation for clarifying text (i.e., "both terms are used")
Happel expresses preference for sender and receiver over client and server due to ambiguity in use of client (e.g., client could mean MUA)
Crocker in chat - "Since 'server' seems to have become a socially insensitive term, sender/receiver is the socially safer choice."
Klensin - Use of sender and receiver in document seems mostly to be in context of reference to dual-function entities

aamelnikov commented 2 years ago

Based on no objection from the mailing list, the following change needs to be implemented:

Add a note to the document stating that "sender-SMTP" and "SMTP client", as well as "receiver-SMTP" and "SMTP server" are used interchangeably, but otherwise do no further changes.

aamelnikov commented 2 years ago

The change is implemented in -11