[e2e] was Re: A message to authors - nsdi

[Michael Welzl]

> If you posit that a proposal actually "solves" a problem, you won't mind
> having the end-to-end argument posed - does it completely solve it, or
> must the endpoints be involved.   If they must be involved, why is your
> "in the guts of the system" solution needed?   If it is an optimization,
> does it also have bad cases that wouldn't have been there if the
> solution hadn't been invented in the first place?

We need to think about what the endpoints are in the email scenario...


> Email, like paper mail before it, does NOT guarantee delivery.   The
> fault is not with email or the US post office.  The fault is with the
> users (in this case the program committees).

Well - even if email doesn't guarantee delivery, the general public's
expectation is that it does. It's not just program committees  :-)   it's
a fact of the world which I have personally encountered on several
occasions, just like (I assume) many of us: people believe email to
be reliable.

So, in order to give people the desired (even expected!) service, we
should make it reliable.

The end points, however, should be my outgoing SMTP server and
your incoming POP or IMAP server. This is the communication
that we assume to be trustworthy and reliable - not the communication
between your email client and mine. If my personal email client's spam
filter deletes emails, it's my fault and I would be inclined to accept it.
If I didn't configure that filter, I'd assume that it's the client
developer's
fault, and complain to them (or someone else would).

It's the same thing with the post office - people assume the
communication path from my post office to yours to be reliable,
or at least *quite* reliable. If the US post office would start
losing 50% of your letters (I know, email isn't doing that, but
it's getting worse, and we ought to pull the break before it's too
late), people would get heavily annoyed, and misunderstandings
would happen.

Hmm, didn't the UK just give us an example of that?  :-)

Cheers,
Michael