Re: [hybi] BWTP progress

One thing that I didn't see when I looked at (an earlier draft of) BWTP 
that I'd like included is a recommendation for how to layer 
request/response semantics over it. This would be achievable right now 
per the draft with custom headers (e.g. X-Method: GET, X-Request-Id: 
1234 .... X-Response-Id: 1234, X-Status: 200 OK) but it seems like a 
common enough case that codifying it might make sense.

One scenario we're looking at over in OGPX is where HTTP serves very 
well - both as a transport and REST semantics - for client access to 
server resources. We also have the reverse scenario where the "server" 
would make use of "client" resources, and again the HTTP semantics work 
well; this is currently achieved in practice (and drafted) as long poll 
connections over HTTP.

http://tools.ietf.org/html/draft-lentczner-rhttp-00 has been written, 
describing RHTTP which addresses this specific case in a straightforward 
manner. If BWTP were to formalize the semantics for bi-directional 
resource utilization with REST semantics over the protocol, that'd be 
swell, and it would be straightforward for OGPX protocols to operate 
over BWTP.

Greg Wilkins wrote:
> All,
>
> The BWTP proposal continues to be worked on and is getting
> some more content that would be good to be reviewed:
>
> The Connection: closing   header to allow an intermediary
> to initiate an orderly close of a BWTP connection.
>
> Origin and Access-Control-Allow-Origin headers to control
> who can see messages.
>
> Content-Encoding and Transfer-Encoding. Do we need both?
> They make sense in a request situation where the transfer-encoding
> is not the encoding of the requested resource???
>
> Content Range/Language/Location definitions
>
> More examples in Appendix
>
>
> review/ideas/critique welcome!
>
>
> cheers
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>   