Re: [hybi] HyBi Design Space

[Salvatore Loreto <[e-mail]>]

Hi Martin,

see in line.

Cheers
Sal

Thomson, Martin wrote:
> 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.
>   
thanks
> 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
>   
right, there was consensus for both! and the HyBi will eventually work 
to address both!
> 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.
>   
the confusion most probably come from the fact that the draft was 
thought to address the problem -A- .
maybe instead of insert the Design Space analysis text in the existing 
draft it would be better include it in a new draft;
and then include in the existing draft (draft-loreto-http-bidirectional) 
a much more specific text for the "right here and now, HTTP extensions".
would it make sense?



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