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

[Takeshi Yoshino <[e-mail]>]

On Wed, May 25, 2011 at 20:10, Patrick McManus <[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