Re: [hybi] moving forward on HTTP extensions

["Thomson, Martin" <Martin.Thomson at andrew.com>]

Hi Peter,

My first impression from reading the document is that the problems are reasonably well stated, but the process by which these conclusions are arrived at is not made especially clear.  

At this stage, this document seems to add the most value as a problem statement alone, and it does a good job of that, maybe it could be entered as one half of the basis of a WG effort.  (The other half being related to longer term efforts.)

My second impression was that the name "Bidiectional HTTP" was unfortunate, even if the name is actually entirely precise.  The document concentrates on the practical near-term problems of using HTTP for bidirectional exchanges.  This group, which shares a similar name, has a larger set of goals that bring in longer-term goals that go beyond HTTP.  "HTTP long-polling" might be a better choice.

From the conclusions drawn in the draft, it seems that long-polling is really the only approach considered.  What, if any, provision is made for streaming?  It seems that streaming is not a practical near-term option and longer-term options have much greater freedom.  I'd like to see the analysis on streaming, but I can't see anything coming from it.  The draft could be clearer on that point.

As much as anything, this is a call for an analysis of requirements for long-polling.  Rather than leap to what appear to be conclusions, why not concentrate on the problems/requirements.

1. Request-response correlation for "inverted" queries, such as those that might occur with long polling.  If I use pipelining to reduce latency, how do I identify to the HTTP server that this "request" I'm making is in response to the "response" it sent.  Useful.

2. If this is "please tell me when http://x.example.org/page changes", then this is certainly useful, but I'd actually see this as an _application_ of this specification, not a part of this.  Don't read that wrong, I'd be keen to make this possible, but I don't see it as a necessary part of the solution.  Defer.

3-4. Timeout management - need a way to specify/determine timeout constraints imposed by intermediaries, then act on them to ensure that a server doesn't hold onto a transaction that is no longer good.  (I tend to think that measuring based on 408/504 followed by a hint to the server might work, but that would be pre-empting on my part.)  Useful.

5. Is useful, but is probably less critical.

6. Resource identification/addressing.  It isn't sufficient to rely on the request URI for this purpose (because then you can't operate long-polling on multiple resources on the same server without blowing out your connection budget -- incidentally, this is a problem I didn't see expressed in the draft).  Useful.

--Martin

> -----Original Message-----
> From: hybi-bounces at ietf.org [mailto:hybi-bounces at ietf.org] On Behalf Of
> Peter Saint-Andre
> Sent: Thursday, 18 June 2009 3:11 AM
> To: hybi at ietf.org
> Subject: [hybi] moving forward on HTTP extensions
> 
> Some potential future work items for bidirectional HTTP are discussed
> in
> draft-loreto-http-bidirectional-00 as follows:
> 
> 1. An HTTP extension for long polling, including request tracking,
>    duplication, and retry methods.
> 
> 2. A method for monitoring the state of multiple resources.
> 
> 3. A request header to determine timeouts.
> 
> 4. A request header to determine the longest acceptable polling
>    interval.
> 
> 5. Improved rendezvous logic between the user agent, a proxy /
>    connection manager, and the backend application server.
> 
> 6. Improved addressing for the entities involved in bidirectional
>    HTTP, possibly including the use of URI templates.
> 
> Sal and I just had a chat about this topic and would like to ask for
> feedback from the list members:
> 
> - - Which work items do folks think would be most productive to focus
> on?
> 
> - - Who will be available in Stockholm to join a bar BOF about this?
> 
> - - Would it be helpful to schedule a text or voice chat before IETF
> 75?
> 
> Thanks!
> 
> Peter
> 
> - --
> Peter Saint-Andre
> https://stpeter.im/
> 
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]