Subject: [Emailcore] Draft agenda for the Interim meeting this Thursday

From: Alexey Melnikov <[email-masked]>
Date: Tue, 7 Dec 2021 14:08:30 +0000

Dear WG participants,

Chairs are hoping to see you on Thursday.

Below is a tentative list of tickets that we will be discussing:

Followup on remaining issues related to #17 (Deprecated Source Routes)
https://trac.ietf.org/trac/emailcore/ticket/17

#9 (G.7.3. Definition of domain name in Section 2.3.5)
https://trac.ietf.org/trac/emailcore/ticket/9

#15 (G.7.9. Discussion of 'blind' copies and RCPT)
https://trac.ietf.org/trac/emailcore/ticket/15

#3 (G.3. Meaning of "MTA" and Related Terminolog)
https://trac.ietf.org/trac/emailcore/ticket/3

#12 (G.7.5. Improve description/definition of mailing lists, aliases, 
and forwarding)
https://trac.ietf.org/trac/emailcore/ticket/12

#4 (Exploders seem to be prohibited from adding List-* header fields)

https://trac.ietf.org/trac/emailcore/ticket/4

Best Regards,

Alexey

---

From: Dave Crocker <[email-masked]>
Date: Tue, 7 Dec 2021 07:45:23 -0800

> https://trac.ietf.org/trac/emailcore/ticket/9

Should SMTP, as a 'standard', cover operation within private 
environments that are relatively or completely independent of the 
'public' Internet.  That is, does the work of the IETF only pertain to 
the global operation of the Internet.  Or do the protocol specification 
have applicability to private use?  And why?

A benefit of at least trying to cover private use is that it will tend 
to make a specification cleaner and more distinct as a component of 
technology.  And given how challenging it can be to properly separate 
things into discrete components(*), perspectives that facilitate making 
these separations are likely to be helpful, even for specifying things 
that operate in that public space.

At the least, it ought to press folk to think harder about what is 
essential and what isn't.  And why.

In the case of domain names, there are really two separate activities. 
One is registration of a name and the other is querying a name.  In the 
case of the term "fully qualified domain name" there might be a third, 
namely syntax.

The benefit of an FQDN is eliminating concern for the way to interpret 
the string.  There's no need to wonder about adding to it, to move it 
from relative to absolute.

The benefit of requiring global registration is a guarantee that there 
will not be any name collisions, even if a name does not resolve in a 
query.

The benefit of requiring that the name be globally resolveable is...?

Consider unresolveable.example.com, where for example.com the name does 
not resolve in the public DNS, but example.com does.  Perhaps it 
resolves in a private DNS that example.com operates internally.  Perhaps 
not.  How is this relevant to the specification of the protocol SMTP, as 
opposed to the global Internet email service?

Should the SMTP specification prohibit either of these cases?  If so, 
why?  And for that matter, what does it mean for the SMTP specification 
to make that prohibition, since example. com can choose to ignore it and 
will otherwise still obtain full SMTP functionality?

A requirement for public resolveability seems obviously essential for 
operation of the public Internet email service.  It does /not/ seem 
essential for the definition of an email transport protocol.

That is a fundamental challenge when doing a protocol specification: 
separating technology specification from service specification.

Conflating the two tends to create messy, confused documentation that 
suffers in both tasks.

d/

(*) Tussle in Cyberspace: Deﬁning Tomorrow's Internet
     http://conferences.sigcomm.org/sigcomm/2002/papers/tussle.pdf

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Tue, 7 Dec 2021 08:21:13 -0800

>  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.

There's probably a really good reason to ignore the IETF-approved 
definition in RFC 5598, rather than just incorporating it by reference.

What exactly is that reason?

d/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 7 Dec 2021 08:45:08 -0800

There's probably a really good reason to ignore the IETF-approved 
definitions in RFC 5598, rather than just incorporating it by reference.

d/

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Dec 2021 23:54:02 -0500

Because Thursday is getting close and no one else has responded,
I am reluctantly doing so.  Inline below...

