Subject: [imap5] Beep

From: Dave Crocker <[email-masked]>
Date: Thu, 10 May 2012 08:57:06 -0700

On 2/16/2012 3:30 AM, Tony Finch wrote:
> I think BEEP is insane. Masses of complexity just to avoid using multiple
> concurrent TCP connections.

Having been involved in creating beep, I'm feeling obligated to respond 
on this.  I won't be saying anything that isn't pretty obvious, so the 
real disparity is almost certainly personal interpretations of degree:

    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.

It would be very nice to fix this underlying problem, but until it's 
fixed, then a new application that uses new TCP ports is not likely to 
succeed.

d/
-- 
  Dave Crocker
  bbiw.net

---

From: Tony Finch <[email-masked]>
Date: Thu, 10 May 2012 17:22:20 +0100

> operation through firewalls and application gateways.

Well they aren't great for congestion control and window sizing, but
middleboxes should only be a problem if you are doing FTP-style layering
violations. So concurrent connections are normal for HTTP and IMAP and
SMTP etc. and work OK for other protocols. After all, the network can't
tell the difference between one user's concurrent connections and multiple
concurrent users.

> It would be very nice to fix this underlying problem, but until it's fixed,
> then a new application that uses new TCP ports is not likely to succeed.

Everything over port 443.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Malin: Northeast backing north 5 to 7. Moderate or rough. Rain then showers.
Moderate or good.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 10 May 2012 09:30:51 -0700

On 5/10/2012 9:22 AM, Tony Finch wrote:
> Dave Crocker<[email-masked]>  wrote:
>>

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.

> 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

---

From: Bron Gondwana <[email-masked]>
Date: Thu, 10 May 2012 21:56:50 +0200

On Thu, May 10, 2012 at 09:30:51AM -0700, Dave Crocker wrote:
> 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.
> 
> 
> opinion for the IMAPnextgen discussion, but wanted to clarify why
> beep was a long way from crazy.

SCTP seems like a great idea apart from the difficulty bootstrapping
support - you need more than just application-level support.  BEEP
suffers a bit from the "you need a less-common library to implement
it" problem too - but at least libraries seem pretty common.

It's hard to argue with everything over 443 from a perspective of
"just f'n well works for users" though.

Bron.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Thu, 10 May 2012 23:03:26 +0000

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-masked]>
To: "Tony Finch" <[email-masked]>
Cc: "Discussion on drastically slimming-down IMAP." <[email-masked]>
Sent: 11/05/2012 4:30:51 a.m.
Subject: Re: [imap5] Beep
>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. 
>
>
>
>--  Dave Crocker 
>_______________________________________________ 
>imap5 mailing list 
>[email-masked] 
>https://www.ietf.org/mailman/listinfo/imap5

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Thu, 10 May 2012 23:08:08 +0000

------ Original Message ------
From: "Adrien W. de Croy" <[email-masked]>
To: "Dave Crocker" <[email-masked]>;"Tony Finch" <[email-masked]>
Cc: "Discussion on drastically slimming-down IMAP." <[email-masked]>
Sent: 11/05/2012 11:03:26 a.m.
Subject: Re: [imap5] Beep
>  
>There was recently a long and heated discussion about the same issue 
>on the HTTP WG list. 
>  
>* everyone should be encrypting everything anyway (response - not 
>true, many situations require transparency, and forcing burden of 
>SSL/TLS deployment everywhere is highly problematic) 
>  
  
actually I'm confusing BEEP with something else (BOSH) ... strike that 
final comment... I don't know enough about it to comment.

Adrien

>>>>The real world of today's Internet makes it difficult to ensure 
>>>>proper operation through firewalls and application gateways. 
>>>
>>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. 
>>>middleboxes should only be a problem if you are doing FTP-style 
>>>layering violations. 
>>
>>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. 
>>
>>
>>d/ -- Dave Crocker bbiw.net 
>>_______________________________________________ imap5 mailing list 
>>[email-masked] https://www.ietf.org/mailman/listinfo/imap5 
>