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

[Michael Welzl]

> Putting "features" in the Berkeley Sockets interface doesn't solve the 
> problem generically.  The problem has nothing to do with the lack of 
> features "in the network".  Papering over that fact by positing that 
> "there exists a generic solution" doesn't actually prove that there 
> really is a generic *solution*.  Just a pile of crappy new features 
> justified by a questionable claim of relevance.

I'm not saying that there *has* to be a generic solution (that
might just not be exist), I just said that I disagree that there's
no need (or maybe better: demand) for it. There can be partial
solutions like SureMail which actually make sense.

The way you refer to "features in the network" above indicates
to me that you're taking a "pro end-to-end" position here,
whereas mine is "anti end-to-end".

- but I don't think that this is the right way to see it. The end
systems that we are talking about here are humans, and I'm
not sure if we can take e2e as a guiding principle when that
is the case - after all, the goal seems to be to build a system
that's convenient for people to use.

We don't require people to be involved in TCP ACKs, right?

Just because SMTP and POP/IMAP servers aren't built in
end hosts like TCP is, that doesn't mean that they are not the
communication endpoints that people interact with. You seem
to say that they are "in the network". I say they are the end
systems that we must consider, because they are the entities that
we (as human users of the system) expect a certain service from.

 
> The same logic justifies scanning airport passengers for Arabic names 
> and presuming that contributes to "security".

I don't get that analogy.

Cheers,
Michael