Subject: [hybi] moving forward on HTTP extensions

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Jun 2009 11:10:58 -0600

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/

---

From: Pieter Hintjens <[email-masked]>
Date: Wed, 17 Jun 2009 20:36:04 +0200

> - - Would it be helpful to schedule a text or voice chat before IETF 75?

All the items look interesting but more detail would help, especially
covering the justification (problems the change would solve,
alternatives, impact of change).

One question: have you already a wiki for this, and if not, shall I
set one up as we did for BWTP?  It could help in capturing the
discussion and organizing the work.

I'm in Brussels but would come to Stockholm if there was a BOF gathering.

Voice chats, not for me thanks.  Maybe an irc meeting.

Cheers,
-Pieter

---

From: Pieter Hintjens <[email-masked]>
Date: Thu, 18 Jun 2009 13:40:56 +0200

On Thu, Jun 18, 2009 at 1:24 PM, Salvatore
Loreto<[email-masked]> wrote:

> we have tried to list all the issue on the Best Practice draft:
> http://www.ietf.org/internet-drafts/draft-loreto-http-bidirectional-00.txt

This is an excellent text and immediately useful to me, and I'll
reference it in the RestMS design.

The only improvements I could offer are some language simplifications,
the use of passive tense in parts of the text makes the explanations
less precise than they could be.  I'd be happy to edit.

Two questions that occur to me are:

* how these best practices relate to RESTful use of HTTP
* how protocols like WebSockets and BWTP fit into the picture

Cheers,
Pieter

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 18 Jun 2009 15:44:37 +0300

> less precise than they could be.  I'd be happy to edit.
any opinions on potential future work items for bidirectional HTTP that 
are listed in the draft?

it would be even more interesting hear your (as well from all the other 
people interested in this issue) ideas/opinions
on how HTTP could be extended to better support bidirectional communication

> * how these best practices relate to RESTful use of HTTP
good point, we haven't said anything about the RESTful use of HTTP for 
bidirectional / long polling.
It would be great explicitly adding some statement explicitly saying that:
- every URI designates exactly one resource
- only GET has to be used to retrieve a representation of a resource.

but I have to admit that I have not looked into RestMS yet!

> * how protocols like WebSockets and BWTP fit into the picture
the best practices draft only relates to the technologies that provide 
server-push using HTTP.
Both WebSocket and BWTP are instead working on a different aspect of the 
server-push technique,
that briefly is upgrade from HTTP to a different bidirectional protocol.
So both the protocols do not fit at all into this draft.

cheers
Sal

---

From: Pieter Hintjens <[email-masked]>
Date: Thu, 18 Jun 2009 15:06:46 +0200

On Thu, Jun 18, 2009 at 2:44 PM, Salvatore
Loreto<[email-masked]> wrote:

> any opinions on potential future work items for bidirectional HTTP that are
> listed in the draft?

I am not really competent to give opinions except that (a) the work
items seem to make sense, but (b) it may be more pragmatic to solve
some of them outside HTTP, e.g. with BWTP.

> So both the protocols do not fit at all into this draft.

Understood.

-Pieter

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 19 Jun 2009 01:57:37 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Peter Saint-Andre
> Sent: Thursday, 18 June 2009 3:11 AM
> To: [email-masked]
> Subject: [hybi] moving forward on HTTP extensions
> 
------------------------------------------------------------------------------------------------
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]

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 28 Jun 2009 19:02:46 +0300

Hi Martin,

thanks for you useful comments and suggestion.

I want make clear that the draft focus is on the "near term" solutions 
to the problem of using HTTP for bidirectional exchanges
and does not consider at all the longer-term goals that go beyond HTTP.
It only talks about what's possible using the existing protocol and 
existing tools, the intention is to analyse the  current  solutions 
that  go  under  the  Comet  umbrella name,  highlight the problems and 
eventually
propose small possible ways to extend HTTP to accommodate/improve the 
current Comet solution.

To write the document we have analysed how  Bayeux  and  Bosh  protocols 
use  HTTP for  bidirectional exchanges,
and in particular  we have  dug in the  Tomcat implementation of  Cometd 
and  Bayeux to write down the conclusion present in the
draft. I am not saying that they are the final conclusions, actually I 
see them just as a first step to start the discussion...
and then receive different points of view and different experiences 
learned using HTTP for bidirectional exchanges.

it would be also interesting to know from the list members who will be 
available in Stockholm to join a bar BOF about this
(I mean discuss the "near term" part of HyBi group)

see more in line...

thanks
Sal

> 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.  
I agree on the fact that Section 6 "Future Work" is just a list of 
possible idea, and that it would be better explain better what is behind 
each of the points in the list...
we will clarify that in a next version
> 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…
thanks, that was the actual intention of the draft.
> 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 HT…
actually the draft describe both the two most common server push 
mechanisms: "Long Polling" and  "HTTP Streaming",
even if we analyse HTTP Streaming only from the angle of a possible way 
to answer to a Long Poll request
> 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 practic…
you are completely right, there isn't any suggestion on how to improve 
the streaming solution. We can spend more time to analyse better this 
problem and then try to define more
definite conclusion.
It would be also interesting receive your opinion as well as comments by 
other expert people on this 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.
good suggestion. We will expand the section and put in a more 
problems/requirements way, in a next version!
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>