--On Tuesday, December 7, 2021 08:21 -0800 Dave Crocker
<[email-masked]> wrote:

>> # 3 (G.3. Meaning of "MTA" and Related Terminolog)
>>     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.
> 
> 
> There's probably a really good reason to ignore the
> IETF-approved definition in RFC 5598, rather than just
> incorporating it by reference.
> 

I am aware of two reasons:

(1) The IETF did not "approve" that definition or other
definitions in that document.  What was approved was the
document's publication as a model and a history.  I should not
have to do this, but I call your attention particularly to the
"Status" section that follows the Abstract and the statement "It
does not specify an Internet standard of any kind."  If the IETF
had agreed on that model description and terminology and that it
was intended to be treated as normative, 5598 should have been
published as a BCP or on Standards Track, presumably updating
5321, 5322, and possibly 4409 and other documents in the
process.  

(2) IIR, there are other inconsistencies between the vocabulary
and terminology of RFC 5598 and that of RFC 5321.  If we decide
to treat 5598 as authoritative and to adjust 5321 to match it,
it seems to me that consistency would dictate that we change
other terminology in 5321 to match.    That is precisely the
type of cosmetic, error-prone, change I think we should not try
to make ... and that I believe you have argued as strongly as I
have for not making.

AFAIK, nothing procedural prevents you from trying to convince
the IESG and the community that the 5598 should be reclassified
to BCP or Standards Track and, as part of that change, making
its terminology authoritative and normative.  This WG should not
be implicitly making such a change via some sort of tacit
assumption or by accepting a claim that it already has that
status.

     john

---

From: Dave Crocker <[email-masked]>
Date: Wed, 8 Dec 2021 14:41:19 -0800

On 12/7/2021 8:54 PM, John C Klensin wrote:
> document's publication as a model and a history.  

Since the document has only a brief history section and is clearly not 
significantly a history document, your assertion about that is factually 
wrong.

And 'model' is only a component of the document's effort, which is 
listed as covering:

>       *  Capturing refinements to the email model
>       *  Clarifying functional roles for the architectural components
>       *  Clarifying identity-related issues, across the email service
>       *  Defining terminology for architectural components and their
>          interactions

So you are oddly selective about the nature of the document.

Perhaps you missed that last bullet?

> I should not

Your 'If" is false.  First, it missed that there was quite good rough 
consensus among IETF email folk for standardization.  Second, the IESG 
comments are strongly positive about the content.

Third, perhaps you can point to some documentation about IESG reasoning 
for RFC 5598?  The IESG ballot record provides no example of the 
constrained usage view you cite. And while it has a number of statements 
preferring Informational, only one offers something of an explanation.

It's probably also worth noting that, so far:

   6 Standards track RFCs have made normative reference to it
   1 BCP RFC has made normative reference to it
   4 Experimental RFsC has made normative reference to it

and if my counting is correct:

   24 RFCs have made informative reference to it.

So it might be worth considering the substance of the material at issue, 
rather than invoking questionable process points.

Somehow you neglected to consider the substance of that material, rather 
than the process surrounding it.

> to make ... and that I believe you have argued as strongly as I

My questions are focused on specific items already on the table.  They 
seek to use existing work that represents extensive IETF development 
effort and review, rather than having the working group re-litigate 
basic material.  I offered nothing implying or intending to expand the 
scope of work.

So your comments about expanded scope are yours, not mine, and for what 
it's worth, I see no requirement to expand that scope.

As such, introducing that expansion, as part of my query, is a distraction.

To be clear, your "If we decide to treat 5598 as authoritative and to 
adjust 5321 to match it," goes quite far beyond the scope of my query 
and beyond the items I've raised questions about.

Also, it's quite odd to consider definitions to be cosmetic.

> assumption or by accepting a claim that it already has that

Thanks for suggesting work I might consider.  I hadn't thought of doing 
that. And it certainly has nothing to do with the working group's 
current activities.

d/