[ih] There is no such thing as an "end-to-end failure"

[Dave Crocker]

On 9/13/2020 12:28 PM, Joseph Touch via Internet-history wrote:
>> On Sep 13, 2020, at 11:09 AM, Dave Crocker <dhc at dcrocker.net> wrote:
>> Note that my primary comment was about terminology.
>>
>> I'm going to venture that this exchange demonstrates how unproductive --
>> or even counterproductive -- language like "end-to-end failure" is.
> 
> Agreed. My version is:
> 
> 	from user sending a post to a list
> 	to user knowing the post arrives on that list

MLMs vary on whether the author gets a copy of the message posted 
through the MLM.  In fact it is a per-list configuration option for some 
MLM software.  (I think that includes the IETF list manager.)


>> In formal architectural parlance, a basic mailing list sequence
>>
>>   MUA -> MSA -> MTA -> ... MTA -> MDA -> MLM ->
>>
>>       -> MSA -> MTA -> ... MTA -> MDA -> MUA
> 
> You’ve omitted the users on both ends of that sequence, which *can* be part of the E2E chain too.
> 
>> ...
>> It's tempting to think that the issue might be to provide a mechanism
>> invoked during 'final' delivery, to the 'ultimate' recipient.  That
>> would presume knowing when that occurs.  cf, multiple mailing lists.
> 
> Humans do.

Yeah, but that's largely irrelevant, in terms of operational realities.

There is a widespread belief that it's good to give user's control.  The 
belief typically does not distinguish between "available" and "required" 
and therefore misses the basic problem of user burden, attention, 
desire, etc.



>>>>> If it were, your mailer would have let you know that you didn’t
>>>>> receive a copy of the mail
>>
>> My "mailer" would let me know I didn't receive some mail?  Isn't that
>> akin to proving a negative?  I don't understand how my "mailer" can be
>> expected to know about mail I didn't receive.
> 
> A timeout. That’s the only way anyone (or thing) ever knows something is lost.
A timeout to what?  From what to what? I have guesses what you might 
mean but this is your mechanism, not mine. And my guess is for something 
that doesn't work very well...


>>> or that your post didn’t appear in the archive. So, at some level,
>>> one E2E failure happened in the design and implementation of ALL mail
>>> readers.
>>
>> Sorry, but I do not understand the control mechanisms you are postulating.
> 
> A mail reader COULD know when it’s posting to a list (we don’t currently encode that in either email addresses or the protocols to post to lists, but that could have been done).
> 
> A mail reader could then correlate the sent mail to the receipt of matching post to that list, again if email had sufficient unique IDs that were retained through the entire chain from  user to mailing list and back to that user.

The sent (outbox) MUA folder constitutes just such a list, and some MUAs 
do correlate received return receipts.  But as I originally noted, 
that's a low-level email transport mechanism, not specific to mailing lists.


>> They appear to involve quite a bit of mechanism that hasn't been
>> discussed much, over the 45+ years of email, or implemented for Internet
>> mail at all.
> 
> Right - my (apparently too subtle) point is that this was
> 	a) not considered by email designers
> 	b) not performed by email list users
> 	c) but appears to be assumed of email list maintainers
> 
> I don’t consider (a) the E2E failure; rather it is the combination of (a), (b), and (c).

You've left off:  not required by users.  New mechanism is expensive. 
Mechanism not demanded by the market -- or not appreciated by the market 
when the mechanism shows up -- is a lot of wasted time and money.

That was the (apparently too subtle) point in referring to the 45+ year
history of this service.


>> The basic stance of such rubbish is that all eventualities must be
>> anticipated before anything is put into the field.  That was the OSI
>> approach.  Besides creating infinite delay, it doesn't work.
> 
> One eventuality is that hop by hop mail delivery in a mail sequence does not confer E2E delivery guarantees.
> 
> Any mail source could - and should - plan for that. That includes “people” as that source.

Yeah, but... I don't know what that means in its particulars.  Or at 
least not what it means beyond what is already happening.


>> Sorry, but I don't know what "matching list posts to sent mail" is,
>> since I consider "posts" to equate to "sent".
> 
> If that were true, then Karl’s posts were all successful. They all got sent to ISOC and promptly dropped on the floor after being successfully received.

Some mail is worth ignoring.  Some MLMs are clever.

But seriously...

Your "if that were true" doesn't seem to follow from what I wrote. 
Sorry, I just don't understand.


>> Further, there is nothing
>> that identifies mail that is sent as specifically going to a list.
> 
> As per above, yes. That’s part of the “failure” of the system overall to account for the E2E goal.

Oh good.  That gives you a design task, for a better mechanism.  Note 
that the major challenge here won't be the technology but overcoming end 
user resistance.

Well, ok.  Some design approaches would be to create intractable 
technology designs...



>> Your certitude about what is needed for end-to-end mailing list behavior serves as self-nomination to produce something similar for mailing lists.  I look forward to reviewing your first draft.
> 
> Here’s the draft, in as much detail as is needed:
> 
> 	- if you post to a list and don’t see it in the archive or get a copy,
> 	then debug it by varying what’s transmitted and who transmits it, i.e., at the endpoints
> 
> Not all E2E problems should start by demanding visibility into the middle of a path.

I don't see how what you have in mind does not require such visibility.

also, end users love being given tasks like that.

But, really, I'd argue that the requirement is already satisfied. You 
can choose to do all that today.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net