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

[Gabriel Montenegro <[e-mail]>]

After discussion with Salvatore, this is our take on this:

The only thing that absolutely needs to change, then is this:

b-yes-2) Allow the Pong body to contain extra data beyond just echoing the Ping body?
OK. Harmless. I don't have any preference on this. This needs text change.

And the corresponding change is in section 4.5.3 on Pong:

OLD:
The message
   bodies (i.e. both the Extension data (if any) and the Application
   data) of the Ping and Pong MUST be the same.
NEW:
 The message body's Application data of the Ping and Pong MUST be the same.

Thanks,

Gabriel

From: [e-mail] [mailto:[e-mail]] On Behalf Of Takeshi Yoshino
Sent: Wednesday, May 25, 2011 21:35
To: Patrick McManus
Cc: [e-mail]
Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07)

On Wed, May 25, 2011 at 20:10, Patrick McManus <[e-mail]<mailto:[e-mail]>> wrote:
But if A's algorithm is "unpredictable random sequence" then B cannot
realistically match A's value even if they are uncoordinated. Just make
the random space sufficiently large - these are infrequent events after
all.

Yes. I know.

My point is the trade off between "please choose and implement some algorithm (e.g. random 3, 4 or more octet) that very possibly never generates body which collide with others' by yourself when necessary" and "the spec clearly disambiguates them by 1 octet indicator".

I think the former works practically. But that's not what something called "specification" should do I think in principle. Things people may leave under-specified are things that defined in lower or under layer which have their own agreement/spec, or extensions that has negotiation mechanism by which entities can coordinate their behavior. This is not the case.

that does break interoperability, though. a Ping of "0x23 0x24 0x25
0x26" is legal under -07 and invalid under that text. s/must/SHOULD
would repair that, I suppose.

Yes. For non-empty cases, it does break.

-07 rules? It's time to ship the protocol already.

I'm ok with this shipped without adding indicator if no one else thinks it's necessary. It's time to ship, yes. Personally I have no plan to use non-empty ping/pong body.

As Bruce listed, there're some other issues raised recently. Here are my thoughts on them.

a) Allow multiple in-flight Pings?
Yes. Harmless. Jamie's opinion makes sense. Keep the current text.

b) Allow Ping and Pong to have a body?
Yes. Harmless. Keep the current text.

b-yes-1) Disambiguate solicited and unsolicited Pong by the spec?
I can live without this, but I think we should.

b-yes-2) Allow the Pong body to contain extra data beyond just echoing the Ping body?
OK. Harmless. I don't have any preference on this. This needs text change.

c) Have solicited Pong respond to only the most recent Ping?
I don't understand why we allow this kind of unsynchronized behavior purposely. It's not a good way to discourage multiple in-flight Pings. If it's good to disallow multiple in-flight Pings, the spec should say "multiple in-flight Pings MUST not be sent" directly. I think most of implementation would handle received data frame-by-frame. Once it sees a Ping frame, it will enqueue a Pong to its sending queue, forget it and move on the next frame. This text looks just confusing.
Again, I can live with this.

Thanks,
Takeshi