Re: [hybi] I-D Action:draft-ietf-hybi-thewebsocketprotocol-01.txt

[Ian Fette (イアンフェッティ) <[e-mail]>]

James -

Good feedback, thank you. FWIW I agree with what you said below, but I
expect that we will flush out details once we have agreement on the base
framing. In putting this together my primary concern was to get an updated
draft that reflected the recent framing discussions so that we can settle
that issue. Once we have some reasonable level agreement that yes, this
framing is correct, then I think we can fully specify (with MUSTs) behaviour
in all of the circumstances you mention. However, it's a bit like trying to
discuss whether you want the car in red or black when your spouse is trying
to decide between a prius and a F150 -- certain things have to settle down
first :)

-Ian

On Thu, Sep 2, 2010 at 4:47 AM, James Graham <[e-mail]> wrote:

> On 09/02/2010 12:45 AM, [e-mail] wrote:
>
>  A URL for this Internet-Draft is:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-01.txt
>>
>
> A few initial comments:
>
> The framing sections seem to have a lot of SHOULDs. This is worrying as
> SHOULD-level conditions can't really be tested (it is not an error to
> violate them) and can be a source of interoperability problems. I would
> prefer that we make all behaviour mandatory unless there is a good reason to
> do otherwise.
>
> Some specific clauses seem problematic. For example:
>
> """A receiver MUST be prepared to accept arbitrarily fragmented
>      messages, even if the sender sent the message in a single frame."""
>
> "be prepared to accept" seems like poor wording. I would just say "Clients
> and servers MUST support recieving both fragmented and unfragmented
> messages". The clause "even if the sender sent the message..." seems odd
> because it is not clear how the recipient can know how the message is
> originally sent. In any case it seems redundant. This whole clause could be
> avoided with normative processing requirements that require support for
> fragmented and unfragmented messages (see below).
>
> """Ping
>
>      Upon receipt of a Ping message, an endpoint SHOULD send a Pong
>      response as soon as is practical.  The Pong response MUST contain
>      the payload provided in the Ping message, though an implementation
>      MAY truncate the message at an implementation-defined size which
>      MUST be at least 8 _(TBD)_ bytes."""
>
> It seems simpler and less error prone to require truncation always in case
> servers come to depend on the behaviour of specific implementations here.
>
> """      Ping frames MAY be sent as a keep-alive mechanism, but if so the
> interval SHOULD be configurable."""
>
> I have no idea what this SHOULD is trying to require. Is it supposed to be
> a requirement on browser UI? On server implementations? Something else? In
> any case, we can't really require that things are configurable.
>
> """Close:
>
>      Upon receipt of a close frame, an endpoint SHOULD send a Close
>      frame to the remote recipient, if it has not already done so,
>      deliver a close event to the application if necessary, and then
>      close the WebSocket."""
>
> It is not clear what the scope of the SHOULD here is. Since this is nested
> inside a MUST clause I guess "and then close the connection" is supposed to
> be a requirement. I'm not sure why sending the close frame is "SHOULD". I
> don't think it is necessary to talk about "deliver[ing] a close event to the
> application" since the interaction between the application and the protocol
> is for the application to determine. For the specific case of the JS API we
> just need to ensure we use the right terminology so that the description in
> the API document is correct (i.e. this needs to match section 7.3 of the
> protocol draft and section 5 of the API draft).
>
>
> There seems to be a general lack of processing requirements. I don't know
> if this is just something that is missing from the first draft, but without
> such requirements there are a lot of missing details. For example it is
> unclear what happens if the first frame a client receives has opcode=0
> (aside: it seems like we can design around this particular problem by e.g.
> ditching opcode=0 and just ignoring opcode after the first frame in a
> fragment). It is also not defined what should happen if any of the reserved
> bits are set or if the opcode is in the reserved range. All of these things
> are essential for interoperable implementations.
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>