Re: [hybi] updated Charter proposal

[Jamie Lokier <[e-mail]>]

Salvatore Loreto wrote:
> Jamie Lokier wrote:
> >Peter Saint-Andre wrote:
> >  
> >>Somewhere in the text we need to make it clear what kind of intermediate
> >>entities we're talking about -- does that include entities which are in
> >>some sense HTTP-aware or HTTP-optimized (proxies, load balancers,
> >>caches, etc.) or also entities that are in some sense more generalized
> >>(firewalls, network address translators, etc.).
> >>    
> >
> >Firewalls and NATs are quite important to HyBi.  Because the server
> >can't initiate connections, it's necessary for connections to be kept
> >open as long as the client wishes to receive messages.  Firewalls and
> >NATs need enough keepalive packets to stop them blocking a connection
> >in mid use.  And "ping" requests with responses from one side are
> >not the most efficient way to do that.
> >
> >HyBi may also need a strategy to cope when a firewall or NAT
> >spontaneously blocks a connection in the middle of it's use too.  That
> >might be deferred to the application (bet lots of them will get it
> >wrong if so), but it should at least be addressed.
> >  
> I agree that we have to take in consideration Firewalls and NATs during 
> the design of a Bidirectional protocol
> (both short and long term), and this is extremely important for HyBi.
> However the HyBi wg should not have any ambition to improve the 
> Firewalls and NATs, but only design a protocol that
> cooperate well with them and improve the existing HTTP entities to 
> improve the interaction with the existing Firewalls and NATs.

Fwiw, I agree completely.

It may involve characterising firewalls and NATs, for example to
suggest keepalive message rates and strategies.  I wouldn't be
surprised if another part of IETF has investigated that already in a
more general context or for some other protocol.

The issue of connections being dropped, and detecting when this has
happened, and perhaps recovering, is more general than firewalls and
NATs.  E.g. mobile IP has the same problem.  I don't know if it needs
to appear anywhere in HyBi or if it can be dealt with entirely in the
application layer.  But it is worth looking at, because a web full of
applications which deal with it badly is a less desirable outcome than
a web full of applications which handle it well, and we _might_ be
able to make a big difference there.

-- Jamie