Re: [hybi] HyBi Design Space

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

While I agree that constraining the design space is probably a necessary part of our work, there are aspects to this text that concern me.

I like the effort that is going into identifying the servers, clients and intermediaries that are involved and the constraints that are involved.  That part of the text seems valuable.

However, it seems like there was consensus to address two problems in the WG:

 A - right here and now, HTTP extensions
 B - sometime later, new protocols that interact somehow with HTTP

From the abstract and early sections of the document, the draft right now seems to be concentrated on the side of A.

This analysis seems divorced from this goal, so much so that it seems a little unfocussed.

For instance, the usual laundry list of desires surfaces: Complexity, Capability, Extensibility, Latency, Bandwidth, Scalability, Footprint, AAA, Security, Interoperability (!), Compatibility.

These are constraints on any design exercise.  They don't add any value unless they are directly related to the work at hand.

My initial view of this document was a problem statement for A.  To that end, this could all be much more specific.  For instance, compatibility is highly important for solution A.  Or, more specifically yet: it is important that solution A can be deployed to the web in the short-term, so compatibility with existing implementations is crucial.

The example of "Non-browser, non-HTTP" immediately jumps out as a problem for this document.  A reasonable reaction might be that this is way out of scope.  But then, I know that it isn't necessarily the case.   Insufficient context has been provided to assess this item rationally because it's talking about B, not A.

Because the constraints are significantly different on A vs. B, a separate problem statement for B seems appropriate.  That would help this be a little less vague.

