Subject: [hybi] Some words about "WS intermediaries"

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 13:47:35 +0200

Hi all,

I would like to talk a bit about SIP protocol (mainly RFC 3261):

RFC 3261 defines the concept of SIP client, SIP server and SIP proxy.
A SIP proxy is an entity that works as SIP level and routes requests
and responses. It can also require authentication (401/407 responses),
make authorization decisions (based on requests source IP,
authenticated user, SIP method, content of the SIP request...), modify
requests and responses (by adding/modifying headers), change the
transport (UDP / TCP / TLS / SCTP...).

A SIP proxy can be transaction stateful or stateless. A transaction
stateful SIP proxy has memory and can match arriving responses with
their associated requests. They run transaction timers, mantain
client/server transaction states, send request retransmission when
required and so on.

A stateless SIP proxy is not aware of transactions. It just route
requests and responses based on their headers. A stateless SIP proxy
can handle millions of requests/responses and it's used for
scalability purposes. So RFC 3261 (SIP protocol) provides a
scalability solution at *SIP* level, rather than IP/TCP/UDP/black-box
level.

Anyhow, some vendors sell their own SIP black-boxes stuff, which
manipulates SIP traffic without being a pure SIP entity. Those boxes
are ***NEVER*** covered by any RFC related to SIP protocol, and no
vendor dares to demand such black-boxes to be present in a SIP related
RFC. In fact, recently a new draft about MSRP protocol (related to SIP
protocol) was rejected because it proposed a change in the existing
protocol to make it to work within telco wallen gardens in which some
black-boxes were deployed. The draft was rejected because of it and
now it looks totally different.

But in this WG it seems that black-boxes are allowed and admited from
the very beginning. Even more, they are vaguely mentioned in the core
spec (WS draft) but the spec talks about what such abstract and
undefined element can do when "processing" WS frames.

I will be clear: this is an aberration IMHO. The purpose of the IETF
is to define a protocol for Internet in a clear way. Leaving the door
open for undefined elements altering the protocol traffic is not the
way to go. Or at least it should not be covered by the spec.

I would suggest (sure it's to late) the inclusion of the "WebSocket
proxy" in the spec. It could unmask, re-frame, do load-balancing,
perform the WS handshake (or not) and so on. Define all the
capabilities of a WebSocket proxy and there you have your
"intermediary" as something defined and specified.

I also suggest learning from SIP protocol rather than HTTP protocol.

Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 16 Sep 2011 01:22:37 +1000

> "intermediary" as something defined and specified.

Iñaki,

I think it is impossible and unnecessary to try to define "all the
capabilities of a WebSocket proxy" as some kind of
one-true-intermediary.

HTTP has no one-true-intermediary defined and as a result a rich
ecosystem of intermediaries have evolved and provided a vast array of
value add features.  This ecosystem has evolved through the changing
needs of authentication, security, load growth, changing traffic
types, caching, privacy, etc. etc. etc. and I believe it is one of the
key reasons that HTTP has be able to adapt and remain the dominant
internet protocol.

I see no point in trying to define the one-true-intermediary.  Try as
we might to come up with a single definition of what is a WS
intermediary, there will be use-cases that emerge that we have not yet
thought of and people WILL implement them.  I think it is far better
for a specification to embrace such innovation rather than to pretend
that with a few MUSTs they can stop it happening.

So long as the intermediaries consume and produce valid streams of
websocket frames and do not break any end to end extensions
negotiated, then we should not be concerned with what ever additional
functionality they may add.

cheers

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 18:34:04 +0200

> functionality they may add.

In summary, a WS client cannot/should-not expect the existence of a WS
intermediary in the path, neither a WS server. So nothing in the path
must break the WS traffic or alter it in a way that the communication
or protocol gets broken or affected.

IMHO is totally unnecessary to say that obviousness in the draft. In
*any* protocol in the world (involving clients and servers) there can
be *nothing* in the path that breaks the protocol messages or protocol
itself.

Imagine that RFC 2616 states:

  ------------------------
  An intermediary should not change the name of the
  headers in the HTTP requests or responses.
  --------------------------

Obvious!

So I still think that the draft should remove any mention to
_intermediaries_, as they *do not* exist from the point of view of WS
clients and WS servers, they can change *nothing* within the protocol
itself and they just behave as ghosts in the path. If the intermediary
changes something in the traffic from client to server (without
breaking the protocol), the client will not realize of it, the same
occurs in reverse direction. So they "don't exist" for WS endpoints
(they SHOULD NOT exist).

Having said that, of course the _intermediaries_ MUST NOT break the WS
protocol, of course. Is that a reason for including them in the draft?
Neither my mother should be allowed to break the WS traffic between a
WS client and server, why not to include a reference to my mother in
the draft?:

  -----------------------------
  Inaki's mom MUST NOT break the WebSocket protocol
  -----------------------------

Regards.

PS: Sorry for the bad joke.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: John Tamplin <[email-masked]>
Date: Thu, 15 Sep 2011 12:39:18 -0400

This is really getting tiresome.  We don't define every word in the spec,
only those that we want a specific behavior.  Everybody but you seems to
understand that by intermediary we mean anything between the ultimate
endpoints of the WebSocket connection.

Please stop repeating the same arguments with the same exaggerations.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 16 Sep 2011 09:08:19 +1000

Well no.  HTTP intermediaries can and do change header names in HTTP requests.
For example I have often seen intermediaries change
  Connection: close
to
  _onnection: close

because that effectively removes that header, but without requiring
data copies within their buffers. The RFC did not try to prohibit such
behaviour.  Further 2616 does actually put some requirements on
proxy's handling of that header.  for example:

   The proxy server MUST signal persistent connections separately with
   its clients and the origin servers (or other proxy servers) that it
   connects to. Each persistent connection applies to only one transport
   link.

This is exactly what we are doing in the WS spec.   Most of the
mentions of intermediaries are either explaining the design of the
protocol or putting on extra requirements on intermediaries that go
beyond producing a sequence of valid WS frames.  For example:

as a fragmented message may be coalesced or
   split by an intermediary

 With fragmentation, a server
   or intermediary may choose a reasonable size buffer, and when the
   buffer is full write a fragment to the network.

An intermediary might coalesce and/or split frames, if no
   extensions were negotiated by the client and the server, or if some
   extensions were negotiated, but the intermediary understood all the
   extensions negotiated and knows how to coalesce and/or split frames
   in presence of these extensions.

As control frames cannot be fragmented, an intermediary MUST NOT
    attempt to change the fragmentation of a control frame.

An intermediary MUST NOT change the fragmentation of a message if
      any reserved bit values are used and the meaning of these values
      is not known to the intermediary.

An intermediary MUST NOT change the fragmentation of any message
      in the context of a connection where extensions have been
      negotiated and the intermediary is not aware of the semantics of
      the negotiated extensions.

One or two of those are a little redundant, but I do not think any are
obvious enough to warrant removal from the specification.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 16 Sep 2011 18:17:57 +0200

> obvious enough to warrant removal from the specification.

I just ask for a minimal description of a "WS intermediary" in the
draft, just it. It's not nice that the draft speaks about something
that is defined nowhere just because "all the people" have something
in mind and are used to HTTP intermediaries.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>