Re: [hybi] Requirements.

[SM <[e-mail]>]

Hi Greg,
At 16:06 31-01-10, Greg Wilkins wrote:
>All, in line with the charter milestones,  I'd like to start a discussion
>in preparation to preparing a requirements document for April.

[snip]

>Connection limits
>=================
>Connections can consume significant resources on a network and/or
>server.  If a application has an unconstrained ability to open new
>connections than an client may attempt to open more connections
>as a way to reserve more of a servers resources for their application.
>Unconstrained connection creation may also be used as a DOS attack
>(although this is somewhat limited by the current requirement that only
>a single handshake can be outstanding at once).
>
>Endpoints (not applications) should enforce reasonable connection limits.
>Endpoint implementations should be able to negotiate and/or declare
>the maximal connection limits that they will enforce.

The protocol document would then have to define the reasonable 
connection limit.  That serves as guidance to implementors.

>Orderly Close.
>==============
>That either endpoint or any intermediary may initiate an orderly close of
>a websocket connection, such that any message sent before the close would
>be guaranteed of delivery if there are no other failures of the connection.
>
>Websocket endpoints and intermediaries would be able to distinguish between
>an orderly close and a failure of a websocket and thus take different
>application actions with regards to any non-idempotent messages recently
>sent.

That's better than saying that it is always safe to disconnect.

>A websocket endpoint that frequently detects non orderly closes on a
>particular path may make statistical/heuristic inferences about the
>ws support of intermediaries.  It may then take action by reducing idle
>times and/or sending keep-alives.

If it is not normative, you can get away with that.

>Acknowledged Flush
>==================
>Either endpoint may initiate an acknowledged flush of a websocket connection.
>This would be similar to an orderly close in that endpoints and intermediaries
>would be able to know that all messages sent prior to the flush had been
>delivered to the opposite endpoint, except that the connection would be
>left open.

Are you asking for acknowledgement of delivery as part of the protocol?

>Content Type & encodings
>========================
>
>Websocket endpoints may wish to send data in alternative encodings
>and with indications of content type.  Examples include compressing,
>signing or encrypting messages, using utf-16 instead of utf-8 for
>some language groups, sending images or other media.   Content type
>and encoding is needed to make usage of the binary framing transport.
>
>It's unclear if content type should be negotiated or simply declared.
>The under utilization of accept- headers in HTTP would suggest negotiation
>is perhaps not required.

You will have to support content negotiation if you want to support 
different content types.

>Standardized Extensions
>=======================
>
>Features/requirements that deemed to not be base requirements
>(eg possibly message fragmentation and connection sharing), may
>be desirable to support in the form of standardized extensions
>to the protocol.

That's a good idea of else you will end up with a lot of stuff in the 
"base" specifications.

There is also the question of whether the protocol should be run on 
the same port as HTTP (re: discussion about HTTP Upgrade) or whether 
it should be assigned a different TCP port.

Regards,
-sm