There was recently a long and heated discussion about the same issue on
the HTTP WG list.
I think it's a really bad idea to migrate everything to port 443, and
would be a huge step backwards for the internet.
Firstly, there are many intermediaries that snoop into port 443 (break
into the SSL with spoofed certs etc) and expect to find HTTP in there.
This is done because there's no supported way for an intermediary to
perform its necessary functions on https. IN fact we're looking into
options to put the intermediary in the picture, since there are many
valid bona fide reasons why the content requires inspection (e.g.
malware). Especially since more and more of the web is moving to https
(FB, Gmail etc etc).
the arguments for such a proposal are things like
* 443 gets through firewalls (response - now they may, probably not so
in future).
* everyone should be encrypting everything anyway (response - not true,
many situations require transparency, and forcing burden of SSL/TLS
deployment everywhere is highly problematic)
Basically my position is moving to port 443 for other protocols is an
escalation in the arms-race between client / server vendors and
intermediary vendors. There must be a better way.
BEEP may seem insane. It kinda is, but it's doing what it has to given
the limitations. However specifying some new protocol such as IMAP5 to
go over BEEP _would_ be insane.
Adrien
------ Original Message ------
From: "Dave Crocker" <[email protected]>
To: "Tony Finch" <[email protected]>
Cc: "Discussion on drastically slimming-down IMAP." <[email protected]>
Sent: 11/05/2012 4:30:51 a.m.
Subject: Re: [imap5] Beep
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
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
