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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.