Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07)

[Bruce Atherton <[e-mail]>]

It seems there are still a number of issues around Ping/Pong. Here are 
my thoughts on them:

1) Should multiple Pings be allowed before a response Pong is received?

Surely this is the business of the implementation/application and not 
the specification. If someone has a use for such a thing, why not allow it?

2) Should Ping and Pong be allowed to have a body?

I think it is a useful and desirable feature. It allows matching Pongs 
to Pings, as well as being an area for experimenting with new ideas in 
how the Ping and Pong are used.

The argument has been brought up that the bodies are useless without a 
standard way of interpreting them. This is absolutely true. Why not 
allow experimentation so that people can come up with standards for them?

What is the downside to allowing it?

3) Should there be an indicator for unsolicited Pongs and/or Pings that 
need no response.

I don't see why this is necessary or desirable so long as the body of 
the Pong in some way indicates the Ping it is responding to. Allowing 
unsolicited Pongs removes any usecase for Pings without responses as far 
as I can see. As far as unsolicited Pongs go, if the Pong body does not 
match a Ping that was sent out, then surely it can be assumed to be an 
unsolicited Pong.

What is the marker trying to indicate? That if we have a Pong that 
claims to be solicited and does not match the Ping body that there is a 
bug in the server implementation, or perhaps that the server is mistaken 
in the client it thinks it is communicating with? Is this really necessary?

4) Should we allow the Pong body to contain extra data beyond just 
echoing the Ping body?

Again, I think this is a harmless way to allow experimentation on uses 
for Ping and Pong. I don't see any reason for disallowing it.

It has been claimed that there could not be any value in allowing 
additional information because Ping/Pong frames run at a higher priority 
than other Websocket traffic, and so any data they carry on network 
characteristics would not reflect the behaviour of other data in the 
channel. This makes a couple of assumptions that I think are 
questionable. First, are all possible uses of Ping and Pong concerned 
with network characteristics? Even if so, are all possible network 
characteristics rendered moot by higher priority traffic? I don't see it 
necessarily follows that these two assumptions are valid.

So if it were up to me, I would just change the spec to indicate that 
the Pong must respond with the Ping body, but is allowed to add any data 
it wishes to afterward. In fact, you could even change it to respond 
with just a hash of the Ping body followed by any other data it wanted 
to (SHA1 + Base64 for consistency).

I wouldn't add in a flag for unsolicited vs. solicited Pongs since the 
Pong response does that for us by indicating the Ping it is responding 
to, but if others wanted it then I wouldn't stand in their way. 
Although, if you are going to specify a byte for a single flag then you 
may want to indicate the other 7 bits are reserved for future use.