[hybi] Comments on draft-loreto-http-bidirectional-01

["Thomson, Martin" <[e-mail]>]

==Two connection limit:

No mention is made on why this limit exists; it's an important concern that is not captured elsewhere 

I also note that httpbis still haven't decided on whether this limit will be lifted: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/131>

==Intermediaries:

I noted in the breakfast BoF that there was a need for a way for an end client or host to indicate to intermediaries that long-polling is in use.  One thing I see a lot of is complete suppression of HTTP caching, which might be unnecessary in many cases, except for the fact that intermediaries could provide a cached response.  

What would be really nice is a set of extensions, or maybe just some recommendations for existing headers, that allow clients to give intermediaries the hints they need to act in a constructive fashion.  Caching is one thing - connection management is another (i.e. allocate a new connection for this: it's going to take a little while).

Mark Nottingham suggested that he might write something like this up last meeting.

=="A request header to determine timeouts":

This presumes a solution, which might be good, but I'm not sure that a header truly is necessary.  Why not simply express the problem: "Provide a mechanism, or describe a method that allows a client to determine the most appropriate (or longest) time that a long poll can be outstanding.  Any mechanism must work without support from intermediaries..."

==REST:

How much of this is intended to fit with the a resource-based data model (i.e., REST)?  It's an important constraint on the solution space that we need to consider.  To my mind, there is less value in simply providing a transport for bi-directional transport; we can probably do better by ensuring that this fits within the model...for those who care for the benefits that provides.

For me at least, this means that a mechanism is provided whereby a client can learn of state changes in a resource.  Long polling allows this to be relatively low latency without the overheads of repeated polling.

==Building an API:

During Lisa's REST presentation yesterday, she noted that APIs aren't often done by the IETF.  Aside from the fact that these were pretty hard, her thesis was that APIs tend to build tight coupling and that they constrain implementations.  Based on this (and the fact that the W3C already does XMLHttpRequest) the API piece can be dropped.

==Improved addressing for the entities involved:

I'm not clear on what this means any more.  Entities at the server end are resources identified by URIs.  That doesn't seem inadequate to me.  I've seen discussions where the idea that a client is divided into multiple logical, addressable entities, but the question has to be asked: is this truly necessary?