Subject: [hybi] #19: Changes to Section 4.4 - Control Frames

From: "hybi issue tracker" <[email-masked]>
Date: Mon, 27 Sep 2010 17:20:05 -0000

#19: Changes to Section 4.4 - Control Frames
----------------------------------+-----------------------------------------
 Reporter:  sm+ietf@…             |       Owner:     
     Type:  defect                |      Status:  new
 Priority:  major                 |   Milestone:     
Component:  thewebsocketprotocol  |     Version:     
 Severity:  Active WG Document    |    Keywords:     
----------------------------------+-----------------------------------------
 Message posted by Patrick McManus on 2 Sept, 2010:

 Section 4.4 - Control Frames

 I've done some more significant cleanups here that go a bit beyond the
 editorial. Specifically I want to include some of James Graham's
 concerns.

 As drafted a ping and pong are meant to be paired together via their
 content.. but the pong is allowed to truncate the content but isn't
 given any mechanism to indicate that it has done so.. in light of that how
 can the pinger determine if there is a match? If those truncated bytes
 aren't relevant to the match, why did it send them in the first place? My
 answer to that is to disallow truncation but limit the message size to the
 tiny 125 byte frame size. If people want to argue for a larger but still
 reasonable constant I don't have a problem with that.
 Furthermore the draft made responding to the ping optional (SHOULD
 level) which really makes it kind of useless as a keep-alive.. so I
 changed that to MUST respond, but SHOULD do it soonish. (see text).

 We've been calling them control frames, not control messages, so I
 assume that means they shouldn't be fragmented and I made that a
 requirement. The alternative is to try and consistently call them
 control messages. Personally, I don't see a reason to let them be
 fragmented into multiple frames.

 With that being said - this is the proposed replacement for section 4.4:

 =============

 4.4.  Control Frames

    Control frames have opcodes of 0x01, 0x02, or 0x03. They are used
    to communicate state about the websocket.

    All control frames MUST be 125 bytes or less in length and MUST NOT be
 fragmented.

 4.4.1 Close

    The Close message contains an opcode of 0x01.

    The application MUST NOT send any more data messages after
    sending a close message.

    A recevied close message is deemed to be an acknowledgement if the
 message body matches the body of a close message previously sent by the
 receiver. Otherwise the close message is a close initiated by the sender.

    Upon receipt of an initiated close the endpoint MUST send a close
    acknowledgment. It should do so as soon as is practical.

    The websocket is considered fully closed when an endpoint has either
 received a close acknowledgment or sent a close acknowledgment.

 4.4.2 Ping

    The Ping message contains an opcode of 0x02.

    Upon receipt of a Ping message, an endpoint MUST send a Pong
    message in response. It SHOULD do so as soon as is practical. The
    message bodies of the Ping and Pong MUST be the same.

 4.4.3 Pong

    The Pong message contains an opcode of 0x03.

    Upon receipt of a Ping message, an endpoint MUST send a Pong
    message in response. It SHOULD do so as soon as is practical. The
    message bodies of the Ping and Pong MUST be the same.

 http://www.ietf.org/mail-archive/web/hybi/current/msg04005.html

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/hybi/trac/ticket/19>
hybi <http://tools.ietf.org/hybi/>
The Hypertext-Bidirectional (HyBi) working group will seek
standardization of one approach to maintain bidirectional
communications between the HTTP client, server and intermediate
entities, which will provide more efficiency compared to the current
use of hanging requests.