--Martin

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Salvatore Loreto
> Sent: Friday, 9 October 2009 7:51 AM
> To: [e-mail]
> Subject: [hybi] HyBi Design Space
> 
> Hi there,
> 
> at the breakfast BoF in Stockholm it was brought up that it would have
> been helpful to more
> clearly describe the design space, including the programming
> environments (client, server,
> library, etc.), deployed infrastructure (routers, proxies, etc.).
> 
> here the analysis that we have written down and we are going to insert
> in the
> draft-loreto-http-bidirectional.
> 
> comments, feedbacks and suggestions are very welcome
> 
> cheers
> Sal
> www.sloreto.com
> 
> 
> 
> 6.  Design Space
> 
>    In order to define additions to HTTP that could enable improved
>    mechanisms for bidirectional HTTP or new bidirectional protocols, it
>    is important to map out the design space and potential design
>    alternatives, with special attention to deployed infrastructure and
>    programming environments.
> 
>    In existing HTTP-based systems, the typical semantic is client-
> server
>    Representational State Transfer (REST), where the resources served
>    are closely associated with an entity known by a URI or URL.
>    However, the introduction of bidirectionality can significantly
>    change the normal HTTP patterns.
> 
>    As one example, the standard roles of client and server can be
>    reversed and a server can request resources from a client.
>    Unfortunately, due to a lack of client addressability URL's may not	
>    be applicable to client entities and new addressing paradigms may be
>    required.
> 
>    Furthermore, bidirectionality introduces a message passing pattern
>    into the traditional REST style.
> 
>    These additional semantics will influence the design of the
>    bidirecitonal protocols, addressing, and APIs.  Without a strong
>    association between an identified entity and a resource, new
>    mechanisms for content distribution and caching messages might need
>    to be considered.
> 
>    In the next sections we analyse the design space from several
>    different sides of the HTTP deployed infrastructure, including
>    clients, servers, and intermediaries such as proxies, caching
>    servers, and load balancers.
> 
>    The process of evaluating eventual improvements to the bidirectional
>    solutions or development of new bidirection protocols should take
>    into consideration the following concerns and criteria:
> 
>    Complexity:  enables ease of implementation, understanding, and
>       debugging
> 
>    Capability:  addresses all/most known bidirectional use-cases
> 
>    Extensibility:  has the capacity to handle new use-cases
> 	
>    Latency:  defines minimal, average, and maximal latency for message
>       delivery
> 
>    Bandwidth overhead:  minimizes overhead for idle and busy usage
> 
>    Scalability:  has the ability to handle large scale usage
> 
>    Footprint:  has the ability to handle small devices and/or massive
>       replication ("cloud")
> 
>    AAA:  enables proper Authentication, Authorization and Accounting
> 
>    Security:  enables strong security for integral, confidential,
>       endorsed, and cross domain deployments.
> 
>    Interoperability:  can work with and/or be integrated with existing
>       bidirectional implementations
> 
>    Compatibility:  can work with existing web infrastructure for
>       distributing, caching, manipulating, and displaying content.
> 
> 6.1.  Server side
> 
>    The server side can be decomposed into three categories:
> 
>    In-band HTTP:  Bidirectionality is part of the normal HTTP/Web
> server
>       responsibilities.  HTTP is used for transporting server events.
>       Examples include Comet and (in some deployments) BOSH.
> 
>    Out-of-band HTTP:  Here two servers are involved: bidirectionality
> is
>       not part of the normal HTTP/Web server responsibilities, but the
>       backend service is offered by a separate server that might not
>       even be on the same machine of the HTTP/Web server.  HTTP is used
>       for transporting server events.  When a browser is used on the
>       client side, a cross-domain solution is needed to overcome the
>       "same-source" web service restriction.  Examples include BOSH (in
>       some deployments) and Lightstreamer.
> 
>    In-band non-HTTP:  Bidirectionality is part of the normal HTTP/Web
>       server responsibilities.  However, server events are transported
>       on an upgraded HTTP connection.  Examples include Bidirectional
>       Web Transfer Protocol (BWTP) and WebSockets.
> 
>    Out-of-band non-HTTP:  Bidirectionality is offered by a dedicated
>       server using non HTTP protocol for transport server events.
>       Examples include WebSockets.
> 
>    The HTTP transport based servers (in-band and out-of-band) can work
>    with existing HTTP standards or enhanced HTTP.  Enhanced HTTP would
>    be a standardized set of headers and behaviours to assist with
>    bidirectionality and cross domain concerns.
> 
>    At present, a protocol that interacts heavily with JavaScript on the
>    client side implies some constraints also on the server side, such
>    that they have to use XML or JSON encapsulation.
> 
> 6.2.  Clients
> 
>    Clients can be involved in bidirectional transport in the following
>    capacities:
> 
>    In browser open standards with HTTP transport:  For applications
>       written in a web browser scripting language (e.g.  JavaScript)
>       within a browser client.  Examples include Comet and BOSH.
> 
>    In browser open standards with enhanced HTTP transport:  For
>       applications written in a web browser scripting language (e.g.
>       JavaScript) within a browser client.  Examples include Comet with
>       cross domain extensions.
> 
>       Browsers using either standard HTTP transport or enhanced HTTP
>       transport typically use XMLHttpRequest (XHR) API
>       [W3C.WD-XMLHttpRequest2-20090820] allowing scripts to perform
> HTTP
>       client functionality.  The XHR object can be used to perform
>       bidirectional HTTP using both "long polling" and "HTTP streaming"
>       mechanisms.
> 
>       XHR also supports the cross domain extension
>       [W3C.WD-cors-20090317], which overcomes the same-origin
>       restrictions that prevent a Web application running from one
>       origin from obtaining data retrieved from another origin.
>       However, XHR presents some limitations on the headers that can be
>       set by the user.
> 
>       An alternative to XMLHttpRequest is using the Server-Sent Events
>       API [W3C.WD-eventsource-20090423].  This "EventSource: interface
>       enables servers to push data to Web pages over HTTP or using
>       dedicated server-push protocols.
> 
> 
>    In browser open standards with non HTTP transport:  For applications
>       written in JavaScript within a browser client.  Examples include
>       BWTP and WebSockets.
> 
>    In browser with plugin:  This is not of particular interest to IETF,
>       but should be noted as part of the design space.  Examples
> include
>       BlazeDS.
> 
>    Non-browser HTTP:  A bidirectional client may be written outside of
> a
>       browser and use bidirectional web transports.  Typically this is
>       done so that a rich or minimal client can bypass firewalls to
>       access public servers over HTTP transports.  Examples include the
>       Comet Java client and the Second Life Viewer.
> 
>    Non browser enhanced HTTP:  [Definition and examples to follow.]
> 
>    Non browser non-HTTP:  [Definition and examples to follow.]
> 
> 6.3.  Intermediaries
> 
>    Intermediaries (e.g. proxies, gateways, caching servers, load
>    balancers, etc) can be involved in bidirectional transport in
> several
>    capacities:
> 
>    Legal HTTP relay:  Transports such as long polling use
> intermediaries
>       to carry legal HTTP requests and response.  Any capabilities that
>       may interfere with bidirectional flow (e.g. caching) are
>       controlled with standard headers or cookies.  The intermediary
> may
>       be a participant in the transport (e.g., changing framing or
>       encapsulation).
> 
>    Defacto HTTP relay:  Some streaming transports use the common
>       behavior of HTTP intermediaries to forward content packet-by-
>       packet.  This relies on intermediaries to not cache or buffer
>       content.
> 
>    Enhanced HTTP relay:  Uses yet-to-be-defined HTTP headers to assist
>       HTTP based bidirectional transports.  The intermediary may be a
>       participant in the transport (e.g., changing framing or
>       encapsulation).
> 
>    Upgraded HTTP relay:  Uses HTTP upgrade to relay a non-HTTP
> protocol.
> 
>    Tunneled relay:  Uses (or abuses?) the CONNECT mechanism to simulate
>       an SSL connection to be used as a tunnel for a non-HTTP
> transport.
> 
> 
> 
> 
>    [W3C.WD-XMLHttpRequest2-20090820]
>               Kesteren, A., "XMLHttpRequest Level 2", World Wide Web
>               Consortium WD WD-XMLHttpRequest2-20090820, August 2009,
>               <http://www.w3.org/TR/2009/WD-XMLHttpRequest2-20090820>.
> 
>    [W3C.WD-cors-20090317]
>               Kesteren, A., "Cross-Origin Resource Sharing", World Wide
>               Web Consortium WD WD-cors-20090317, March 2009,
>               <http://www.w3.org/TR/2009/WD-cors-20090317>.
> 
>    [W3C.WD-eventsource-20090423]
>               Hickson, I., "Server-Sent Events", World Wide Web
>               Consortium WD WD-eventsource-20090423, April 2009,
>               <http://www.w3.org/TR/2009/WD-eventsource-20090423>.
> 
> 
> 
> 
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi

------------------------------------------------------------------------------------------------
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]