On 5/10/2012 9:22 AM, Tony Finch wrote:
Dave Crocker<[email protected]> wrote:
Multiple simultaneous TCP connections are highly problematic.
Especially for new protocols.
The real world of today's Internet makes it difficult to ensure proper
operation through firewalls and application gateways.
Well they aren't great for congestion control and window sizing, but
a multiplexing mechanism always has those issues, where the underlying
issue is making sure that a problem in one sub-channel does not block
the others.
multiplexing adds complexity. it's always better to find a workable
solution that does not require it.
middleboxes should only be a problem if you are doing FTP-style layering
violations.
I don't have a guess about what layering violation you think FTP does...
So concurrent connections are normal for HTTP and IMAP and
I was careful to say "new" protocols. And I think I was careful to cite
use of different port numbers. (I certainly meant to be.)
Parallel identical connections for protocols that already punch through
firewalls are in a very different position of strength than new
protocols. However even these are problematic for gateways. On the
average, we don't design for concern about gateways, but the issue still
exists.
Everything over port 443.
well, that's obviously far better than everything over 80...
And while I mean that ironically, there's a kernel of reality to it:
Beep was produced in response to the clear trend to put everything over
http. Beep is lower cost, by quite a bit.
It then adds back some cost with the multiplexing mechanism, of course.
But that's why it replicates established multiplexing mechanisms from
lower layers.
For reference, I'm not lobbying for it's use, here. I don't have an
opinion for the IMAPnextgen discussion, but wanted to clarify why beep
was a long way from crazy.
d/
--
Dave Crocker
bbiw.net
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
